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

[Andrea Corallo]

Helmut Eller <address@hidden> 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

-- 
address@hidden