Message from discussion Symbol pollution non-issue.
Received: by 10.204.156.210 with SMTP id y18mr499781bkw.7.1329597596861;
Sat, 18 Feb 2012 12:39:56 -0800 (PST)
From: RG <rNOSPA...@flownet.com>
Subject: Re: Symbol pollution non-issue.
Date: Sat, 18 Feb 2012 12:38:34 -0800
Organization: Amalgamated Widgets Unlimited
References: <email@example.com> <barmar-8BC135.firstname.lastname@example.org> <email@example.com> <rNOSPAMon-8889E3.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <rNOSPAMonemail@example.com> <9q9vlfFjjjU1@mid.individual.net> <rNOSPAMon-5A3ECE.firstname.lastname@example.org> <9qa52aFr9eU1@mid.individual.net> <rNOSPAMon-F96E5F.email@example.com> <9qac48Fic9U1@mid.individual.net>
X-Trace: news.albasani.net YPa2cYKldowJqQ8NET5lMzVFgTHLMtUw4OgGQ+WctY3CSyRXrh+0nGhk6WdWY77lwqwu2S2d6XrIJf4LD2mWTdoc9L2Eq15EOa1bTJrsVCsjvhlCM49Of6AoEGHVA7ng
NNTP-Posting-Date: Sat, 18 Feb 2012 20:38:36 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="9tXHP6Df5a8R5e1UpcQbygq8VLfIucVRsoHIThu6g13kYpSYxnJfiFIgRIXZIl4tV/q7ZeprsG0BMbbcsPGiyBCncyOMdx2F6kfl/sKJ2hU1WC8jrmdEpNEJDU9otQoh"; mail-complaints-to="ab...@albasani.net"
User-Agent: MT-NewsWatcher/3.5.1 (Intel Mac OS X)
Content-Type: text/plain; charset=UTF-8
In article <9qac48Fic...@mid.individual.net>,
Pascal Costanza <p...@p-cos.net> wrote:
> On 18/02/2012 19:07, RG wrote:
> > In article<9qa52aFr9...@mid.individual.net>,
> > Pascal Costanza<p...@p-cos.net> wrote:
> >> On 18/02/2012 18:09, RG wrote:
> >>> In article<9q9vlfFjj...@mid.individual.net>,
> >>> Pascal Costanza<p...@p-cos.net> wrote:
> >>>> If you argue for dropping the package system, and replacing it with
> >>>> something else, you need to provide an answer here...
> >>> I have NEVER argued for DROPPING the package system.
> >> So what are you arguing for?
> > http://rondam.blogspot.com/2010/02/new-and-improved-lexicons-now-50-lexier.h
> > tml
> I see. I wasn't aware (anymore) that you're suggesting a mapping between
> your lexicons to packages. Considering what you seem to think is the
> major problem with packages, this may still be overkill.
> A problem in the way how you word your concerns is that you describe the
> package system as fundamentally flawed, but the package system is
> actually not the source of the problem you have. It's rather a detail of
> how the read algorithm in Common Lisp works.
I guess it depends on your definition of "fundamentally flawed." The
whole point of having symbols in the first place is that they are
automatically constructed when reading Lisp source code. You can
construct a legal Lisp program without using the reader (except to
bootstrap the process) by doing something like this:
(let ((cl-package (find-package "COMMON-LISP"))
(my-package (or (find-package "foo" (make-package "foo")))))
(list (intern "DEFUN" cl-package) (intern "my-fun" my-package)
(list (intern "arg1" my-package) (intern "arg2" my-package) ...
So yes, it is technically true that my concern is (to a large extent)
about "a detail of how the read algorithm in Common Lisp works." But it
is IMHO a rather important detail.
> What you suggest under the link above is essentially a different read
> algorithm, where symbols that cannot be found are not automatically
> interned, but rather patched up in such a way that they find their
> actual definition later on during evaluation.
No. Lexicons use the standard Lisp reader algorithm.
Lexicons are not "better packages." They are fundamentally different
from packages. They map symbols (or to be strictly technically correct,
identifiers, which in CL happen to be symbols) onto bindings. Packages
map strings onto symbols. Lexicons are first-class global lexical
environments. Packages are hash tables from strings onto symbols.
Lexicons do what they do at macroexpand/compile time. Packages (mostly)
do what they do at read time. They are as different as two
computational concepts can be. If you do not see that then you do not
understand what lexicons are.
> (This reminds me of the
> delayed finalization of CLOS classes, which ensures that superclasses
> don't have to be fully defined when a defclass form is evaluated.)
Yes, delayed binding of lexical references is very similar to many other
forms of delayed binding in Lisp, and has many of the same advantages.
> I guess this way of patching up / delaying symbol interning can probably
> be provided without the need to build a whole package system replacement
> around it. This could even be a compatible extension of Common Lisp
> (which doesn't really specify which read algorithm to use in a
> read-eval-print-loop anyway, as far as I can tell).
Lexicons ARE a compatible extension to Common Lisp, since they are
implemented in (mostly) portable Common Lisp. (That this is possible is
a sterling credit to the overall design of the language.)
> It's confusing that you criticize the package system for something that
> it is ultimately not responsible for. What you should be criticizing is
> Section 2.3.4 of the HyperSpec.
The idea of the package system being "responsible" for anything strikes
me as a little bizarre.
What I am criticizing is one aspect of Common Lisp's design. It is an
aspect that involves elements of the reader, the package system, and
indeed the whole concept of symbols and symbolic programming (though I
don't often highlight that. I have learned over the years that one must
pick one's battles.)
The real fundamental problem, as succinctly as I can state it, is this:
state in general is bad software engineering practice, to be avoided
whenever possible (it's not always possible). GLOBAL state is even
worse and it is to be even more assiduously avoided. And global state
that is mutated by the language parser is a Really Bad Idea. It leads
to real problems of the sort that sends newbies to C.L.L. with the same
questions year in and year out, and makes the Idiots Guide to CL
Packages such a perennial best seller on the page rank circuit. It also
leads to experienced Lisp programmers arguing over whether they should
be writing :FOO or #:FOO or "FOO" in their defpackage forms.
Whether that is a criticism of packages or the reader or something else
is in the eye of the beholder, and in any case quite beside the point.
The point is: there's a problem. Reasonable people can disagree over
how serious this problem is or what (if anything) should be done about
it. But that there is a problem is undeniable. (Note that "there is no
problem" and "there is no problem FOR ME" are not equivalent statements.)