Re: A prototype for a binding based approach to proper namespaces

[Daniel Colascione]

On May 9, 2020 8:51:23 AM Andrea Corallo <address@hidden> wrote:

> Daniel Colascione <address@hidden> writes:
>
> > > I think it depends on how resilient you want to have your language to
> > > redefinitions.  Say you have four libraries B derived from A and C from
> > > B etc:
> > >
> > > A <= B <= C <=
> >
> >
> > We don't have these problems at all with an approach based on symbol
> > rewriting in the reader. Even one additional pointers chase at runtime
> > is too much, especially since we're considering using this mechanism
> > as a routine way to access module provided facilities and not as a
> > rare patch for papering over other problems, as with existing symbol
> > aliases. (Thanks to modern memory architectures, each pointer chase is
> > brutal.) Yes, I dislike reader magic, but I dislike runtime overhead a
> > lot more.
>
> I agree with you in principle, but the fact that a pointer chase more is
> negative for performance in a measurable way or not for this case should
> be verified with a measure

Death by a thousand cuts is something that happens to lots of real world 
programs. I don't want to introduce unnecessary memory indirections or 
branches where simple and efficient alternatives are known to exist and 
where they're just as good as the inefficient option.

> Cache misses in modern architectures can be expansive but also caches
> are now very big.  I'm pretty sure that if you have a good locality on
> bindings given we often hit there cache misses should't be much of a
> problem.

No. We need those caches for *other* things too.

> I'm sure you know it but for public record:  this argument obviously
> applies to global variables only, locals in lexical code are not
> effected.
>
> > > E has visibility on ~everything was defined in A.  Now what if while
> > > running A changes the value of something used by E?  We need at least
> > > one indirection to handle that otherwise you would be pointing still to
> > > the original object.  But it is more complex because while running B
> > > could decide to unimport the definition from A and define the variable
> > > locally,
> >
> > Why should we support this kind of post definition namespace modification?
>
> I think is good to support it not to have to restart Emacs while
> developing.  Python restarts all the time, Emacs depends on the user
> habit :)

A symbol rewriting approach supports unloading and reloading just as well 
as we support it today, which seems adequate. Symbol rewriting is, in 
general, a much smaller departure from how things work today.