From: David De La Harpe Golden <david@harpegolden.net>
To: Emacs-devel@gnu.org
Subject: Re: is requiring cl bad?
Date: Thu, 20 Dec 2012 04:46:41 +0000 [thread overview]
Message-ID: <50D29831.9060408@harpegolden.net> (raw)
In-Reply-To: <87txrkfqcl.fsf@kuiper.lan.informatimago.com>
On 17/12/12 19:09, Pascal J. Bourguignon wrote:
>> 24.3 finally provides an alternative: `cl-lib' which offers the
>> same functionality but in a namespace-clean way (i.e. using a "cl-"
>> prefix everywhere).
>
> This is a silly solution.
> The right solution is to implement a package system.
>
The consistent-prefix approach may be a C-like solution, but is still
noticeably better than the previous conflicty mess, and widely
used for other emacs lisp libs.
But regarding the idea of "a package system" in particular, as you may
mean a system similar to common lisp "packages":
If emacs ever did go toward adding new facilities in the general area of
modularity (however unlikely it is in reality in the near future), I
reckon Ron Garret's common lisp land "lexicons" work [1] might be a
better "lispy modularity thingy" for emacs lisp to be inspired by than
common lisp packages in particular. At least, I'd take a hard look at
lexicons (and at least glance at what some other languages do), before
just blindly adding common lisp style packages.
Emacs lisp is lexically scoped now after all.
To people coming from quite a few other languages with more
[nowadays-]conventional module systems, lexicons might well seem less
weird than packages.
In emacs lisp land there is obviously no prior usage of common lisp
style packages in the first place (yes I am vaguely aware you can feck
about with non-default obarrays in emacs lisp for some purposes, but
meh), unlike the situation in common lisp land where inertia and compat
concerns will probably keep most people on packages anyway despite the
existence of lexicons there now.
[1] http://www.flownet.com/ron/lisp/lexicons.pdf
"""
Lexicons are first-class global lexical environments, what are sometimes
called "modules" or "namespaces" in other languages.
[...]
instead of mapping strings to symbols, lexicons map symbols to (global)
bindings.
"""
next prev parent reply other threads:[~2012-12-20 4:46 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 [this message]
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
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=50D29831.9060408@harpegolden.net \
--to=david@harpegolden.net \
--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).