[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:16:17 -0700
User-agent: AquaMail/1.24.0-1585 (build: 102400006)

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:


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

Why should we support this kind of post definition namespace modification?

reply via email to

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