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

[Andrea Corallo <akrl@sdf.org>]

Daniel Colascione <dancol@dancol.org> writes:

> On May 8, 2020 1:49:05 PM Andrea Corallo <akrl@sdf.org> 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 <= E

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, then you need to retain the whole chain to have a consistent
behavior.

Now, I think when compiling would a fair assumtion that libraries (B and
C here) never unimport and redefine variables or functions.  With this
assumptoon should be very easy to compile out all intermediate
indirections (bindings) except the last 'effective' one.

> If we adopt the short prefix alias
> approach proposed elsewhere, we don't have the problem of bare symbol
> aliasing.

I'd like to add an optional prefix to `lexspace-import-symbol' but I'm
not sure we are on the same point here.  Do you have the link for the
proposition you refer to?  I've got a bit lost in all the discussion.

  Andrea

-- 
akrl@sdf.org