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

[Andrea Corallo]

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
problem.

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

Andrea

-- 
address@hidden