[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: Helmut Eller
Subject: Re: A prototype for a binding based approach to proper namespaces
Date: Sat, 09 May 2020 09:38:31 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

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

     (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 #'.



reply via email to

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