Received: by 10.204.156.210 with SMTP id y18mr499781bkw.7.1329597596861;
        Sat, 18 Feb 2012 12:39:56 -0800 (PST)
Path: t13ni43073bkb.0!nntp.google.com!news2.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!newshosting.com!news2.euro.net!news.mixmin.net!news.albasani.net!.POSTED!rNOSPAMon
From: RG <rNOSPA...@flownet.com>
Newsgroups: comp.lang.lisp
Subject: Re: Symbol pollution non-issue.
Date: Sat, 18 Feb 2012 12:38:34 -0800
Organization: Amalgamated Widgets Unlimited
Lines: 111
Message-ID: <rNOSPAMon-EEE41D.12383418022012@news.albasani.net>
References: <208471263350311915.117387tfb-tfeb.org@reader443.eternal-september.org> <barmar-8BC135.11440607022012@news.eternal-september.org> <675780956350327169.062709tfb-tfeb.org@reader443.eternal-september.org> <rNOSPAMon-8889E3.11213107022012@news.albasani.net> <jguqnk$gkc$2@z-news.wcss.wroc.pl> <20120217012534.632@kylheku.com> <rNOSPAMon-911025.11210217022012@news.albasani.net> <9q9vlfFjjjU1@mid.individual.net> <rNOSPAMon-5A3ECE.09093218022012@news.albasani.net> <9qa52aFr9eU1@mid.individual.net> <rNOSPAMon-F96E5F.10075218022012@news.albasani.net> <9qac48Fic9U1@mid.individual.net>
Mime-Version: 1.0
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)
Cancel-Lock: sha1:ecGsrqBEf+r1v0cQlb+0Net8glc=
X-Received-Bytes: 7161
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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.)

rg