[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: Andrea Corallo
Subject: Re: A prototype for a binding based approach to proper namespaces
Date: Sat, 09 May 2020 15:50:31 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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.

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

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
>> 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 :)



reply via email to

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