[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel Colascione
Subject: Re: A prototype for a binding based approach to proper namespaces
Date: Sat, 09 May 2020 08:56:21 -0700
User-agent: AquaMail/1.24.0-1585 (build: 102400006)

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

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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]