unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Helmut Eller <eller.helmut@gmail.com>
To: emacs-devel@gnu.org
Subject: Re: is requiring cl bad?
Date: Fri, 21 Dec 2012 10:24:04 +0100	[thread overview]
Message-ID: <m2r4mj3gi3.fsf@gmail.com> (raw)
In-Reply-To: 50D40A3D.1020408@harpegolden.net

On Fri, Dec 21 2012, David De La Harpe Golden wrote:

> On 20/12/12 09:16, Helmut Eller wrote:
>
>> Have you actually taken a "hard look" at Ron Garret's lexicons?
>> What  was your experience?  I played with them a few years back, but I quickly
>> concluded that lexicons are only a crude prototype
>
> Well, the last version I looked much at was ~2.0 when he started to
> reuse packages extensively as part of the underlying implementation
> (something I disliked actually [1], but he saw lexicons as a complete
> replacement for packages, I remember in the CL case I would have
> preferred if they had been independent facilities (but my concerns
> about packages vs. lexicons in the CL cases /would not apply/ here in
> emacs land, because there are no packages))

Emacs symbols may not have packages but (funcall '<some-symbol>) is used
a lot in Emacs Lisp.  AFAICS, modules based on lexical scoping don't
handle this case, because funcall doesn't resolve the symbol to a module
binding.  Which module should be used at runtime?

>> and that it was never used in the "field"; not something I
>> would use.
>
> Not exactly mature, no - but hey, was new, shrug.  Anyway, there's
> presumably no way at his /implementation/ could be reused for emacs
> unless emacs was first made into a common lisp.
>
> However, I mentioned lexicons as something to look at for inspiration
> for a hypothetical emacs system: the quality of Ron's actual
> implementation for [C]CL is not of particular concern for that
> purpose, in fact you could avoid looking at it completely (though it
> appears to be liberally licensed) and just read the paper for that
> purpose.

Some ideas look nice on paper but when used in practice all sorts of
problems appear that aren't covered in the paper.  IMO lexicons fall
into that category.

>>> Emacs lisp is lexically scoped now after all.
>>
>> If you want Scheme-like modules based on lexical scoping you will also
>> need hygienic macros.  (Something that Common Lisp nicely avoids.)
>>
>
> Ron actually presented lexicons plus an escaping hack as an
> /alternative/ to scheme-style hygienic macros in his paper, mind, you
> may or may not be convinced that's better than a hygienic macro DSL,
> not sure I was.

Either way you need to resolve a symbol to the module binding.  So the
result of a macro must either contain the resolved binding (if you do
the resolution early) or the symbol plus the module (in some way) to
that the compiler can do the resolution.

> I figure implementation innards would need amendment regardless in the
> emacs case, practically if not in theory (I didn't mean to suggest
> lexicons be built on top of existing facilities at a purely lisp level
> or something in the emacs case, whereas despite CCL-isms, Ron used
> mostly portable CL)

I would not call this "mostly portable" because the compiler patch is
crucial and it was not even portable to the next version of the
compiler.

Helmut




  reply	other threads:[~2012-12-21  9:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-16  9:29 is requiring cl bad? Ivan Kanis
2012-12-16 10:14 ` Xue Fuqiao
2012-12-16 10:26   ` Pascal J. Bourguignon
2012-12-16 10:36     ` Xue Fuqiao
2012-12-16 11:00   ` Ivan Kanis
2012-12-16 17:06 ` Stefan Monnier
2012-12-17 19:09   ` Pascal J. Bourguignon
2012-12-18  1:58     ` Tony Day
2012-12-20  4:46     ` David De La Harpe Golden
2012-12-20  5:20       ` Ivan Kanis
2012-12-20  9:16       ` Helmut Eller
2012-12-21  7:05         ` David De La Harpe Golden
2012-12-21  9:24           ` Helmut Eller [this message]
2012-12-17 20:58   ` Ivan Kanis
2012-12-18  4:04     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2r4mj3gi3.fsf@gmail.com \
    --to=eller.helmut@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).