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

[Vladimir Sedach]

Andrea Corallo <address@hidden> writes:
> 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.

Sounds like too much late-binding. If you mentally translate the
lexspaces to nested flets, that would be "lexical." This is a kind of
dynamic binding of functions, and a dynamic-binding-of-dynamic
bindings of special variables.

Between this and Helmut's observation that there is not enough
late-binding, it seems that the lexspace prototype as of the
time of this writing has not arrived at "just enough" late-binding
yet.

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

Why would you need the extra redirection? If you resolve the chain at
compile-time, it should be the same as calling a function defined
with flet.

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

The original motivation for the currently ongoing discussion (as I
understand it) is João's attempt to solve the problem of s.el
choosing a short prefix, without requiring all of the packages that
rely on s.el to change the way that they call s.el

What is needed is for package maintainers to be able to do only:

--8<---------------cut here---------------start------------->8---
(declare-namespace legacy-library
  (import other-string-library-with-long-name s-))
--8<---------------cut here---------------end--------------->8---

And for things to "just work."

--
Vladimir Sedach
Software engineering services in Los Angeles https://oneofus.la