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

[Daniel Colascione]

On May 9, 2020 1:05:27 AM Andrea Corallo <address@hidden> wrote:

> Daniel Colascione <address@hidden> writes:
>
> > On May 8, 2020 1:49:05 PM Andrea Corallo <address@hidden> wrote:
> >
> > > Hi all,
> > >
> > > given the ongoing discussion on namespaces I thought was interesting to
> > > try out a prototype to reason on.
> > >
> > > I wrote a short page explaining what I did and how it is implemented:
> > >
> > > https://akrl.sdf.org/lexspaces/lexspaces.html
> > >
> > > It's a quick hack, certainly many pieces are missing, is potentially a
> > > very bad idea, but I'd be interested in opinions.
> >
> > If the set of imports is known at compile time, why do we need to pay
> > the runtime cost of the binding?
>
> 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.

> 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?