A prototype for a binding based approach to proper namespaces

A prototype for a binding based approach to proper namespaces

[Andrea Corallo]

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.

  Andrea

--
akrl@sdf.org

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

[Daniel Colascione]

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? If we adopt the short prefix alias approach 
proposed elsewhere, we don't have the problem of bare symbol aliasing.


>
>  Andrea
>
> --
> akrl@sdf.org

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

[Andrea Corallo]

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

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

[Daniel Colascione]

On May 9, 2020 1:05:27 AM Andrea Corallo <akrl@sdf.org> wrote:

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


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?

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

[Andrea Corallo]

Daniel Colascione <dancol@dancol.org> 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

-- 
akrl@sdf.org

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

[Daniel Colascione]

On May 9, 2020 8:51:23 AM Andrea Corallo <akrl@sdf.org> wrote:

> Daniel Colascione <dancol@dancol.org> 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

Death by a thousand cuts is something that happens to lots of real world 
programs. I don't want to introduce unnecessary memory indirections or 
branches where simple and efficient alternatives are known to exist and 
where they're just as good as the inefficient option.

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

No. We need those caches for *other* things too.

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

A symbol rewriting approach supports unloading and reloading just as well 
as we support it today, which seems adequate. Symbol rewriting is, in 
general, a much smaller departure from how things work today.

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

[Andrea Corallo]

Daniel Colascione <dancol@dancol.org> writes:

>> 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
>
> Death by a thousand cuts is something that happens to lots of real
> world programs. I don't want to introduce unnecessary memory
> indirections or branches where simple and efficient alternatives are
> known to exist and where they're just as good as the inefficient
> option.

Exactly because we are talking of real world programs I think it should
be measured :)

I'll maybe have a run using the prototype (so it will prove some
usefulness) and report.

-- 
akrl@sdf.org

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

[Daniel Colascione]

On May 9, 2020 9:39:18 AM Andrea Corallo <akrl@sdf.org> wrote:

> Daniel Colascione <dancol@dancol.org> writes:
>
>>> 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
>>
>> Death by a thousand cuts is something that happens to lots of real
>> world programs. I don't want to introduce unnecessary memory
>> indirections or branches where simple and efficient alternatives are
>> known to exist and where they're just as good as the inefficient
>> option.
>
> Exactly because we are talking of real world programs I think it should
> be measured :)
>
> I'll maybe have a run using the prototype (so it will prove some
> usefulness) and report.

No, not in this case. This is something that might appear to be fine in 
isolated tests or in modules that don't get a lot of use, but the more 
people use this thing, the worse it gets, right? I don't see any reason to 
*prefer* this approach to the zero cost one. Let's not be slow for no benefit.


>
> --
> akrl@sdf.org

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

[Andrea Corallo]

Daniel Colascione <dancol@dancol.org> writes:

> On May 9, 2020 9:39:18 AM Andrea Corallo <akrl@sdf.org> wrote:
>
>> Daniel Colascione <dancol@dancol.org> writes:
>>
>>>> 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
>>>
>>> Death by a thousand cuts is something that happens to lots of real
>>> world programs. I don't want to introduce unnecessary memory
>>> indirections or branches where simple and efficient alternatives are
>>> known to exist and where they're just as good as the inefficient
>>> option.
>>
>> Exactly because we are talking of real world programs I think it should
>> be measured :)
>>
>> I'll maybe have a run using the prototype (so it will prove some
>> usefulness) and report.
>
> No, not in this case. This is something that might appear to be fine
> in isolated tests or in modules that don't get a lot of use, but the
> more people use this thing, the worse it gets, right? I don't see any
> reason to *prefer* this approach to the zero cost one. Let's not be
> slow for no benefit.

If the alternative is the read time approach I think many people think
it has disadvantages.  Are proposing a third way?

-- 
akrl@sdf.org

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

[Daniel Colascione]

On May 9, 2020 10:15:29 AM Andrea Corallo <akrl@sdf.org> wrote:

> Daniel Colascione <dancol@dancol.org> writes:
>
>> On May 9, 2020 9:39:18 AM Andrea Corallo <akrl@sdf.org> wrote:
>>
>>> Daniel Colascione <dancol@dancol.org> writes:
>>>
>>>>> 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
>>>>
>>>> Death by a thousand cuts is something that happens to lots of real
>>>> world programs. I don't want to introduce unnecessary memory
>>>> indirections or branches where simple and efficient alternatives are
>>>> known to exist and where they're just as good as the inefficient
>>>> option.
>>>
>>> Exactly because we are talking of real world programs I think it should
>>> be measured :)
>>>
>>> I'll maybe have a run using the prototype (so it will prove some
>>> usefulness) and report.
>>
>> No, not in this case. This is something that might appear to be fine
>> in isolated tests or in modules that don't get a lot of use, but the
>> more people use this thing, the worse it gets, right? I don't see any
>> reason to *prefer* this approach to the zero cost one. Let's not be
>> slow for no benefit.
>
> If the alternative is the read time approach I think many people think
> it has disadvantages.  Are proposing a third way?


Which specific disadvantages?

> --
> akrl@sdf.org

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

[Andrea Corallo]

Daniel Colascione <dancol@dancol.org> writes:

>>> No, not in this case. This is something that might appear to be fine
>>> in isolated tests or in modules that don't get a lot of use, but the
>>> more people use this thing, the worse it gets, right? I don't see any
>>> reason to *prefer* this approach to the zero cost one. Let's not be
>>> slow for no benefit.
>>
>> If the alternative is the read time approach I think many people think
>> it has disadvantages.  Are proposing a third way?
>
>
> Which specific disadvantages?

I think there as been recently other discussions here on this, you can
look them up.  I'd say read-time side effects and symbol leakage.  This
is all coming from having different obarrays the reader is working on.

Anyway reasoning about I think is possible to have no additional
indirections in (byte-)compiled code with this system too.  If the
Lexspace is known at compile time and so is the final slot into the
binding to be used this should be used directly.  It shouldn't be hard
to implement.

  Andrea

-- 
akrl@sdf.org

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

[João Távora]

On Sun, May 10, 2020 at 12:14 AM Andrea Corallo <akrl@sdf.org> wrote:
> >> If the alternative is the read time approach I think many people think
> >> it has disadvantages.
> > Which specific disadvantages?
> I think there as been recently other discussions here on this, you can
> look them up.  I'd say read-time side effects

Can you be specific? "Read-time side effects" _is_ the read-time
approach. At read time, you intern symbols, thus producing a side
effect, i.e. the program's state is different than before your read.  S
So your assertion is hard to understand.

> and symbol leakage.

Where to symbols leak to?  Where do they leak from? Are
you describing bugs from the future?

I've recently implemented a simple-minded <50-line
reader-based approach, I didn't see any "leakage",
but maybe I'm not looking the right place.

https://github.com/joaotavora/elisp-shorthand

João

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

[Vladimir Sedach]

Andrea Corallo <akrl@sdf.org> 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

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

[João Távora]

On Sun, May 10, 2020 at 12:30 AM Vladimir Sedach <vas@oneofus.la> wrote:

> 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

Indeed, that is the most desired feature because there is a large
body of programs that use s.el, f.el dash.el and such. We don't want
the importation of one of those systems to pollute the namespace.
Every system we idealize, whatever the approach, should keep
its eyes on this prize, IMO.

I've personally come up with this in
https://github.com/joaotavora/elisp-shorthand
so you can add it to the 7 or so I've counted so far.

Vlamidir, earlier you had many questions about the shorthand
approach that I couldn't answer.  shorthand.el is less than 50 loc,
it's reasonably easy to read.  It's very dumb, and doesn't do
any fancy stuff, but it does solve the problem.  Obviously, a proper
implementation wouldn't use advice, but proper interfaces.

João

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

[Daniel Colascione]

On 5/9/20 4:53 PM, João Távora wrote:
> On Sun, May 10, 2020 at 12:30 AM Vladimir Sedach <vas@oneofus.la> wrote:
> 
>> 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
> 
> Indeed, that is the most desired feature because there is a large
> body of programs that use s.el, f.el dash.el and such. We don't want
> the importation of one of those systems to pollute the namespace.
> Every system we idealize, whatever the approach, should keep
> its eyes on this prize, IMO.
> 
> I've personally come up with this in
> https://github.com/joaotavora/elisp-shorthand
> so you can add it to the 7 or so I've counted so far.
> 
> Vlamidir, earlier you had many questions about the shorthand
> approach that I couldn't answer.  shorthand.el is less than 50 loc,
> it's reasonably easy to read.  It's very dumb, and doesn't do
> any fancy stuff, but it does solve the problem.  Obviously, a proper
> implementation wouldn't use advice, but proper interfaces.

Another problem with prefix-less imports is the semantic confusion. Lots 
of symbols are named such that their function is clear only in context 
of the package to which they belong. For example, tramp has 
tramp-syntax-values, tramp-prefix-format-alist, tramp-prefix-regexp, and 
tramp-error. Importing these symbols as just syntax-values, 
prefix-format-alist, prefix-regexp, and error and using them without 
further qualification would probably lead to confusion at reference 
sites. "Uh... prefix-regexp? Prefix of what? Where? Huh?"

If these symbols were instead imported as t:syntax-values, 
t:prefix-format-alist, t:prefix-regexp, and t:error, reference sites 
would be almost as clear as they are now (because the reader would ask 
himself "what does t: stand for?") while being much more terse.

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

[Vladimir Sedach]

João Távora <joaotavora@gmail.com> writes:
> Vlamidir, earlier you had many questions about the shorthand
> approach that I couldn't answer.  shorthand.el is less than 50 loc,
> it's reasonably easy to read.  It's very dumb, and doesn't do
> any fancy stuff, but it does solve the problem.  Obviously, a proper
> implementation wouldn't use advice, but proper interfaces.

I read your explanation for Richard in the other thread, that was
very helpful.

This seems like a good hack.

From my perspective, it seems more like an opt-in, per-file
preprocessor that does search-and-replace intelligently on symbols,
and leaves the pre-processing information around for elisp-mode to
handle xref etc., than anything to do with namespaces. That was the
cause of my confusion. If people want to deal with the drawbacks of
pre-processing, that's up to them. I have seen much worse
pre-processing done in Elisp packages.

I like it.

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

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

[Andrea Corallo]

Vladimir Sedach <vas@oneofus.la> writes:

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

E function defined with flet is in the lexical scope, here we are
talking about global variables.

Anyway an indirection more respect of what we have now is not needed, I
corrected myself here:

https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01305.html

  Andrea

-- 
akrl@sdf.org

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

[Vladimir Sedach]

Andrea Corallo <akrl@sdf.org> writes:
> E function defined with flet is in the lexical scope, here we are
> talking about global variables.

Well, the symbols are in the global obarray, but the namespace system
can resolve them to variable bindings in a lexical way.

When you first brought up the idea of namespacing over bindings, and
called your proposal lexspaces, I thought this would be similar to how
most (all?) Scheme module systems work: the namespace system resolves
symbols (globally visible an EQ) to bindings in a lexical way (scoped
to the module definition and resolvable at compile-time). The words
used were the same, and I assumed you were coming at this from a
Scheme angle.

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

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

[Andrea Corallo]

Vladimir Sedach <vas@oneofus.la> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>> E function defined with flet is in the lexical scope, here we are
>> talking about global variables.
>
> Well, the symbols are in the global obarray, but the namespace system
> can resolve them to variable bindings in a lexical way.
>
> When you first brought up the idea of namespacing over bindings, and
> called your proposal lexspaces, I thought this would be similar to how
> most (all?) Scheme module systems work: the namespace system resolves
> symbols (globally visible an EQ) to bindings in a lexical way (scoped
> to the module definition and resolvable at compile-time). The words
> used were the same, and I assumed you were coming at this from a
> Scheme angle.

I see what you mean.  I don't know Scheme and maybe we have a slightly
different language but AFAIU I think we are on the same page now.

-- 
akrl@sdf.org

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

[Helmut Eller]

On Fri, May 08 2020, Andrea Corallo 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.

On the page you asked "I don't know if other similar implementations
exists (I'd guess so) and I'd like or hear about those if someone are
aware".  MIT Scheme (and hence the Edwin editor) has "environments"[1]
which seem to similar to your lexicons.  But it's not well documented.

I believe, like Stefan, that a big problem is the use of symbols as
"designators" (to borrow Common Lisp terminology).  E.g. funcall works
on functions but also on symbols.  The symbol designates a (global)
function.  The same thing for faces: symbols are used to designate
faces, which only exist in C code.  XEmacs has actual face objects, but
almost everywhere where a face object is required a symbol can be used
too.

Maybe that problem could be (partially) solved by having an operator,
like:

     (resolve-designator NAME)

that returns the full symbol for NAME based on the currend lexical
environments.  This would be a pure compile-time operation, a bit like
macroexpand.  E.g. instead of 

  (define-key keymap (kdb "C-c C-c") 'myprefix-command)

one would then write

  (define-key keymap (kdb "C-c C-c") (resolve-designator command))

Of course, to be useful it would need a be shorter name or even be a
reader macro like #'.

Helmut

[1] http://git.savannah.gnu.org/cgit/mit-scheme.git/tree/src/runtime/environment.scm

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

[Andrea Corallo]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Fri, May 08 2020, Andrea Corallo 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.
>
> On the page you asked "I don't know if other similar implementations
> exists (I'd guess so) and I'd like or hear about those if someone are
> aware".  MIT Scheme (and hence the Edwin editor) has "environments"[1]
> which seem to similar to your lexicons.  But it's not well documented.
>
> I believe, like Stefan, that a big problem is the use of symbols as
> "designators" (to borrow Common Lisp terminology).  E.g. funcall works
> on functions but also on symbols.  The symbol designates a (global)
> function.  The same thing for faces: symbols are used to designate
> faces, which only exist in C code.  XEmacs has actual face objects, but
> almost everywhere where a face object is required a symbol can be used
> too.
>
> Maybe that problem could be (partially) solved by having an operator,
> like:
>
>      (resolve-designator NAME)
>
> that returns the full symbol for NAME based on the currend lexical
> environments.  This would be a pure compile-time operation, a bit like
> macroexpand.  E.g. instead of 

Yes it's an interesting problem.  Isn't sufficient to select the wanted
behavior to do as follow?

;; foo define in another Lexspace will use its definition of bar.
(foo #'bar)

;; This will use the definition in the current lexical enviroment instead.
(foo (symbol-function bar))

Thanks

  Andrea

-- 
akrl@sdf.org

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

[Helmut Eller]

On Sat, May 09 2020, Andrea Corallo wrote:

>> Maybe that problem could be (partially) solved by having an operator,
>> like:
>>
>>      (resolve-designator NAME)
>>
>> that returns the full symbol for NAME based on the currend lexical
>> environments.  This would be a pure compile-time operation, a bit like
>> macroexpand.  E.g. instead of 
>
> Yes it's an interesting problem.  Isn't sufficient to select the wanted
> behavior to do as follow?
>
> ;; foo define in another Lexspace will use its definition of bar.
> (foo #'bar)
>
> ;; This will use the definition in the current lexical enviroment instead.
> (foo (symbol-function bar))

I'm not sure that I understand you.

Just do make my point clear(er): functions that accept symbols
(e.g. face-name) don't know anything about the current lexical
environments of the caller.  symbol-function is one of them.  The only
sensible place where symbol-function could search is the global
environment.

Helmut 

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

[Andrea Corallo]

Helmut Eller <eller.helmut@gmail.com> writes:

> I'm not sure that I understand you.
>
> Just do make my point clear(er): functions that accept symbols
> (e.g. face-name) don't know anything about the current lexical
> environments of the caller.  symbol-function is one of them.  The only
> sensible place where symbol-function could search is the global
> environment.
>
> Helmut 

I start to see the issue.

If two libraries are using a symbol to communicate something shouldn't
the definition of this something be imported by both?

Say faces are defined in the 'face' Lexspace, the two libraries should
probably derive from it if they want to communicate using this
definitions.

There are maybe cases where the 'resolve-designator' operator you have
suggested would be necessary but I don't know how common would be that
case.

  Andrea

PS I think practically faces would be in the fundamental Lexspace where
every other is derived from.

-- 
akrl@sdf.org

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

[Dmitry Gutov]

On 09.05.2020 10:38, Helmut Eller wrote:
> Of course, to be useful it would need a be shorter name or even be a
> reader macro like #'.

FWIW, Clojure tries to solve this problem by having ` return 
fully-qualified symbols: 
https://stackoverflow.com/questions/17800917/clojure-difference-between-apostrophe-and-backtick

' returns "unqualified ones", and can be used inside ` forms to create 
"unqualified" elements in there.

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

[Helmut Eller]

On Sat, May 09 2020, Dmitry Gutov wrote:

> On 09.05.2020 10:38, Helmut Eller wrote:
>> Of course, to be useful it would need a be shorter name or even be a
>> reader macro like #'.
>
> FWIW, Clojure tries to solve this problem by having ` return
> fully-qualified symbols: 
> https://stackoverflow.com/questions/17800917/clojure-difference-between-apostrophe-and-backtick
>
> ' returns "unqualified ones", and can be used inside ` forms to create
> "unqualified" elements in there.

Interesting.  It's certainly useful to be able to write down lists
etc. that contain many symbols.  In Emacs we would probably not change
the existing backquote, but instead use something new like #`.

It seems[1] that in Clojure the symbol is resolved at read-time.  I'm
not sure that that is better than resolving it at macroexpand-time or
compile-time.

Helmut

[1] https://clojure.org/reference/reader#syntax-quote

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

[Dmitry Gutov]

On 09.05.2020 21:08, Helmut Eller wrote:

>> On 09.05.2020 10:38, Helmut Eller wrote:
>>> Of course, to be useful it would need a be shorter name or even be a
>>> reader macro like #'.
>>
>> FWIW, Clojure tries to solve this problem by having ` return
>> fully-qualified symbols:
>> https://stackoverflow.com/questions/17800917/clojure-difference-between-apostrophe-and-backtick
>>
>> ' returns "unqualified ones", and can be used inside ` forms to create
>> "unqualified" elements in there.
> 
> Interesting.  It's certainly useful to be able to write down lists
> etc. that contain many symbols.  In Emacs we would probably not change
> the existing backquote, but instead use something new like #`.

I don't know. It could. I imagine the backward compatibility argument 
would not exactly apply, given that the change would only affect code 
using the new namespaces system.

> It seems[1] that in Clojure the symbol is resolved at read-time.  I'm
> not sure that that is better than resolving it at macroexpand-time or
> compile-time.

Can't comment on that.

> Helmut
> 
> [1] https://clojure.org/reference/reader#syntax-quote
> 
> 

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

[Vladimir Sedach]

Hi Andrea,

The implementation reminds me of how Corman Common Lisp implements
thread-local dynamic binding, minus the chaining of bindings.

Here are some comments on the document:

> potentially could open the door to other interesting options like
> namespace versioning. Different version of the same library could
> then coexist loaded.

This is an interesting idea. In R6RS, library definitions and imports
include optional version information, but if you look at section 7.9
of the R6RS rationale document:

> Implementations are encouraged to prohibit two libraries with the
> same name but different versions to coexist within the same program.
> While this prevents the combination of libraries and programs that
> require different versions of the same library, it eliminates the
> potential for having multiple copies of a library's state

http://www.r6rs.org/final/html/r6rs-rationale/r6rs-rationale-Z-H-9.html

So it seems that the use of R6RS library version numbers is intended
for dependency management only.

I think the same reasoning applies to Elisp. For example, a package
could change the type of arguments it accepts for a customizable
variable. This recently happened in a few places in mu4e. Or a change
in the data structures used in some resource outside of the
namespace, such as a file somewhere on disk.

But versioning information could be used for dependency management if
shared between namespaces, require, and package.el

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