Hi,
lots of my code is defined in CL-USER package. Now I think this is not such a good idea. I stumbled
across the following:
CL-USER 1 > (defun foo (&key test) t)
FOO
CL-USER 2 > (defpackage :cl-test (:export :test))
#<PACKAGE CL-TEST>
CL-USER 3 > (use-package :cl-test)
Error: Using package CL-TEST results in a name conflict for this symbol: TEST.
1 (continue) Unintern the conflicting symbol from its home package.
2 Shadow the conflicting symbols.
3 Shadowing-import the conflicting symbol already visible in COMMON-LISP-USER.
4 Shadowing-import the conflicting symbol from CL-TEST.
5 Skip using CL-TEST by COMMON-LISP-USER.
6 (abort) Return to level 0.
7 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
CL-USER 4 : 1 >
Should one always use packages, even if I don't know if or what I will ever export from that
package, just to avoid such conflicts (which are no real conflicts)?
Andreas
"Andreas Thiele" <··········@nospam.com> writes:
> CL-USER 1 > (defun foo (&key test) t)
> FOO
>
> CL-USER 2 > (defpackage :cl-test (:export :test))
> #<PACKAGE CL-TEST>
>...
> Should one always use packages, even if I don't know if or what I will ever export from that
> package, just to avoid such conflicts (which are no real conflicts)?
Yes.
And, in fact, it is a real conflict. You have a conflict between the
symbol CL-USER::TEST and CL-TEST::TEST. These are distinct symbols,
which is why there is a conflict. The reader would not be able to tell
which of those two objects you meant when parsing the name "TEST", if
they are both visible in the same package.
--
Thomas A. Russ, USC/Information Sciences Institute
"Andreas Thiele" <··········@nospam.com> writes:
> Should one always use packages, even if I don't know if or what I
> will ever export from that package, just to avoid such conflicts
> (which are no real conflicts)?
Yes.
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
"Andreas Thiele" <··········@nospam.com> writes:
> CL-USER 1 > (defun foo (&key test) t)
> FOO
>
> CL-USER 2 > (defpackage :cl-test (:export :test))
> #<PACKAGE CL-TEST>
>
> CL-USER 3 > (use-package :cl-test)
>
> Error: Using package CL-TEST results in a name conflict
> for this symbol: TEST.
>
> Should one always use packages, even if I don't know if or what I
> will ever export from that package, just to avoid such conflicts
> (which are no real conflicts)?
Your real problem here is failing to use the package before you use
it. Hmm. That probably sounds more circular than is meant. Don't do
any work in the package [your DEFUN above] before you declare you're
going to [the call to USE-PACKAGE above].
Personally, I do not recommend ever doing USE-PACKAGE on an existing
package interactively as you've done. I would rather see you
construct a suitable package to work in and then do IN-PACKAGE. e.g.,
in the above example, you'd change the USE-PACKAGE to an IN-PACKAGE
and add a (:use :cl) [and possibly other packages there] to the
DEFPACKAGE.
"Kent M Pitman" <······@nhplace.com> schrieb im Newsbeitrag ··················@nhplace.com...
> "Andreas Thiele" <··········@nospam.com> writes:
>
> > CL-USER 1 > (defun foo (&key test) t)
> > FOO
> >
> > CL-USER 2 > (defpackage :cl-test (:export :test))
> > #<PACKAGE CL-TEST>
> >
> > CL-USER 3 > (use-package :cl-test)
> >
> > Error: Using package CL-TEST results in a name conflict
> > for this symbol: TEST.
> >
> > Should one always use packages, even if I don't know if or what I
> > will ever export from that package, just to avoid such conflicts
> > (which are no real conflicts)?
>
> Your real problem here is failing to use the package before you use
> it. Hmm. That probably sounds more circular than is meant. Don't do
> any work in the package [your DEFUN above] before you declare you're
> going to [the call to USE-PACKAGE above].
>
> Personally, I do not recommend ever doing USE-PACKAGE on an existing
> package interactively as you've done. I would rather see you
> construct a suitable package to work in and then do IN-PACKAGE. e.g.,
> in the above example, you'd change the USE-PACKAGE to an IN-PACKAGE
> and add a (:use :cl) [and possibly other packages there] to the
> DEFPACKAGE.
After re-reading "The Complete Idiot's Guide To Common Lisp Packages" by Erann Gat things seem a bit
clearer to me. My intuition fooled me. I though that
(defun foo (&key test) t)
will only intern a symbol 'foo in the current package which can lead to conflicts. Thus I wondered
about a conflicting symbol 'test. Obviously a misunderstanding. 'test is also interned as well as
all function parameters possibly appearing elsewhere in the current package.
Now if I understand things right, I simply do the following:
(defpackage :cl-test (:use :common-lisp) (:export :test))
... some code (especially my function 'test) ...
(defpackage :my-app (:use :common-lisp :cl-test))
(in-package :my-app)
(defun foo (&key test) t)
or in other words (my own recapitulation) use-package expresses package dependencies and has to
appear before the definition of 'foo regardless to which package 'foo might belong. This way I don't
run into the conflict.
Thanks, Andreas
In article <···············@news.t-online.com>,
"Andreas Thiele" <··········@nospam.com> wrote:
> "Kent M Pitman" <······@nhplace.com> schrieb im Newsbeitrag
> ··················@nhplace.com...
> > "Andreas Thiele" <··········@nospam.com> writes:
> >
> > > CL-USER 1 > (defun foo (&key test) t)
> > > FOO
> > >
> > > CL-USER 2 > (defpackage :cl-test (:export :test))
> > > #<PACKAGE CL-TEST>
> > >
> > > CL-USER 3 > (use-package :cl-test)
> > >
> > > Error: Using package CL-TEST results in a name conflict
> > > for this symbol: TEST.
> > >
> > > Should one always use packages, even if I don't know if or what I
> > > will ever export from that package, just to avoid such conflicts
> > > (which are no real conflicts)?
> >
> > Your real problem here is failing to use the package before you use
> > it.
Actually, it appears that the real problem was a failure to understand
how the reader processes symbols (or, to put it another way, a failure
to understand that symbols are interned by the reader and not the
evaluator):
> I though[t] that
>
> (defun foo (&key test) t)
>
> will only intern a symbol 'foo ...
At the risk of beating a dead horse, I will make a point that I have
made before and gotten roundly beaten up for, but I'll raise it again
because I think it is relevant in light of the recent discussion taking
place in the "beyond CL" thread. (Cameron Mackinnon is making similar
points and getting predictably beaten up for it, so I feel duty-bound to
come to his aid.)
The claim has been made that nothing in Common Lisp is fundamentally
broken. I disagree. CL is missing a feature, namely, first-class
top-level lexical scopes, what in T were called "locales", what in
modern functional programming languages are called "modules." Because
CL does not have modules/locales, people try to use the package system
instead, but packages are fundamentally unsuitable for this purpose (as
evidenced by the perennial confusion that they cause when people try to
use them in the way that Andreas has done).
Locales can be added to CL as a user-level construct (as demonstrated by
my paper presented at ILC03) but only with considerable difficulty, and
at the cost of undermining useful vendor-specific features (because
adding locales requires redefining/shadowing DEFUN, DEFVAR, etc.) In
this sense I submit that CL is fundamentally deficient in a way that can
only be addressed by changing (or at least augmenting) the standard.
Ron Garret f.k.a. Erann Gat
Ron Garret <·········@flownet.com> writes:
> The claim has been made that nothing in Common Lisp is fundamentally
> broken.
Where was this claim made?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <·············@franz.com>, Duane Rettig <·····@franz.com>
wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > The claim has been made that nothing in Common Lisp is fundamentally
> > broken.
>
> Where was this claim made?
http://groups-beta.google.com/group/comp.lang.lisp/msg/ceb61b77c306347d
"So far as I know, no one has shown that CL is so broken in its core
that fixing it requires revisiting the original standard. "
rg
Ron Garret <·········@flownet.com> writes:
> In article <·············@franz.com>, Duane Rettig <·····@franz.com>
> wrote:
>
> > Ron Garret <·········@flownet.com> writes:
> >
> > > The claim has been made that nothing in Common Lisp is fundamentally
> > > broken.
> >
> > Where was this claim made?
>
> http://groups-beta.google.com/group/comp.lang.lisp/msg/ceb61b77c306347d
>
> "So far as I know, no one has shown that CL is so broken in its core
> that fixing it requires revisiting the original standard. "
I agree with Kent that the CL standard is not so broken as to warrant
trying to open up the ANSI process. In fact, the majority of the
Lisp community seems to agree with this statement; when Steve Haflich
was looking for members to sign up to keep the committee alive and
to discuss visiting the spec at least for the purposes of cleanup,
barely enough people signed up to keep a quorum; apparently the
potential to clean things up was not worth the $600 USD per year (or
whatever the membership fee is) that was required to fix such
brokenness.
However, I disagree with your implication that this statement
constitutes the assertion that nothing in the CL spec is
fundamentally broken. All the statement really means is that not
enough is broken to warrant opening up the very painful ANSI
process again. In light of potentially much-less-painful processes,
if they become viable, the brokenness might cross the threshold of
action. Meanwhile, those of us still in the Common Lisp industry
still use the spec to advantage despite its apparent brokenness...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> [...] when Steve Haflich
> was looking for members to sign up to keep the committee alive and
> to discuss visiting the spec at least for the purposes of cleanup,
> barely enough people signed up to keep a quorum; apparently the
> potential to clean things up was not worth the $600 USD per year (or
> whatever the membership fee is) that was required to fix such
> brokenness.
In some ways, it's a good thing that over-priced $600 fee is there to
get people thinking about cost. But the real cost is in time away
from other work, travel, etc. for voting members--not even to mention
the full time work of at least an editor and probably the full or part
time work of other essential staff like the committee chair and
vice-chair. The cost of the ANSI CL standard ran conservatively to
just shy of half a million dollars in easy to spot real dollars spent,
not even counting the dollars spent by companies to pay salaries of
people reviewing the document, writing contributed sections, attending
meetings, etc. Very little of that cost was membership fees. :)
> However, I disagree with your implication that this statement
> constitutes the assertion that nothing in the CL spec is
> fundamentally broken.
I concur with Duane's analysis here.
> All the statement really means is that not
> enough is broken to warrant opening up the very painful ANSI
> process again. In light of potentially much-less-painful processes,
> if they become viable, the brokenness might cross the threshold of
> action. Meanwhile, those of us still in the Common Lisp industry
> still use the spec to advantage despite its apparent brokenness...
Right. Just for a concrete example, there's some really dumb text in
the definition of PROG2 that says it does what PROG1 does.
http://www.lispworks.com/documentation/HyperSpec/Body/m_prog1c.htm#prog1
Surely that's broken. But is it enough broken to pay huge quantities of
dollars to fix it through ANSI? Or can we just get by with saying
"that's a typo, ok?" Until something of a reasonably significant pain
is found, we're trying to encourage people not to overspend and to
bankrupt the entire community in a quest for perfection.
To repeat my oft-used chant: What stands between this community and
commercial success is not..... [today's answer:] fixing typos in the spec.
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> Duane Rettig <·····@franz.com> writes:
>
> > [...] when Steve Haflich
> > was looking for members to sign up to keep the committee alive and
> > to discuss visiting the spec at least for the purposes of cleanup,
> > barely enough people signed up to keep a quorum; apparently the
> > potential to clean things up was not worth the $600 USD per year (or
> > whatever the membership fee is) that was required to fix such
> > brokenness.
>
> In some ways, it's a good thing that over-priced $600 fee is there to
> get people thinking about cost. But the real cost is in time away
> from other work, travel, etc. for voting members--not even to mention
> the full time work of at least an editor and probably the full or part
> time work of other essential staff like the committee chair and
> vice-chair. The cost of the ANSI CL standard ran conservatively to
> just shy of half a million dollars in easy to spot real dollars spent,
> not even counting the dollars spent by companies to pay salaries of
> people reviewing the document, writing contributed sections, attending
> meetings, etc. Very little of that cost was membership fees. :)
>
> > However, I disagree with your implication that this statement
> > constitutes the assertion that nothing in the CL spec is
> > fundamentally broken.
>
> I concur with Duane's analysis here.
>
> > All the statement really means is that not
> > enough is broken to warrant opening up the very painful ANSI
> > process again. In light of potentially much-less-painful processes,
> > if they become viable, the brokenness might cross the threshold of
> > action. Meanwhile, those of us still in the Common Lisp industry
> > still use the spec to advantage despite its apparent brokenness...
>
> Right. Just for a concrete example, there's some really dumb text in
> the definition of PROG2 that says it does what PROG1 does.
> http://www.lispworks.com/documentation/HyperSpec/Body/m_prog1c.htm#prog1
> Surely that's broken. But is it enough broken to pay huge quantities of
> dollars to fix it through ANSI? Or can we just get by with saying
> "that's a typo, ok?" Until something of a reasonably significant pain
> is found, we're trying to encourage people not to overspend and to
> bankrupt the entire community in a quest for perfection.
>
> To repeat my oft-used chant: What stands between this community and
> commercial success is not..... [today's answer:] fixing typos in the spec.
Yes, I agree with both you and Duane. However, I also believe that
given that the ANSI process is not cost effective (at the moment) it
ought to be replaced by a different process that is more cost effective.
Surely in the age of the internet we can invent an amendment process
that, e.g. does not require travel and is therefore less overtly
expensive. But this we as a community (or you as a community -- I'm not
sure if my membership is still active) have failed to do. We have not
dispensed with one process in favor of a different process, we have
dispensed with one process in favor of no process at all, and that's not
good.
(The process you suggest, Kent:
> If you can't get someone to implement it, at least work out in excruciating
> and rigrous detail what it would look like and then put a paper on the web
> or submit it to a Lisp conference to provoke discussion.
doesn't work. I did exactly this in 2003, and the ensuing discussion
lasted until the end of my 45 minute presentation. But the real problem
is not really the lack of interest in locales per se. The real problem
is that having presented the idea at ILC there is no subsequent
mechanism for the community to speak with one voice and say "yay verily
we believe this is a good idea, we christen it CLRFI #123, and we grant
it "approved" status", or, "yay verily, this idea sucketh big fat
honking weenies and deserves to be relegated to the most obscure and
foul smelling dustbin of history." Or some such thing.)
The last time I suggested this (back in 2003) the response was that you
(Kent) were working on such a process, one that you called
"substandards". I responded by observing that substandards were, at
least at the time, "vaporware", and was promptly pilloried for using
that term. But I felt vindicated when I just now visited
substandards.org.
Please note that I have no quarrel with the lack of progress on
substandards in and of itself. What I object to is your having grabbed
a lock on the (meta-)process -- by announcing substandards, claiming a
trademark on the term (of dubious validity but that's a topic for
another day), and consistently criticizing anyone who advocates for
(meta-)change -- and failing to make progress while holding that lock.
In that respect you have IMO done a disservice to the community.
rg
Ron Garret <·········@flownet.com> writes:
> However, I also believe that given that the ANSI process is not cost
> effective (at the moment) it ought to be replaced by a different
> process that is more cost effective.
C'mon. Where else will $600 bucks buy this level of grief?
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > However, I also believe that given that the ANSI process is not cost
> > effective (at the moment) it ought to be replaced by a different
> > process that is more cost effective.
>
> C'mon. Where else will $600 bucks buy this level of grief?
Heh, on Usenet you can get it for free. (Reminds me of the old Monty
Python sketch. "Hello, I'd like to have an argument please.")
rg
Ron Garret <·········@flownet.com> writes:
> In article <·············@nhplace.com>,
> Kent M Pitman <······@nhplace.com> wrote:
>
> (The process you suggest, Kent:
>
> > If you can't get someone to implement it, at least work out in excruciating
> > and rigrous detail what it would look like and then put a paper on the web
> > or submit it to a Lisp conference to provoke discussion.
>
> doesn't work. I did exactly this in 2003, and the ensuing discussion
> lasted until the end of my 45 minute presentation. But the real problem
> is not really the lack of interest in locales per se. The real problem
> is that having presented the idea at ILC there is no subsequent
> mechanism for the community to speak with one voice and say "yay verily
> we believe this is a good idea, we christen it CLRFI #123, and we grant
> it "approved" status", or, "yay verily, this idea sucketh big fat
> honking weenies and deserves to be relegated to the most obscure and
> foul smelling dustbin of history." Or some such thing.)
>
> The last time I suggested this (back in 2003) the response was that you
> (Kent) were working on such a process, one that you called
> "substandards". I responded by observing that substandards were, at
> least at the time, "vaporware", and was promptly pilloried for using
> that term. But I felt vindicated when I just now visited
> substandards.org.
>
> Please note that I have no quarrel with the lack of progress on
> substandards in and of itself. What I object to is your having grabbed
> a lock on the (meta-)process -- by announcing substandards, claiming a
> trademark on the term (of dubious validity but that's a topic for
> another day), and consistently criticizing anyone who advocates for
> (meta-)change -- and failing to make progress while holding that lock.
> In that respect you have IMO done a disservice to the community.
>
Theres nothing stopping you from identifying a big enough constituency
of paying customers who then demand their desired improvements from
their vendors.
There is also nothing stopping you from taking one of the open source
Lisps, adding whatever it is you like and selling the community on it
because the improvements are so great, which will then filter down to
the vendors pretty quickly. If the user community doesn't really care
about the improvements, then you have saved everyone the effort of a
standards procedure which would not have contributed anything useful.
I should think both alternatives are much easier, cheaper and faster
than a formal standards procedure.
Gregm
In article <··············@athena.pienet>,
Greg Menke <············@toadmail.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <·············@nhplace.com>,
> > Kent M Pitman <······@nhplace.com> wrote:
> >
> > (The process you suggest, Kent:
> >
> > > If you can't get someone to implement it, at least work out in
> > > excruciating
> > > and rigrous detail what it would look like and then put a paper on the
> > > web
> > > or submit it to a Lisp conference to provoke discussion.
> >
> > doesn't work. I did exactly this in 2003, and the ensuing discussion
> > lasted until the end of my 45 minute presentation. But the real problem
> > is not really the lack of interest in locales per se. The real problem
> > is that having presented the idea at ILC there is no subsequent
> > mechanism for the community to speak with one voice and say "yay verily
> > we believe this is a good idea, we christen it CLRFI #123, and we grant
> > it "approved" status", or, "yay verily, this idea sucketh big fat
> > honking weenies and deserves to be relegated to the most obscure and
> > foul smelling dustbin of history." Or some such thing.)
> >
> > The last time I suggested this (back in 2003) the response was that you
> > (Kent) were working on such a process, one that you called
> > "substandards". I responded by observing that substandards were, at
> > least at the time, "vaporware", and was promptly pilloried for using
> > that term. But I felt vindicated when I just now visited
> > substandards.org.
> >
> > Please note that I have no quarrel with the lack of progress on
> > substandards in and of itself. What I object to is your having grabbed
> > a lock on the (meta-)process -- by announcing substandards, claiming a
> > trademark on the term (of dubious validity but that's a topic for
> > another day), and consistently criticizing anyone who advocates for
> > (meta-)change -- and failing to make progress while holding that lock.
> > In that respect you have IMO done a disservice to the community.
> >
>
> Theres nothing stopping you from identifying a big enough constituency
> of paying customers who then demand their desired improvements from
> their vendors.
>
> There is also nothing stopping you from taking one of the open source
> Lisps, adding whatever it is you like and selling the community on it
> because the improvements are so great, which will then filter down to
> the vendors pretty quickly. If the user community doesn't really care
> about the improvements, then you have saved everyone the effort of a
> standards procedure which would not have contributed anything useful.
>
> I should think both alternatives are much easier, cheaper and faster
> than a formal standards procedure.
All true, but neither of these alternatives produces the result that I
seek, namely, a way for the Lisp community to speak definitively as a
community about changes to the language.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@athena.pienet>,
> Greg Menke <············@toadmail.com> wrote:
>> I should think both alternatives are much easier, cheaper and faster
>> than a formal standards procedure.
>
> All true, but neither of these alternatives produces the result that I
> seek, namely, a way for the Lisp community to speak definitively as a
> community about changes to the language.
Ron, having participated in c.l.l. for as many years as you have, do
you really think that the "Lisp community" can "speak definitively as
a community" on any topic whatsoever?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
In article <··············@gigamonkeys.com>,
Peter Seibel <·····@gigamonkeys.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@athena.pienet>,
> > Greg Menke <············@toadmail.com> wrote:
>
> >> I should think both alternatives are much easier, cheaper and faster
> >> than a formal standards procedure.
> >
> > All true, but neither of these alternatives produces the result that I
> > seek, namely, a way for the Lisp community to speak definitively as a
> > community about changes to the language.
>
> Ron, having participated in c.l.l. for as many years as you have, do
> you really think that the "Lisp community" can "speak definitively as
> a community" on any topic whatsoever?
First it should be noted (and I am far from the first to make this
observation) that c.l.l. and the "Lisp community" are not synonymous.
But that having been said, the answer to your question is: not as things
stand, no. But that is because they (we?) have chosen not to, not
because we (they?) are fundamentally incapable of doing so.
rg
Ron Garret <·········@flownet.com> wrote:
>All true, but neither of these alternatives produces the result that I
>seek, namely, a way for the Lisp community to speak definitively as a
>community about changes to the language.
A standards committee doesn't codify things that don't yet exist.
That's simply the wrong body to talk to, then.
mkb.
In article <··············@news.dfncis.de>,
Matthias Buelow <···@incubus.de> wrote:
> Ron Garret <·········@flownet.com> wrote:
>
> >All true, but neither of these alternatives produces the result that I
> >seek, namely, a way for the Lisp community to speak definitively as a
> >community about changes to the language.
>
> A standards committee doesn't codify things that don't yet exist.
> That's simply the wrong body to talk to, then.
Huh? Locales (merely to illustrate the point) have existed for
twenty-five years. They have existed in Common Lisp for two years.
rg
Ron Garret <·········@flownet.com> wrote:
>Huh? Locales (merely to illustrate the point) have existed for
>twenty-five years. They have existed in Common Lisp for two years.
Shipped with at least one "mainstream" (if such a thing exists)
Lisp system and in frequent use? Or hidden somewhere as a research
paper+sample code on someone's website?
mkb.
Greg Menke wrote:
> ...
> Theres nothing stopping you from identifying a big enough constituency
> of paying customers who then demand their desired improvements from
> their vendors.
>
> There is also nothing stopping you from taking one of the open source
> Lisps, adding whatever it is you like and selling the community on it
> because the improvements are so great, which will then filter down to
> the vendors pretty quickly. If the user community doesn't really care
> about the improvements, then you have saved everyone the effort of a
> standards procedure which would not have contributed anything useful.
>
> I should think both alternatives are much easier, cheaper and faster
> than a formal standards procedure.
but will they have the desired effect? most of the complaints about
missing standards i have seen so far concern features that are available
in most (all?) implementations, though not compatible among those
implementations. this reduces the incentive for the users to adopt the
new (sub?)standard (why bother learning something new that doesn't offer
extra functionality?), hence the likelihood for the new standard to be
implemented by the vendor (our customers aren't going to use it anyways)
hs
Hartmann Schaffer <··@hartmann.schaffernet> writes:
> Greg Menke wrote:
>> ...
>> Theres nothing stopping you from identifying a big enough constituency
>> of paying customers who then demand their desired improvements from
>> their vendors. There is also nothing stopping you from taking one
>> of the open source
>> Lisps, adding whatever it is you like and selling the community on it
>> because the improvements are so great, which will then filter down to
>> the vendors pretty quickly. If the user community doesn't really care
>> about the improvements, then you have saved everyone the effort of a
>> standards procedure which would not have contributed anything useful.
>> I should think both alternatives are much easier, cheaper and faster
>> than a formal standards procedure.
>
> but will they have the desired effect? most of the complaints about
> missing standards i have seen so far concern features that are
> available in most (all?) implementations, though not compatible among
> those implementations. this reduces the incentive for the users to
> adopt the new (sub?)standard (why bother learning something new that
> doesn't offer extra functionality?), hence the likelihood for the new
> standard to be implemented by the vendor (our customers aren't going
> to use it anyways)
Well, some users are interested in writing code that will run on more
than one implementation. So they're interested in seeing vendors
smooth out gratuitous differences. And certainly I'd expect that
vendors would keep their old APIs for some time so if you don't care
about other implementations you can keep using the old API>
And vendors--at least the commercial ones--are presumably interested
in growing the overall Lisp pie without giving up the things that make
their implementations unique. So it might be in their interest to try
and make Common Lisp easier to adopt so folks don't come check out
Lisp and then give up because the answer to seemingly simple questions
like, how do I open a socket in Common Lisp is "it depends".
However, to the extent that most Lispers are currently using a single
implementation and are satisfied with it, and most vendors care mostly
about satisfying the needs of their existing customers, there's little
motivation for anyone to spend much time or effort trying to
smooth-out cross-implementation differences. If that's the state we're
in, it's possible that the vendors are being short-sighted by focusing
too much on their existing customers at the cost of losing potential
customers. Or maybe, given the relatively high number of
implementations, including several whose implementors are not
necessarily driven by a desire for commercial success, the cost of
trying to coordinate between vendors is simply too high, even if such
coordination would yield relatively large benefits.
The saving grace may be that we're talking about Lisp--a lot of things
that would absolutely require vendor support in other languages can be
accomplished in userland in Lisp. Folks who want their code to be
source compatible between implementations can probably accomplish that
through portability libraries that have little to no runtime cost and
that don't require the vendors to do any work at all. And such
libraries could be listed on the Schmoe List (see other posts in this
thread) and everything would be good. But, as with the Schmoe List, it
requires people who believe they would benefit from better portability
between Lisps, to step up and do the work of writing, documenting, and
maintaining the portability libraries.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Ron Garret <·········@flownet.com> writes:
> > If you can't get someone to implement it, at least work out in excruciating
> > and rigrous detail what it would look like and then put a paper on the web
> > or submit it to a Lisp conference to provoke discussion.
>
> doesn't work. I did exactly this in 2003, and the ensuing discussion
> lasted until the end of my 45 minute presentation. But the real problem
> is not really the lack of interest in locales per se.
I'm not so sure.
> The real problem is that having presented the idea at ILC there is
> no subsequent mechanism for the community to speak with one voice
I don't think the community has one voice.
> and say "yay verily
> we believe this is a good idea, we christen it CLRFI #123, and we grant
> it "approved" status",
What will approve status buy you?
I'm not big on christening/blessing software. certifying for
correctness, etc.--sure. but not just blesshing the abstract
goodness. I think people should use what they like and not use what
they don't, and I don't see why the blessing of any organization is
going to help that.
substandards (mentioned below) was explicitly NEVER a consensus process.
it was a documentation process. there is a big difference. what you have
done by publishing a conference paper has the same effect as what the
substandards process i envisioned would buy you--it would not assure you
implementation. it would assure that anyone who wanted to know what someone
was babbling about when they mentioned something by name could find out.
in many ways, the web offers this already, but it wouldn't be the first time
someone consolidated information on a site that could as well be distributed.
> or, "yay verily, this idea sucketh big fat
> honking weenies and deserves to be relegated to the most obscure and
> foul smelling dustbin of history." Or some such thing.)
And, by symmetry, what will this tell you?
just becuase certain people tell you they don't like something doesn't
mean there aren't others who do. that's why I think consensus is
wrong for many things. consensus is needed when it's something
everyone needs to share. it's good there is basic consensus on the
core of cl. libraries don't require consensus. they just require
doing, and documenting. or documenting, and doing. (the order might
matter and might differ.) in the modern world, linking three different
ways to do something is not prohibitive like it once would... so why
waste time fighting over things that can just play well together.
let everyone use the things they like and be done with it?
> The last time I suggested this (back in 2003) the response was that you
> (Kent) were working on such a process, one that you called
> "substandards". I responded by observing that substandards were, at
> least at the time, "vaporware", and was promptly pilloried for using
> that term. But I felt vindicated when I just now visited
> substandards.org.
Feel vindicated if you like. All you're really being happy about is
that I had a bunch of personal financial problems that delayed me. If
you want to claim that proves that I had no intent to carry through,
feel free. If you think I've encouraged Nick Levine that he shouldn't
go ahead with CLRFI, I suggest you ask him first. Not only am I glad
someone is addressing the gap, but I also think he isn't doing the
intended to do (and still intend, incidentally, unless someone does it
first) so while we compete in some way, we don't compete in others.
And until I get my system out, we don't compete at all. He just does
something cool and that's that.
> Please note that I have no quarrel with the lack of progress on
> substandards in and of itself. What I object to is your having grabbed
> a lock on the (meta-)process -- by announcing substandards, claiming a
> trademark on the term (of dubious validity but that's a topic for
> another day),
(It's a requirement of trademark law to claim it from first use or you
cannot claim it at all. Don't hassle me about the way the law works.)
But anyway, nothing says you have to have that name to do the action you
want. There are lots of names out there. You've always had the right to
pick another if you wanted to even if I was claiming to be the single way
to do this.
(You have really no idea how much I want to do this and how much it hurts
me not to have the financial resources to just blow off all other things and
do it. But life is full of trade-offs and I'm bumbling through life the
best I can.)
Nor has anyone approached me saying they had a plan for moving the
process forward and did I want to collaborate or offer use of the name
or whatever, so I find it a bit hard to believe I'm keeping anyone
from getting anything done.
I think the blame you place on me is unfair, but you're welcome to think
otherwise. Do you want me to apologize for the financial difficulties I've
had that have kept me from carrying through? I hereby apologize to you
that I've had to feed my family and work a day job and so on.
Do you want me to claim I've given up just because I've taken longer than
I said I would? I haven't given up. I'm not hyping it thse days so as
not to give false hope. But if you think it doesn't come up on my schedule
on a regular basis internally every week or two even now, you're wrong.
I will not apologize for continuing to care. I will not yield my desire
to do it merely because it's taking longer. If you or anyone wants to fund
the effort, I'll take it seriously. But while I'm having to fund it,
I'll take the time I need.
Incidentally, two people did offer chunks of funding, neither enough to
complete the project. Each meaningful in their own way to me personally.
I don't want to leave the impression that no one cared. But I do want to
leave the impression that money is a key to success and when there's
insufficient money, a process can fail.
This, incidentally, is a major reason I argue against a return to ANSI.
ANSI is expensive. If we start an ANSI process and fail, it doesn't mean
Lisp is dead, but overcoming the bad press that would come of such a process
folding would, I bet, take decades.
> and consistently criticizing anyone who advocates for
> (meta-)change -- and failing to make progress while holding that lock.
> In that respect you have IMO done a disservice to the community.
There is no lock.
(That's the WHOLE point of substandards, as you'll see if/when I get time
away from having to keep bills paid to do it.)
Even within the past day or two you've perhaps seen me in the midst of
a heated discussion with Peter Siebel on another thread stop and say
that while I disagree with him on certain details of it, I think it's
great as a meta-process that he's seeking informal agreement on
various interesting points in file system stuff...
I've not critiqued advocates for meta-change. I've encouraged it.
I've merely suggested it happen by layered standards (monotonic
improvement upward). The reason for that is exactly that it can be done
without perturbing others.
I've critiqued the idea of returning to ANSI. I've suggested that people
shouldn't use standards as a club to get vendors to implement things they
don't already have an inclination to implement. I don't like those kinds
of change not because it competes with anything I've wanted to do but because
I find it undesirable that the community should have to change to accommodate
such upgrades...
You seem to be (mis)characterizing everything I'm doing as force.
I see it as just the opposite.
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> > But the real problem
> > is not really the lack of interest in locales per se.
>
> I'm not so sure.
I've included the above snippet not because I want to respond to it (I
have no idea how to convince you that you're wrong about my motives, and
it doesn't really matter to me anyway) but because it's relevant to a
later response. See below.
> > The real problem is that having presented the idea at ILC there is
> > no subsequent mechanism for the community to speak with one voice
>
> I don't think the community has one voice.
Yes. That would be precisely the point I am trying to make.
> > and say "yay verily
> > we believe this is a good idea, we christen it CLRFI #123, and we grant
> > it "approved" status",
>
> What will approve status buy you?
This question is ambiguous in light of your earlier questioning of my
motives. It could mean, "What would obtaining 'approved' status of your
own work buy you?" Or it could mean, "What would the existence of an
'approved' status for various substandards(tm) buy you?"
The answer to the first question is: absolutely nothing, except possibly
a warm fuzzy feeling. (There was a time when it might have bought me a
resume item, but I have changed careers.)
The answer to the second question is: an easier time selling CL (not
that this is really a concern for me personally any more, since I'm no
longer in the business of selling CL. But having spent a significant
chunk of my life trying to sell CL and experiencing firsthand the
problems and frustrations that attend such an endeavor I still have a
soft spot in my heart for those who are still engaged in this activity,
and for those who, like me, believe that (meta-)change will help make
this easier, and so I make the time to fire the odd salvo in the debate.)
> I'm not big on christening/blessing software.
I know, and from a technical point of view I sympathize. But from a
business point of view I think this stance is a colossal mistake. (I'm
not alone in this. See http://www.paulgraham.com/road.html, the section
on "releases".)
> substandards (mentioned below) was explicitly NEVER a consensus process.
I'm not advocating for consensus. I'm advocating for definitiveness.
> it was a documentation process. there is a big difference. what you have
> done by publishing a conference paper has the same effect as what the
> substandards process i envisioned would buy you--it would not assure you
> implementation. it would assure that anyone who wanted to know what someone
> was babbling about when they mentioned something by name could find out.
> in many ways, the web offers this already, but it wouldn't be the first time
> someone consolidated information on a site that could as well be distributed.
And that would be a big step forward IMO.
> > or, "yay verily, this idea sucketh big fat
> > honking weenies and deserves to be relegated to the most obscure and
> > foul smelling dustbin of history." Or some such thing.)
>
> And, by symmetry, what will this tell you?
> just becuase certain people tell you they don't like something doesn't
> mean there aren't others who do. that's why I think consensus is
> wrong for many things.
You really are laboring under a very severe misconception about what I
am advocating. I am not advocating for consensus. You put that word in
my mouth. (I did say "speak with one voice", but that is not the same
as consensus, though I can see how you might have interpreted it that
way. Perhaps I should have said, "speak definitively about changes in
the state of the language.")
> consensus is needed when it's something everyone needs to share.
That's not true, but it's beside the point, except to point out that you
are still thinking about this in technical terms, and what I'm talking
about is PR.
> it's good there is basic consensus on the
> core of cl. libraries don't require consensus. they just require
> doing, and documenting. or documenting, and doing. (the order might
> matter and might differ.) in the modern world, linking three different
> ways to do something is not prohibitive like it once would... so why
> waste time fighting over things that can just play well together.
> let everyone use the things they like and be done with it?
Because many important things don't play well together in the CL world
at the moment.
> > The last time I suggested this (back in 2003) the response was that you
> > (Kent) were working on such a process, one that you called
> > "substandards". I responded by observing that substandards were, at
> > least at the time, "vaporware", and was promptly pilloried for using
> > that term. But I felt vindicated when I just now visited
> > substandards.org.
>
> Feel vindicated if you like. All you're really being happy about is
Feeling vindicated is not all the same as feeling happy. Believe me, I
am in no sense happy about any aspect of this situation. (That was a
major factor in my decision to change careers.)
> that I had a bunch of personal financial problems that delayed me. If
> you want to claim that proves that I had no intent to carry through,
> feel free.
I make no such claim, and I take no joy from your financial
difficulties. Quite the opposite.
> If you think I've encouraged Nick Levine that he shouldn't
> go ahead with CLRFI, I suggest you ask him first.
My concern is not with Nick. My concern is with all the people who now
have to make a choice between using CLRFI or waiting for substandards.
It's not unlike the situation with VHS and Beta (or to pick a more
contemporary example, blu-ray and HD-DVD).
> > Please note that I have no quarrel with the lack of progress on
> > substandards in and of itself. What I object to is your having grabbed
> > a lock on the (meta-)process -- by announcing substandards, claiming a
> > trademark on the term (of dubious validity but that's a topic for
> > another day),
>
> (It's a requirement of trademark law to claim it from first use or you
> cannot claim it at all. Don't hassle me about the way the law works.)
>
> But anyway, nothing says you have to have that name to do the action you
> want. There are lots of names out there. You've always had the right to
> pick another if you wanted to even if I was claiming to be the single way
> to do this.
Hopefully it is clear now why this would not help.
> > and consistently criticizing anyone who advocates for
> > (meta-)change -- and failing to make progress while holding that lock.
> > In that respect you have IMO done a disservice to the community.
>
> There is no lock.
That may not have been your intent, but I think it has that effect.
Certainly it had that effect two years ago when some people were saying,
"substandards(tm) are just right around the corner."
> I've not critiqued advocates for meta-change. I've encouraged it.
> I've merely suggested it happen by layered standards (monotonic
> improvement upward). The reason for that is exactly that it can be done
> without perturbing others.
That's not been my impression, but perhaps I've just misunderstood.
> You seem to be (mis)characterizing everything I'm doing as force.
> I see it as just the opposite.
No, I just think that your stature in the community is such that, like
it or not, what you say has a lot of impact.
rg
Ron Garret <·········@flownet.com> writes:
> > I'm not big on christening/blessing software.
>
> I know, and from a technical point of view I sympathize. But from a
> business point of view I think this stance is a colossal mistake. (I'm
> not alone in this. See http://www.paulgraham.com/road.html, the section
> on "releases".)
But I'm not saying people shouldn't. I'm saying that suppressing
software that is not blessed is not better.
Let me make an analogy to medicine. Do you think the world is served by
having the FDA prohibit drugs that don't meet its standards? I understand
why they do it, but I don't agree with it. I'm ok with the FDA wanting to
label things it approves as ok, but I'm ot ok with it trying to suppress
things that it doesn't think are ok. Some people don't trust the FDA.
Some people have other theories. Some things the FDA keeps out are quackery,
and I'd feel bad for anyone taking them. But some things they keep out are
done for political reasons or for lack of data, but might still be important.
And it seems hard to achieve the wisdom to say.
So I think it's fine if you want to get someone to bless your code.
Let me say differently that what I don't like is the blessing of blessing
agencies, as if there were a canonical one.
> > substandards (mentioned below) was explicitly NEVER a consensus process.
>
> I'm not advocating for consensus. I'm advocating for definitiveness.
If I tell you my home page is http://www.nhplace.com/kent/ is that not
definitive? How would an agency blessing my home page make it more
definitive?
Put another way: what is it that you think is lacking in definitiveness
when you post a pointer to locales and some people use it and others don't?
> > it was a documentation process. there is a big difference. what
> > you have done by publishing a conference paper has the same effect
> > as what the substandards process i envisioned would buy you--it
> > would not assure you implementation. it would assure that anyone
> > who wanted to know what someone was babbling about when they
> > mentioned something by name could find out. in many ways, the web
> > offers this already, but it wouldn't be the first time someone
> > consolidated information on a site that could as well be
> > distributed.
>
> And that would be a big step forward IMO.
In some ways, I hope it will be. I wouldn't do it otherwise.
At the same time, I don't see that it has to be unique. So if the CLRFI
process offers a similar facility, then maybe it won't be a big step forward
it will be a small one forward, or a small one sideways, or some may say a
small one backwards. I think competition in the marketplace helps.
> > > or, "yay verily, this idea sucketh big fat
> > > honking weenies and deserves to be relegated to the most obscure and
> > > foul smelling dustbin of history." Or some such thing.)
> >
> > And, by symmetry, what will this tell you?
> > just becuase certain people tell you they don't like something doesn't
> > mean there aren't others who do. that's why I think consensus is
> > wrong for many things.
>
> You really are laboring under a very severe misconception about what I
> am advocating. I am not advocating for consensus. You put that word in
> my mouth. (I did say "speak with one voice", but that is not the same
> as consensus,
It's probably one of several ways I was confused. It's YOU that I think
should speak with one voice. And me. And any group of people that wants
to elect a leader. But not "the community" because it is special. The
only things that should speak with one voice are (a) individuals or (b)
sets that one can opt out of in order to dissent from the "one voice".
Since one cannot opt out of "the community", it's special and should not
be allowed to speak as if it had one voice except in the unlikely event
that you can (a) enumerate "all people" and (b) assure that those
"all people" agree.
> though I can see how you might have interpreted it that
> way. Perhaps I should have said, "speak definitively about changes in
> the state of the language.")
This is a key issue also. I believe "the language" is a finished
base. Further libraries need not be the language. I don't want
certain things I expect people to make libraries out of to be "in the
language", while the people producing those probably don't want others
(perhaps mine). Rather than haggling over this, I think it's simpler
to say that the language is not up for grabs in that way.
> > consensus is needed when it's something everyone needs to share.
>
> That's not true, but it's beside the point, except to point out that you
> are still thinking about this in technical terms, and what I'm talking
> about is PR.
PR can be done notwithstanding any of this. Someone can claim CLRFI
or Wiki is part of CL for PR. Geez, people claim Scheme is part of
Lisp for PR, though when Schemers post here about it we sent them to
comp.lang.scheme...
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > > I'm not big on christening/blessing software.
> >
> > I know, and from a technical point of view I sympathize. But from a
> > business point of view I think this stance is a colossal mistake. (I'm
> > not alone in this. See http://www.paulgraham.com/road.html, the section
> > on "releases".)
>
> But I'm not saying people shouldn't. I'm saying that suppressing
> software that is not blessed is not better.
I have never advocated suppressing anything. You are attacking a straw
man.
> So I think it's fine if you want to get someone to bless your code.
> Let me say differently that what I don't like is the blessing of blessing
> agencies, as if there were a canonical one.
Yes, this is our fundamental disagreement. I think that canonization
has value. The ANSI CL spec is a shining example.
> > > substandards (mentioned below) was explicitly NEVER a consensus process.
> >
> > I'm not advocating for consensus. I'm advocating for definitiveness.
>
> If I tell you my home page is http://www.nhplace.com/kent/ is that not
> definitive? How would an agency blessing my home page make it more
> definitive?
A poor analogy. Your home page is yours alone. There is no community
associated with it.
> Put another way: what is it that you think is lacking in definitiveness
> when you post a pointer to locales and some people use it and others don't?
A non-sequitur. This isn't about locales (notwithstanding your
conviction that this is all just a big ego trip for me).
> At the same time, I don't see that it has to be unique. So if the CLRFI
> process offers a similar facility, then maybe it won't be a big step forward
> it will be a small one forward, or a small one sideways, or some may say a
> small one backwards. I think competition in the marketplace helps.
Yes, but I believe that the CL community is nowhere near big enough to
constitute a viable marketplace unto itself. CL would do better, I
claim, if the CL community were to consider itself an organization
rather than a marketplace, competing with other organizations (like "the
Java community" or "the PERL community") in the larger IT marketplace,
than to have factions within CL consider themselves organizations
competing with each other within the CL marketplace.
BTW, these two points of view are not mutually exclusive. One can take
an organizational posture with respect to the outside world without
abandoning internal competition.
> It's probably one of several ways I was confused. It's YOU that I think
> should speak with one voice. And me. And any group of people that wants
> to elect a leader.
I would say, "any group that wants to take advantage of the economic
benefits offered by cooperation and group cohesiveness." Electing a
leader is not a prerequisite to cooperation.
> But not "the community" because it is special. The
> only things that should speak with one voice are (a) individuals or (b)
> sets that one can opt out of in order to dissent from the "one voice".
> Since one cannot opt out of "the community", it's special and should not
> be allowed to speak as if it had one voice except in the unlikely event
> that you can (a) enumerate "all people" and (b) assure that those
> "all people" agree.
Of course one can opt out of the community. Think about it: if it's not
possible to opt out, who decides who is and who is not a member?
> This is a key issue also. I believe "the language" is a finished
> base. Further libraries need not be the language.
That is certainly true. What I am saying is that the community (by
which I mean some poorly specified group of people) would derive
economic benefit if they were.
> I don't want
> certain things I expect people to make libraries out of to be "in the
> language", while the people producing those probably don't want others
> (perhaps mine). Rather than haggling over this, I think it's simpler
> to say that the language is not up for grabs in that way.
Yes, it is certainly simpler, but simplicity is not always an unalloyed
good.
> > > consensus is needed when it's something everyone needs to share.
> >
> > That's not true, but it's beside the point, except to point out that you
> > are still thinking about this in technical terms, and what I'm talking
> > about is PR.
>
> PR can be done notwithstanding any of this.
Certainly. But why hobble yourself? Microsoft has to spend zillions of
dollars trying to convince the world that it innovates. Google spends
zero. It will be much easier to convince people that CL is keeping up
with the times if we have more to point at than just a bunch of
open-source development projects.
rg
Ron Garret <·········@flownet.com> writes:
> I am not advocating for consensus. You put that word in my mouth.
> (I did say "speak with one voice", but that is not the same as
> consensus, though I can see how you might have interpreted it that
> way. Perhaps I should have said, "speak definitively about changes
> in the state of the language.")
What do you mean by "speak definitively"? Do you have some process in
mind that you believe could lead to definitive statements from "the
community"?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
In article <··············@gigamonkeys.com>,
Peter Seibel <·····@gigamonkeys.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > I am not advocating for consensus. You put that word in my mouth.
> > (I did say "speak with one voice", but that is not the same as
> > consensus, though I can see how you might have interpreted it that
> > way. Perhaps I should have said, "speak definitively about changes
> > in the state of the language.")
>
> What do you mean by "speak definitively"? Do you have some process in
> mind that you believe could lead to definitive statements from "the
> community"?
Yes, though it's a moot point until the community (or a community)
decides that this would actually be a desirable outcome. There seems to
be a significant portion of the Lisp community that actually likes the
current anarchic/free-market state of affairs, and I'm through swimming
upstream.
(The process I have in mind works something like the mod point system on
slashdot, or Google's pagerank, except there would be a "reviewer rank"
instead. We used a similar system successfully in the Google
translation console to filter out translation spam.)
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@gigamonkeys.com>,
> Peter Seibel <·····@gigamonkeys.com> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > I am not advocating for consensus. You put that word in my
>> > mouth. (I did say "speak with one voice", but that is not the
>> > same as consensus, though I can see how you might have
>> > interpreted it that way. Perhaps I should have said, "speak
>> > definitively about changes in the state of the language.")
>>
>> What do you mean by "speak definitively"? Do you have some process
>> in mind that you believe could lead to definitive statements from
>> "the community"?
>
> Yes, though it's a moot point until the community (or a community)
> decides that this would actually be a desirable outcome. There
> seems to be a significant portion of the Lisp community that
> actually likes the current anarchic/free-market state of affairs,
> and I'm through swimming upstream.
Hmmm. In this case, it might be easier to convince folks that it's a
desirable outcome if they could see more clearly what you're
advocating. Abstractions such as "the community" and "speaking
definitively" may give folks the heebie-jeebies where the actual
specifics of what you think would be a good idea wouldn't bother
anyone and might even be applauded. Seems like the only way to
determine whether there's a community that's interested in something
is to start down a path and, after you've gone a little ways, turn
around and see if anyone's following you. (Have you ever stood on the
sidewalk and tried to get a group of more than three people to pick a
place to go for lunch? Everyone agrees that eating lunch is a
desirable outcome. But if you wait for everybody to agree on a place
to go before you start moving chances are good that you'll starve to
death. The choice is made when someone says, "Hey, I'm going to
Fredie's for bugers, who's with me" and starts walking. At which point
either the community coaleses around that idea and goes to lunch. Or,
if there is no real community, the group splinters into several groups
that each go their own way. But nobody starves. And that's just a
half-dozen folks making a relatively trivial decision. My guess, is
there's no way you're going to get a mob like "the Lisp community" to
all agree, in advance, to move in a specific direction in a hugely
multi-dimensional space without someone taking the initiative to
actually blaze the trail and show others what it looks like.)
> (The process I have in mind works something like the mod point
> system on slashdot, or Google's pagerank, except there would be a
> "reviewer rank" instead. We used a similar system successfully in
> the Google translation console to filter out translation spam.)
Sounds interesting. And also quite a bit different from what I
imagined you meant by the community speaking definitively with one
voice or whatever. Anyway, I'd be interested to hear more about what
you have in mind.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
In article <··············@gigamonkeys.com>,
Peter Seibel <·····@gigamonkeys.com> wrote:
> Sounds interesting. And also quite a bit different from what I
> imagined you meant by the community speaking definitively with one
> voice or whatever. Anyway, I'd be interested to hear more about what
> you have in mind.
I haven't thought it through in any more detail than I've already
described it, but if I get a chance to do so I'll post the results.
rg
Some time back, Kent M Pitman wrote:
> Feel vindicated if you like. All you're really being happy about is
> that I had a bunch of personal financial problems that delayed me. If
> you want to claim that proves that I had no intent to carry through,
> feel free. If you think I've encouraged Nick Levine that he shouldn't
> go ahead with CLRFI, I suggest you ask him first...
Uhm, nobody has asked me about this, so I'll just set the record
straight and say that kmp and I discussed this issue briefly about a
year ago and we agreed that there was no conflict of interest. Kent did
nothing to discourage me / us, and in fact has permitted us to use a
"powered by lisp" logo from his hypermeta site.
- nick
Ron Garret <·········@flownet.com> writes:
> CL is missing a feature, namely, first-class
> top-level lexical scopes, what in T were called "locales", what in
> modern functional programming languages are called "modules." Because
> CL does not have modules/locales, people try to use the package system
> instead, but packages are fundamentally unsuitable for this purpose (as
> evidenced by the perennial confusion that they cause when people try to
> use them in the way that Andreas has done).
Agreed.
--
~jrm
Ron Garret <·········@flownet.com> wrote on Tue, 26 Jul 2005:
> CL is missing a feature, namely, first-class top-level lexical scopes, what
> in T were called "locales", what in modern functional programming languages
> are called "modules." Because CL does not have modules/locales, people try
> to use the package system instead, but packages are fundamentally
> unsuitable for this purpose
FWIW, this idea sounds promising. I certainly wouldn't object to its being
fleshed out and proposed as an enhancement to ANSI Common Lisp.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
At a book burning, don't leave too soon, or you might miss the dictionaries.
-- Deep Thoughts, by Jack Handey [1999]
In article <··············@sidious.geddis.org>,
Don Geddis <···@geddis.org> wrote:
> Ron Garret <·········@flownet.com> wrote on Tue, 26 Jul 2005:
> > CL is missing a feature, namely, first-class top-level lexical scopes, what
> > in T were called "locales", what in modern functional programming languages
> > are called "modules." Because CL does not have modules/locales, people try
> > to use the package system instead, but packages are fundamentally
> > unsuitable for this purpose
>
> FWIW, this idea sounds promising. I certainly wouldn't object to its being
> fleshed out and proposed as an enhancement to ANSI Common Lisp.
>
> -- Don
So how do I go about proposing it?
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@sidious.geddis.org>,
> Don Geddis <···@geddis.org> wrote:
>
> > Ron Garret <·········@flownet.com> wrote on Tue, 26 Jul 2005:
> > > CL is missing a feature, namely, first-class top-level lexical scopes, what
> > > in T were called "locales", what in modern functional programming languages
> > > are called "modules." Because CL does not have modules/locales, people try
> > > to use the package system instead, but packages are fundamentally
> > > unsuitable for this purpose
> >
> > FWIW, this idea sounds promising. I certainly wouldn't object to its being
> > fleshed out and proposed as an enhancement to ANSI Common Lisp.
> >
> > -- Don
>
> So how do I go about proposing it?
Same as anything else:
Figure out what you want it to do. Spec it out to at least your
own satisfaction.
Figure out if you can implement it yourself as a user. If you can, do so.
If you can't, figure out if you can implement it in either a free
CL where you have access to sources or talk a vendor into why it's
important enough to implement.
Following on previous discussion about why it is that language changes
get argued against, the one thing that I am constantly on the lookout
for and that I suspect/hope others are as well, is the idea that
people who haven't been able to convince anyone that something is
useful will use as a court of last resort the idea of just sticking
the pet idea into a standard and hoping that will "force" others to
pay attention. (The vague analog to people in the "real world" using
Government as a club for implementing social change they can't get to
happen another way.)
In most cases, good ideas don't require force to get people to try.
Forcing people who don't need something to implement it anyway adds
expense to everyone. The better alternative, in cyberspace at least,
is just to make your own playground (as the Python people did, and as
Paul Graham has done with Arc within the Lisp community) and see if you
can get people to go there.
This issue was a recurring theme in the CL design and is a reason that
"current practice" (i.e., status of having been implemented, tested,
etc.) was featured prominently in the charter, in the cleanup issue
templates, and in the willingness of many people who voted to actually
vote yes.
If you can't get someone to implement it, at least work out in excruciating
and rigrous detail what it would look like and then put a paper on the web
or submit it to a Lisp conference to provoke discussion.
>> > Ron Garret <·········@flownet.com> wrote on Tue, 26 Jul 2005:
>> > > CL is missing a feature, namely, first-class top-level lexical scopes,
>> > > what in T were called "locales", what in modern functional programming
>> > > languages are called "modules."
>> Don Geddis <···@geddis.org> wrote:
>> > FWIW, this idea sounds promising. I certainly wouldn't object to its
>> > being fleshed out and proposed as an enhancement to ANSI Common Lisp.
> Ron Garret <·········@flownet.com> writes:
>> So how do I go about proposing it?
Kent M Pitman <······@nhplace.com> wrote on Wed, 27 Jul 2005:
> Figure out what you want it to do. Spec it out to at least your
> own satisfaction.
> Figure out if you can implement it yourself as a user. If you can, do so.
> If you can't, figure out if you can implement it in either a free
> CL where you have access to sources or talk a vendor into why it's
> important enough to implement.
It seems to me that a good model for this, and a topic fairly close to your
module idea, is system definitions. That's also not part of the ANSI CL spec,
and yet desired by almost any programmer of significant CL systems.
Very early on, MK:DEFSYSTEM got implemented, passed around, and became a
de facto expectation, if not quite a standard. And there's even a competitor:
ASDF:DEFSYSTEM is quite popular these days. Such layered "standards" didn't
require changing the ANSI CL spec, but are so useful that some implementations
(such as CMUCL) automatically include them in the basic lisp image.
Is there any reason that your idea couldn't follow the path of DEFSYSTEM?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
I don't think God put me on this planet to judge others. I think he put me on
this planet to gather specimens and take them back to my home planet.
-- Deep Thoughts, by Jack Handey
In article <··············@sidious.geddis.org>,
Don Geddis <···@geddis.org> wrote:
> >> > Ron Garret <·········@flownet.com> wrote on Tue, 26 Jul 2005:
> >> > > CL is missing a feature, namely, first-class top-level lexical scopes,
> >> > > what in T were called "locales", what in modern functional programming
> >> > > languages are called "modules."
>
> >> Don Geddis <···@geddis.org> wrote:
> >> > FWIW, this idea sounds promising. I certainly wouldn't object to its
> >> > being fleshed out and proposed as an enhancement to ANSI Common Lisp.
>
> > Ron Garret <·········@flownet.com> writes:
> >> So how do I go about proposing it?
>
> Kent M Pitman <······@nhplace.com> wrote on Wed, 27 Jul 2005:
> > Figure out what you want it to do. Spec it out to at least your
> > own satisfaction.
> > Figure out if you can implement it yourself as a user. If you can, do so.
> > If you can't, figure out if you can implement it in either a free
> > CL where you have access to sources or talk a vendor into why it's
> > important enough to implement.
>
> It seems to me that a good model for this, and a topic fairly close to your
> module idea, is system definitions. That's also not part of the ANSI CL
> spec,
> and yet desired by almost any programmer of significant CL systems.
>
> Very early on, MK:DEFSYSTEM got implemented, passed around, and became a
> de facto expectation, if not quite a standard. And there's even a
> competitor:
> ASDF:DEFSYSTEM is quite popular these days. Such layered "standards" didn't
> require changing the ANSI CL spec, but are so useful that some
> implementations
> (such as CMUCL) automatically include them in the basic lisp image.
>
> Is there any reason that your idea couldn't follow the path of DEFSYSTEM?
Of course not, but you're missing the point. This isn't about locales.
I don't care if they are adopted or not (well, that's not quite true --
it would be nice to see them adopted, but that's not the point). I am
just using the locales experience as an illustration. I could just as
easily have made the same point with mk:defsystem actually, but I'm not
nearly as familiar with its history, so it's easier for me to use my own
experience. I'm less likely to get tripped up by simple ignorance.
Consider:
http://www.python.org/doc/current/modindex.html
This page is one of Python's big selling points, I claim. Here you can
find, all gathered in one place, a very large collection of (evolving)
extensions to Python that have been in some sense "blessed" by the
Python community. (Python has the advantage of having a benevolent
dictator at the helm, which makes it easier for them to do this, but
that too is beside the point.) Actually, what you find there is not the
extensions themselves, but *specifications*. CL has nothing analogous.
CL only has anarchy and free market forces resulting in "emergent" de
facto standards in varying degrees of de factoness. Python has all that
too, but, crucially, it also has a mechanism for saying "Yey verily."
CL does not. And this is bad for CL IMO because it makes it harder for
newbies (and non-newbies for that matter) to assess the current state of
things, yada yada yada.
rg
Ron Garret <·········@flownet.com> writes:
> Consider:
>
> http://www.python.org/doc/current/modindex.html
>
> This page is one of Python's big selling points, I claim. Here you
> can find, all gathered in one place, a very large collection of
> (evolving) extensions to Python that have been in some sense
> "blessed" by the Python community.
Well, have they been blessed by "the Python community" or by "someone
smallish group of individuals the Python community respects"? I think
it's the latter and I think that's good news for Common Lisp. Because
that means that *anyone* could establish such a list for Common Lisp
libraries and say "I bless these libraries." Then others could second
the blessing by saying, "Hey, you're looking for libraries, go check
out the list at <mumble>."
As you point out, Python has a recognized benevolent dictator for all
things Pythonic. But you say this is beside the point and I agree. If
Guido (or his duly authorized deputies) decide to bless certain
libraries that blessing automatically carries some weight but that's
the only difference. While Common Lisp has no single dictator, I don't
think that's a problem. If Joe or Josephine Schmoe, who nobody has
heard of, makes a Lisp library list nobody may care initially. But if
they carry through and build a useful list, with good documentation in
a consistent format, etc. I suspect they will soon have the respect of
enough Lispers to put plenty of facto in their de facto
standards. People will then get to say "Yea, verily" by virtue of
pointing other people to the Schmoe List. Soon a Google search for
"common lisp libraries" will return the Schmoe List as the #1 result
(currently it's the Wikipedia entry on Common Lisp followed by the
projects page at common-lisp.net).
The only thing that is required is for someone or a small number of
people with a shared vision to build the Schmoe List either from
scratch or by volunteering to enhance an existing list such as the
common-lisp.net projects page. But however it happens, it's going to
be work that someone has to do. What I don't see is that there's
anything stopping someone who wants to do the work for getting
started. Heck, it's probably not even necessary for one person to do
all the work--if someone sets up a reasonable framework for other
people to contribute (e.g. specify a common format for documentation),
I imagine others might be glad of the chance to contribute without
having to set up the whole thing themselves. Look at the success of
the Wikipedia for an inspiring example.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> If Joe or Josephine Schmoe, who nobody has
> heard of, makes a Lisp library list nobody may care initially. But if
> they carry through and build a useful list, with good documentation in
> a consistent format, etc. I suspect they will soon have the respect of
> enough Lispers to put plenty of facto in their de facto
> standards. People will then get to say "Yea, verily" by virtue of
> pointing other people to the Schmoe List. Soon a Google search for
> "common lisp libraries" will return the Schmoe List as the #1 result
> (currently it's the Wikipedia entry on Common Lisp followed by the
> projects page at common-lisp.net).
While better than the current situation, I hope that this isn't what
comes to pass.
What if there's only one frob-foo library, and it sucks? Should it make
the list? Putting it on the list may well discourage others from writing
or distributing better frob-foo libraries. If a better frob-foo is made,
should it replace the original in the list? If so, people who have coded
to "best practices" suddenly have orphan code (this may happen in any
event, nothing is perfect forever). If it is merely added to the list,
then we have today's situation, with a website.
As well, people who make website lists tend to want to make them
all-inclusive, which is faster and easier than scrutinizing every entry
(even assuming a small group of people can possibly have expertise in
everything), and much less grief than what's going to happen in at least
some of the "your code sucks, so I'm not listing it" cases.
In short, I doubt an individual would want the grief that would come
with being a judge of quality and, absent such a judge, the list could
well be near useless, or worse. Quality judgements are easier to accept,
and to make, if they're made by a group.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
> Peter Seibel wrote:
>
>> If Joe or Josephine Schmoe, who nobody has
>> heard of, makes a Lisp library list nobody may care initially. But if
>> they carry through and build a useful list, with good documentation in
>> a consistent format, etc. I suspect they will soon have the respect of
>> enough Lispers to put plenty of facto in their de facto
>> standards. People will then get to say "Yea, verily" by virtue of
>> pointing other people to the Schmoe List. Soon a Google search for
>> "common lisp libraries" will return the Schmoe List as the #1 result
>> (currently it's the Wikipedia entry on Common Lisp followed by the
>> projects page at common-lisp.net).
>
> While better than the current situation, I hope that this isn't what
> comes to pass.
What do you propose?
> What if there's only one frob-foo library, and it sucks? Should it
> make the list? Putting it on the list may well discourage others
> from writing or distributing better frob-foo libraries. If a better
> frob-foo is made, should it replace the original in the list? If so,
> people who have coded to "best practices" suddenly have orphan code
> (this may happen in any event, nothing is perfect forever). If it is
> merely added to the list, then we have today's situation, with a
> website.
Well, there are a couple way I think having the list would help. For
starters the list (as I imagine it) would set certain minimum criteria
as far as having thing documented in a standard way, installable in a
standard way (or at least in one of a small number of standard ways),
etc. If a library has a maintainer who is willing to do the work to
meet those criteria, I'd guess that it's unlikely that the library
will *totally* suck. (Usually libraries "suck" becuase they are
unfinished or intentionally incomplete, written to solve one
particular part of a problem without addressing all the ways a
frob-foo library is actually likely to be used. I doubt someone would
bother documenting and making installable such a partial library.)
Also, if a list of libraries contains many good libraries, it may act
as a motivation for folks to bring their own libraries up to par. And
finally, assuming--as I do--that such a list would be focused entirely
or largely on open-source libraries, if a library sucks, it can be
fixed.
> As well, people who make website lists tend to want to make them
> all-inclusive, which is faster and easier than scrutinizing every
> entry (even assuming a small group of people can possibly have
> expertise in everything), and much less grief than what's going to
> happen in at least some of the "your code sucks, so I'm not listing
> it" cases.
>
> In short, I doubt an individual would want the grief that would come
> with being a judge of quality and, absent such a judge, the list could
> well be near useless, or worse.
Well, I did mention it would be work, no doubt about it. But I can't
imagine that taking personal responsibility for making judgements and
living by the consequences of them is harder than, say, implementing
Common Lisp. Yet there are numerous open source Common Lisp
implementations. So surely it's possible.
> Quality judgements are easier to accept, and to make, if they're
> made by a group.
So perhaps someone interested in maintaining such a list should first
enlist a few folks they think are smart and reasonable folks to work
with. But there's a big difference between getting a small group of
people together to buck up each other's spirits and waiting until
*everyone* can agree on some process for agreeing.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> Well, I did mention [a judged library list] would be work, no doubt about it. But I can't
> imagine that taking personal responsibility for making judgements and
> living by the consequences of them is harder than, say, implementing
> Common Lisp. Yet there are numerous open source Common Lisp
> implementations. So surely it's possible.
Possible, certainly. But these are vastly different skill sets. People
aren't likely to take my decision to create a new CL personally, but if
I start judging THEIR software, you can bet that there will be hard
feelings. For me, the psychic rewards of creating a CL implementation
would be greater than those of creating a web catalog, and the grief
would be less. Which isn't to say that maintaining a site like this
wouldn't appeal to anyone. But if I may say so, in as small a community
as ours, the type of person who would shrug off the likely grief
associated with the job (or worse, enjoy telling people that their code
isn't up to snuff) might well be a borderline psychopath.
Not everything can, or ought, to be solved with libraries. Your proposal
regarding handling of UNIX pathnames is one example. As well, I see
libraries as the wrong solution for problems such as TCP socket API
incompatibility: A compatibility layer on top of a bunch of slightly
different implementations is a good userspace workaround to a problem
which should be solved at the implementation level. And what of Kent's
example of the typo in ANSI's PROG2 definition? Surely something can be
cobbled together to say "As regards 4.3.2.1, which is inconsistent, it
is generally accepted that the committee ought to have said ..., and
most modern implementations work as if that were the case."
> So perhaps someone interested in maintaining such a list should first
> enlist a few folks they think are smart and reasonable folks to work
> with. But there's a big difference between getting a small group of
> people together to buck up each other's spirits and waiting until
> *everyone* can agree on some process for agreeing.
I don't think everyone needs to agree; that's not what consensus means
[umm... to me. Ironically, http://www.answers.com/consensus&r=67 shows
that there's no consensus on the word's meaning. Delicious.] If a small
group of people form a proposal, ask for public comment, then take a
public straw poll, that might well be enough to convince vendors to
implement the proposal.
For some issues, an ad hoc group of as few as two (well placed) people
could do the trick: "We, as implementors of Lisps A and B, wish to stop
the foolishness. Henceforth, we will be compatible with implementation C
as regards API X. After all, most people seem to use the API via a
C-COMPAT library anyway." That might be enough for other Lisps'
maintainers to say "Us too." It would be a bonus if the package name to
be standardized didn't look like a vendor specific one...
I don't think we need to reopen ANSI and I don't think we need
unanimity. Ad hoc addressing of a few issues would be nice, but, since
I'm sure that various people have a different set of top issues they'd
like fixed, I'd like to see a process and some progress. Certainly for
some of the issues, consensus could well have been reached with less
discussion and heat than has been generated merely by my (and others')
claim that progress is needed.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
> Peter Seibel wrote:
>
>> Well, I did mention [a judged library list] would be work, no doubt about it. But I can't
>> imagine that taking personal responsibility for making judgements and
>> living by the consequences of them is harder than, say, implementing
>> Common Lisp. Yet there are numerous open source Common Lisp
>> implementations. So surely it's possible.
>
> Possible, certainly. But these are vastly different skill sets.
That's fine. Gives folks who maybe don't have the particular mentality
necessary to be a implementor something to do.
> People aren't likely to take my decision to create a new CL
> personally, but if I start judging THEIR software, you can bet that
> there will be hard feelings.
Well, that depends on the skill of the person taking on the task
doesn't it?
> Not everything can, or ought, to be solved with libraries.
Sure. But many things can. And agreeing on libraries seems like the
easiest possible thing compared to, say, coordinating parallel changes
to multiple implementations. So why don't we start with the easy
stuff--crawl before you do the tango or whatever the cliche is.
> Your proposal regarding handling of UNIX pathnames is one
> example. As well, I see libraries as the wrong solution for problems
> such as TCP socket API incompatibility: A compatibility layer on top
> of a bunch of slightly different implementations is a good userspace
> workaround to a problem which should be solved at the implementation
> level.
Sure. But a compatibility layer can be used as a reference
implementation and can prove (or disprove) a design.
> And what of Kent's example of the typo in ANSI's PROG2 definition?
> Surely something can be cobbled together to say "As regards 4.3.2.1,
> which is inconsistent, it is generally accepted that the committee
> ought to have said ..., and most modern implementations work as if
> that were the case."
Okay, so do that. If you think that's important, put up a web page
that clearly explains the problem and maybe a test case that tests
whether an implementation "correctly" deviates from the literal
wording of the spec so folks can see that this "problem" is not in
fact a problem in practice in any implementation they care about. (And
if there is some implementation that gets it "wrong", lobby the vendor
to do the right thing.)
>> So perhaps someone interested in maintaining such a list should
>> first enlist a few folks they think are smart and reasonable folks
>> to work with. But there's a big difference between getting a small
>> group of people together to buck up each other's spirits and
>> waiting until *everyone* can agree on some process for agreeing.
>
> I don't think everyone needs to agree; that's not what consensus
> means [umm... to me. Ironically,
> http://www.answers.com/consensus&r=67 shows that there's no
> consensus on the word's meaning. Delicious.] If a small group of
> people form a proposal, ask for public comment, then take a public
> straw poll, that might well be enough to convince vendors to
> implement the proposal.
Exactly. That's what I'm saying *should* happen. And the beauty of it
is, any small group can take a crack at it. The first group to
actually navigate resolving some annoyingly gratuitious difference
between, will, I imagine, instantly win a bunch of credibility that
will make it easier for them to take on the next one.
> For some issues, an ad hoc group of as few as two (well placed)
> people could do the trick: "We, as implementors of Lisps A and B,
> wish to stop the foolishness. Henceforth, we will be compatible with
> implementation C as regards API X. After all, most people seem to
> use the API via a C-COMPAT library anyway." That might be enough for
> other Lisps' maintainers to say "Us too." It would be a bonus if the
> package name to be standardized didn't look like a vendor specific
> one...
Yup, that'd be great. So what do you think is stopping that from
happening?
> I don't think we need to reopen ANSI and I don't think we need
> unanimity. Ad hoc addressing of a few issues would be nice, but,
> since I'm sure that various people have a different set of top
> issues they'd like fixed, I'd like to see a process and some
> progress. Certainly for some of the issues, consensus could well
> have been reached with less discussion and heat than has been
> generated merely by my (and others') claim that progress is needed.
As far as I can tell, you've already described several processes by
which progress can be made, if people are willing to actually do
work. What other "process" do we need before interested people can get
to work on actual issues?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel <·····@gigamonkeys.com> writes:
> As far as I can tell, you've already described several processes by
> which progress can be made, if people are willing to actually do
> work. What other "process" do we need before interested people can
> get to work on actual issues?
I've never been under the impression that a lack of process was a
significant impediment to anyone getting anything started. Of
course, I have no problem with making up a new process if there
isn't a pre-existing one, so this is probably a reflection on my
personal bias.
Recognizing that lacking a good process can be detrimental to
success, I can see why some would be hesitant to undertake the
initial steps. In my opinion, this is an example of premature
optimization.
Projects like this get off the ground because some individual has
(or a small core group collectively has) the following
characteristics:
1. Topical interest
2. Resources to pursue the work (time, money, etc.)
3. Motivation to do the work
Groups also need the ability to work effectively together.
If the work isn't happening, these days, it's likely due to a lack
of motivation.
--jon
Ron Garret <·········@flownet.com> writes:
> Consider http://www.python.org/doc/current/modindex.html
> This page is one of Python's big selling points, I claim. Here you can
> find, all gathered in one place, a very large collection of (evolving)
> extensions to Python that have been in some sense "blessed" by the
> Python community.
Sounds like a great business opportunity if it's true. I can't
believe you're letting this valuable idea sit on the table rather than
grabbing it and running with it yourself if you are thus confident.
Me, I found myself worrying I might not feed my family if I did this,
and consequently I've taken a more conservative path. That doesn't
make me right and you wrong, but neither does your claim that I should
be doing this make me wrong and you right. The ultimate test of such
things is the market, and it is proven one way or another by someone bold
enough to try.
Kent M Pitman <······@nhplace.com> writes:
> Ron Garret <·········@flownet.com> writes:
>
> > Consider http://www.python.org/doc/current/modindex.html
> > This page is one of Python's big selling points, I claim. Here you can
> > find, all gathered in one place, a very large collection of (evolving)
> > extensions to Python that have been in some sense "blessed" by the
> > Python community.
>
> Sounds like a great business opportunity if it's true. I can't
> believe you're letting this valuable idea sit on the table rather than
> grabbing it and running with it yourself if you are thus confident.
> Me, I found myself worrying I might not feed my family if I did this,
> and consequently I've taken a more conservative path. That doesn't
> make me right and you wrong, but neither does your claim that I should
> be doing this make me wrong and you right. The ultimate test of such
> things is the market, and it is proven one way or another by someone bold
> enough to try.
Not to mention that its easy to set up "community blessed" extensions
where theres only one implementation of the language... OTOH, the cliki
pages are a fairly close approximation; its community based, pretty well
known and pretty diverse.
Gregm
Ron Garret wrote:
> The claim has been made that nothing in Common Lisp is fundamentally
> broken. I disagree. CL is missing a feature, namely, first-class
> top-level lexical scopes, what in T were called "locales", what in
> modern functional programming languages are called "modules." Because
> CL does not have modules/locales, people try to use the package system
> instead, but packages are fundamentally unsuitable for this purpose (as
> evidenced by the perennial confusion that they cause when people try to
> use them in the way that Andreas has done).
>
> Locales can be added to CL as a user-level construct (as demonstrated by
> my paper presented at ILC03) but only with considerable difficulty, and
> at the cost of undermining useful vendor-specific features (because
> adding locales requires redefining/shadowing DEFUN, DEFVAR, etc.) In
> this sense I submit that CL is fundamentally deficient in a way that can
> only be addressed by changing (or at least augmenting) the standard.
Sounds interesting. Could you describe what these do in more detail?
It sounds like you are talking about telling the reader that certain
read symbols should be placed into *package* while others should be
placed into some anonymous package. I'm particularly interested in how
you handle reading special variables.
-- MJF
In article <······················@speakeasy.net>,
M Jared Finder <·····@hpalace.com> wrote:
> Ron Garret wrote:
>
> > The claim has been made that nothing in Common Lisp is fundamentally
> > broken. I disagree. CL is missing a feature, namely, first-class
> > top-level lexical scopes, what in T were called "locales", what in
> > modern functional programming languages are called "modules." Because
> > CL does not have modules/locales, people try to use the package system
> > instead, but packages are fundamentally unsuitable for this purpose (as
> > evidenced by the perennial confusion that they cause when people try to
> > use them in the way that Andreas has done).
> >
> > Locales can be added to CL as a user-level construct (as demonstrated by
> > my paper presented at ILC03) but only with considerable difficulty, and
> > at the cost of undermining useful vendor-specific features (because
> > adding locales requires redefining/shadowing DEFUN, DEFVAR, etc.) In
> > this sense I submit that CL is fundamentally deficient in a way that can
> > only be addressed by changing (or at least augmenting) the standard.
>
> Sounds interesting. Could you describe what these do in more detail?
See my paper in ILC03. (I'll try to get a copy up on my web site in the
next few days if you can't get it any other way.)
> It sounds like you are talking about telling the reader that certain
> read symbols should be placed into *package* while others should be
> placed into some anonymous package. I'm particularly interested in how
> you handle reading special variables.
Nope, locales/modules are a fundamentally different beast. They are
collections of (lexically scoped) (global) bindings, not collections of
symbols.
rg
"Ron Garret" <·········@flownet.com> schrieb im Newsbeitrag
····································@news.gha.chartermi.net...
> ...
> See my paper in ILC03. (I'll try to get a copy up on my web site in the
> next few days if you can't get it any other way.)
> ...
I thought your paper already is on your website. At the bottom of
http://www.flownet.com/gat/papers/
there is a link to
http://www.flownet.com/gat/locales.pdf
Isn't this the paper under consideration?
Andreas
In article <···············@news.t-online.com>,
"Andreas Thiele" <··········@nospam.com> wrote:
> "Ron Garret" <·········@flownet.com> schrieb im Newsbeitrag
> ····································@news.gha.chartermi.net...
> > ...
> > See my paper in ILC03. (I'll try to get a copy up on my web site in the
> > next few days if you can't get it any other way.)
> > ...
>
> I thought your paper already is on your website. At the bottom of
> http://www.flownet.com/gat/papers/
> there is a link to
> http://www.flownet.com/gat/locales.pdf
> Isn't this the paper under consideration?
Ah, so it is. (I just got back from being out of the country for a
month and I guess I'm still a little jet lagged.)
rg
Now that we are talking about it, there are different approaches to the
subject of first-class environments. Duane Rettig (don't know if he
mentioned it) presented a tutorial on his approach at ILC05. In the
proceedings of ILC02 you can find mine. You can download it from
http://www.pangoline.com/lisp/, login: lispexample, password lisp4all.
(Someone was kind enough to place it on his site) It is about a macro
and the description is oriented towards (but not restricted to)
functional programming. It is older material, but useful it for my own
work.
Ernst
Ron Garret schreef:
> In article <···············@news.t-online.com>,
> "Andreas Thiele" <··········@nospam.com> wrote:
>
> > "Ron Garret" <·········@flownet.com> schrieb im Newsbeitrag
> > ····································@news.gha.chartermi.net...
> > > ...
> > > See my paper in ILC03. (I'll try to get a copy up on my web site in the
> > > next few days if you can't get it any other way.)
> > > ...
> >
> > I thought your paper already is on your website. At the bottom of
> > http://www.flownet.com/gat/papers/
> > there is a link to
> > http://www.flownet.com/gat/locales.pdf
> > Isn't this the paper under consideration?
>
> Ah, so it is. (I just got back from being out of the country for a
> month and I guess I'm still a little jet lagged.)
>
> rg
Ron Garret wrote:
> In article <···············@news.t-online.com>,
> "Andreas Thiele" <··········@nospam.com> wrote:
>
>
>>"Ron Garret" <·········@flownet.com> schrieb im Newsbeitrag
>>····································@news.gha.chartermi.net...
>>
>>>...
>>>See my paper in ILC03. (I'll try to get a copy up on my web site in the
>>>next few days if you can't get it any other way.)
>>>...
>>
>>I thought your paper already is on your website. At the bottom of
>>http://www.flownet.com/gat/papers/
>>there is a link to
>>http://www.flownet.com/gat/locales.pdf
>>Isn't this the paper under consideration?
>
> Ah, so it is. (I just got back from being out of the country for a
> month and I guess I'm still a little jet lagged.)
Interesting. After reading through this, I have a couple questions.
All my questions are based off of the assumption that locales are only
useful if people use them in the way packages are currently used, which
seems obviously true to me.
Is there a way to definitively refer to an object in another locale
without importing the object or the locale? This seems necessary if
locales are the default module system.
How would macros be affected -- would they need to be completely
redesigned? Would expansion depend on the runtime value of *locale*?
One thing I really like about Common Lisp is DEFMACRO. I find it easy
to use *because* it is so low-level, and I'd hate for it to get more
complicated.
-- MJF
In article <······················@speakeasy.net>,
M Jared Finder <·····@hpalace.com> wrote:
> Is there a way to definitively refer to an object in another locale
> without importing the object or the locale? This seems necessary if
> locales are the default module system.
Objects aren't "in" locales. Bindings are in locales. In my reference
implementation there is a function that I call *ref (following T, but
which would be called lsymbol-value if one were following CL naming
conventions) which looks up the value of a symbol in a given locale.
> How would macros be affected -- would they need to be completely
> redesigned? Would expansion depend on the runtime value of *locale*?
> One thing I really like about Common Lisp is DEFMACRO. I find it easy
> to use *because* it is so low-level, and I'd hate for it to get more
> complicated.
Good question. I'm not sure. It's been two years since I've touched
this stuff. Let me go back and see if I can figure it out.
rg
Ron Garret wrote:
> Good question. I'm not sure. It's been two years since I've touched
> this stuff. Let me go back and see if I can figure it out.
>
Stupid aside: The use of the word "locale" for locales still bothers me
a bit. Not because it's inappropriate as such, but because people
(okay, me and some guy I showed your locales paper to) can't seem to
help thinking localisation (as in i18n & l10n ) - and as l10n is so
important, I imagine that might confuse most newbies approaching lisp
if your locales caught on.
You have some experience with name changes :-) : are there any other
names now being considered? "module" doesn't seem entirely
inappropriate...
In article <·················@news.indigo.ie>,
David Golden <············@oceanfree.net> wrote:
> Ron Garret wrote:
>
> > Good question. I'm not sure. It's been two years since I've touched
> > this stuff. Let me go back and see if I can figure it out.
> >
>
> Stupid aside: The use of the word "locale" for locales still bothers me
> a bit. Not because it's inappropriate as such, but because people
> (okay, me and some guy I showed your locales paper to) can't seem to
> help thinking localisation (as in i18n & l10n ) - and as l10n is so
> important, I imagine that might confuse most newbies approaching lisp
> if your locales caught on.
>
> You have some experience with name changes :-) : are there any other
> names now being considered? "module" doesn't seem entirely
> inappropriate...
That's not a stupid aside at all, it's a real issue. I used the term
locale to acknowledge the fact that the idea was not original with me,
but you're right that it's confusing in this day and age. Still, to my
mind "module" is a little too generic. But maybe I'll start using it if
no one comes up with anything better.
rg
Ron Garret <·········@flownet.com> writes:
> In article <·················@news.indigo.ie>,
> David Golden <············@oceanfree.net> wrote:
>
> > Ron Garret wrote:
> >
> > > Good question. I'm not sure. It's been two years since I've touched
> > > this stuff. Let me go back and see if I can figure it out.
> > >
> >
> > Stupid aside: The use of the word "locale" for locales still bothers me
> > a bit. Not because it's inappropriate as such, but because people
> > (okay, me and some guy I showed your locales paper to) can't seem to
> > help thinking localisation (as in i18n & l10n ) - and as l10n is so
> > important, I imagine that might confuse most newbies approaching lisp
> > if your locales caught on.
> >
> > You have some experience with name changes :-) : are there any other
> > names now being considered? "module" doesn't seem entirely
> > inappropriate...
>
> That's not a stupid aside at all, it's a real issue. I used the term
> locale to acknowledge the fact that the idea was not original with me,
> but you're right that it's confusing in this day and age. Still, to my
> mind "module" is a little too generic. But maybe I'll start using it if
> no one comes up with anything better.
You could use "environments". No, wait ...
:-)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Ron Garret <·········@flownet.com> writes:
> Still, to my mind "module" is a little too generic. But maybe I'll
> start using it if no one comes up with anything better.
What about the word "pleat"?
* Each "pleat" holds additional bindings of the symbol, yielding
more "binding room" in the symbol.
* Each symbol would initially have only one pleat, yielding a
small increase in the overal storage space unless the extra room
provided by additionalpleats are needed.
According to http://www.ultralingua.net, "pleat" is synonymous
with "plait", which can mean "a plat" (2nd def). A plat, in turn,
can be "a small piece or plot of ground laid out with some
design, or for a special use." (3rd def).
You could campaign for implementors to create "XL" binding spaces
by adding pleats to their CL! The number of "X"s would depend on
how many namespaces they supported, where each "X" implies n-arry
pleats for the namespace. A Lisp-1 would be XL by adding pleats. A
Lisp-2 would be XXL (heh). A Lisp-Omega would be X-Omega L.
--jon
Ron Garret wrote:
> Still, to my
> mind "module" is a little too generic. But maybe I'll start using it
> if no one comes up with anything better.
>
"lexicon" ??? it's still a bit generic but certainly not as widely
applied as "module". Arrived via:
locale -> first class lexical environment. f.c.l.e.
* a fickle/ the current fickle / different fickles
Groan. No.
* a lexenv / the current lexenv / different lexenvs
Bloody literal mindedness. And suffers from similar
problem to plain "environment"...
lex, lex, lex...
* a lexicon / the current lexicon / different lexicons (or lexica)
hmm.. Maybe that is not actually bad. See
http://thesaurus.reference.com/search?q=lexicon
under "Main Entry: context / Definition: circumstances":
"Synonyms: ambience, background, conditions, connection, framework,
lexicon, relation, situation, substance, text, vocabulary"
And note synonym list contains some of Kent's suggestions too.
David Golden <············@oceanfree.net> writes:
> Ron Garret wrote:
>
> > Still, to my
> > mind "module" is a little too generic. But maybe I'll start using it
> > if no one comes up with anything better.
>
> "lexicon" ??? it's still a bit generic but certainly not as widely
> applied as "module". Arrived via:
"lexicon" is not a terrible name. (doesn't postscript just come right
out and call the equivalent th ing a "dictionary"? that's another
option.) and lexicon has the hint of "lexical" built into it, which
is nice...
Kent M Pitman <······@nhplace.com> writes:
> doesn't postscript just come right out and call the equivalent thing
> a "dictionary"? that's another option.
Yes, postscript has dictionaries.
Either lexicon or dictionary would be a good choice, although I
thing lexicon has a bit more pizzazz.
--jon
David Golden <············@oceanfree.net> writes:
> Ron Garret wrote:
>
> > Good question. I'm not sure. It's been two years since I've touched
> > this stuff. Let me go back and see if I can figure it out.
> >
>
> Stupid aside:
Not stupid at all, IMO. It's often hard to catch things like this at
the right time to actually fix them. At any other time, IMO, this
kind of remark might be much less useful.
(Ron might disagree with me depending on how invested he is in the
name. But there's a story about Makefiles and that stupid business of
depending on the tab character. I think it's a true story, though I
don't know a definitive reference. Supposedly they realized this was a
major design error at one point but since the 'make' system was
already deployed in something like a dozen or two systems, they
figured it was too late to fix it... Ah for such simple numbers of
files to update. The moral, of course, is that you're betting against
your own success if you think that's too many people to trouble with a
last-minute correction to an up-and-coming system.)
> The use of the word "locale" for locales still bothers me
> a bit. Not because it's inappropriate as such, but because people
> (okay, me and some guy I showed your locales paper to) can't seem to
> help thinking localisation (as in i18n & l10n ) - and as l10n is so
> important, I imagine that might confuse most newbies approaching lisp
> if your locales caught on.
This is a good point. Especially since there is presently no compatibility
constraint keeping a name change from having now. It's purely a historical
continuity issue, and though the name is cool, avoiding problems down the
road in this case seems sound even if it makes people forget the relation to
my original T locales ... sniff. Most people probably don't know about
those anyway, which is why Ron is hyping them so much.
There are few times in the life of an idea where you are actually able
to change the name without angering someone. That's the right time to
consider a name change. Not years later when you're talking about a
deployed, mature facility and how to make it "better". Since we're
not talking about the CL core but a layered idea that isn't quite
fully rolled out yet, this is at least the right time to consider
whether the name is right.
And, on the bright side, what Ron is offering is actually different than
the original locales in T, so having them bear a different name might be
proper...
> You have some experience with name changes :-) : are there any other
> names now being considered? "module" doesn't seem entirely
> inappropriate...
This is where a trip to the thesaurus is usually fun/helpful to walk around
in the space of related words.
I kind of like "setting". It has that nice pun between "assignment" and
"background of a movie". But I suspect it is too overused in CL to sound
distinct.
I might go with "milieu" if I thought English speakers could spell,
pluralize, or pronounce it. Since I think many Americans couldn't,
and it would probably tax some non-native English speakers, too, I
wouldn't. I think the ability to talk about something is an important
part of programming langauge design. It's a pity, though. It's a
pretty word...
Either of "backdrop" or "surrounding" is likely distinct enough. The
latter is more easily coalesced into an aggregate. ("The surroundings
of a form affect its value." feels better to describe the sense of a
cascaded set of environments like containerized lexical contours than
does "The backgrounds of a form affect its value." since backdrop is
by its nature already aggregated in nature and the elements of a backdrop
are often named something else.)
dictionary.com (which surveys several dictionaries) says WordNet
defines "ambiance" as "a paritcular environment or surrounding
influence", which is kind of nice. It suggests that you have
something with a basic meaning that can be influenced by changing a
global parameter. Its downside is that it's non-count, so it
pluralizes only in a forced way.
I guess of the ones above, I have a slight preference for "surrounding"
because it has no really major negatives and almost sounds like what
parentheses do.
But mine is just one opinion and it's Ron's proposal, so I'll leave it
to him to sort out whether he wants to change the name and how to weight
suggestions from me and others who no doubt will offer theirs.
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> And, on the bright side, what Ron is offering is actually different than
> the original locales in T,
They are? How?
rg
Ron Garret <·········@flownet.com> writes:
> In article <·············@nhplace.com>,
> Kent M Pitman <······@nhplace.com> wrote:
>
> > And, on the bright side, what Ron is offering is actually different than
> > the original locales in T,
>
> They are? How?
I could be wrong--I didn't go back and review the T design and it's been a
long time since I used it. (You've probably used it more recently than I.)
But I thought in T that all free variables went through this mechanism such
that if something didn't get attached right, you could repair it after the
fact. In your implementation, only free variables will get syntactically
attached and you have to re-evaluate the original form if you want to change
something from a free variable (which is probably defaultly special) to a
locale-managed variable. You can only do the thing your paper advertises
with after-the-fact redirection in the debugger if you've at least gone to
the trouble to define a free variable to be syntaxed as "part of the locale
mechanism" in the first place. You may or may not see this as a substantial
issue, but it speaks to the pervasive nature.
It probably would have been gotten rid of even if it had one, just like
evalhook was, but if CL had a hook that allowed programmatic control
of syntaxing of free variables such that
(defun special-binding (x) `(symbol-value ',x))
(defun lexical-binding (x) `(lexical-value ,x)) ;hypothetical operator
(with-free-variable-management special-binding
(defun foo () x))
=expandsto=> (defun foo () (symbol-value 'x))
you could get the effect of a kind of "catch-all symbolmacrolet". The
problem with doing it this way is that the "binding function" would take
place at compile time in the compiler, and its own environment would be
tricky to manage, ... but conceptually it's the kind of thing you might
wish for ... Another way it could have been cast would be to have a
system macro that was always used to wrap a free reference and that users
were permitted to customize. e.g.,
(defmacro system:free-reference (x) `(symbol-value ',x))
(defun foo () x) =expandsto=> (defun foo () (system:free-reference x))
and then programmers could do:
(defun foo ()
(macrolet ((system:free-reference (x) `(lexical-value ,x)))
...))
or even
(defmacro deflocale (&body definitions)
`(macrolet ((system:free-reference (x) `(locale-value ,x)))
,@definitions))
The problem with this formulation would be that there'd be a strong temptation
for someone to defmacro it to just make it happen globally, so they wouldn't
have to wrap all the forms in a file. That would have the problem of
persisting beyond a file loading, and infecting unsuspecting programs.
Anyway, my bottom line point is that there's a subtle difference between
T (which was built around locales all the way down) and CL (where you've
added locales locally but not everyone is playing), and the difference
is seen primarily in the default handling of undeclared free references.
Or so it seems to me if both my memory is working right about T and if I read
your locale paper correctly...
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> Anyway, my bottom line point is that there's a subtle difference between
> T (which was built around locales all the way down) and CL (where you've
> added locales locally but not everyone is playing), and the difference
> is seen primarily in the default handling of undeclared free references.
Well, yes and no. Most implementations treat undeclared free references
as if they were implicitly declared special, but I don't believe this
behavior is required by the standard (though I don't recall, and I don't
feel like looking it up right now). So this might indeed by a
difference de facto, but I do not believe it is one de jure.
rg
Ron Garret <·········@flownet.com> writes:
> In article <·············@nhplace.com>,
> Kent M Pitman <······@nhplace.com> wrote:
>
> > Anyway, my bottom line point is that there's a subtle difference between
> > T (which was built around locales all the way down) and CL (where you've
> > added locales locally but not everyone is playing), and the difference
> > is seen primarily in the default handling of undeclared free references.
>
> Well, yes and no. Most implementations treat undeclared free references
> as if they were implicitly declared special, but I don't believe this
> behavior is required by the standard (though I don't recall, and I don't
> feel like looking it up right now).
No, that is certainly correct. But you don't get ahold of any option to
make it do something else. And as a de-facto matter, implementations are
pretty uniform in treating free references as defaultly special.
> So this might indeed by a
> difference de facto, but I do not believe it is one de jure.
The sense in which it matters is not in comparison to CL but in comparison
to T. That is, in T I don't believe you had to predefine every variable,
and in CL you do. For working code, it matters little, since in neither
case can you run the code until you know where something's defined. But you
advertise in your paper the ability to correct mis-pointed references from
the debugger, and I'm just observing that that will only be true in the case
where the mis-pointed reference points at least to a locale reference, not to
an arbitrary reference. It's necessary, at minimum, for the reference to
have been syntaxed as a locale-ref of some kind, even if it can be redirected.
Whether this matters or should matter to anyone is not something I was
making a statement about. Only that it might matter. And I didn't even
mean to make it a big point--only to explain why I had referred to it as
being not identical in nature...
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <·············@nhplace.com>,
> > Kent M Pitman <······@nhplace.com> wrote:
> >
> > > Anyway, my bottom line point is that there's a subtle difference between
> > > T (which was built around locales all the way down) and CL (where you've
> > > added locales locally but not everyone is playing), and the difference
> > > is seen primarily in the default handling of undeclared free references.
> >
> > Well, yes and no. Most implementations treat undeclared free references
> > as if they were implicitly declared special, but I don't believe this
> > behavior is required by the standard (though I don't recall, and I don't
> > feel like looking it up right now).
>
> No, that is certainly correct. But you don't get ahold of any option to
> make it do something else. And as a de-facto matter, implementations are
> pretty uniform in treating free references as defaultly special.
Which is unfortunate IMHO.
> > So this might indeed by a
> > difference de facto, but I do not believe it is one de jure.
>
> The sense in which it matters is not in comparison to CL but in comparison
> to T. That is, in T I don't believe you had to predefine every variable,
> and in CL you do. For working code, it matters little, since in neither
> case can you run the code until you know where something's defined. But you
> advertise in your paper the ability to correct mis-pointed references from
> the debugger,
I do? Where?
> and I'm just observing that that will only be true in the case
> where the mis-pointed reference points at least to a locale reference, not to
> an arbitrary reference. It's necessary, at minimum, for the reference to
> have been syntaxed as a locale-ref of some kind, even if it can be redirected.
Yes, that's certainly true. Once a symbol has been declared special
you're screwed. ;-)
rg
Kent M Pitman <······@nhplace.com> wrote:
+---------------
| I kind of like "setting"...
| I might go with "milieu" if I thought English speakers could spell...
| Either of "backdrop" or "surrounding" is likely distinct enough. ...
+---------------
I would suggest "topic", because of its root meaning "of a place"
[also, Google for "memory theatre"], but that has baggage, too.
How about just the raw Greek, "topos"? [Not sure what the plural is,
but it must have one]. Or the Latin "locus" [pl. "loci"]?
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> How about just the raw Greek, "topos"?
> [Not sure what the plural is, but it must have one].
"Topoi". Well, actually, it's often pluralised "toposes"
when used in maths, maybe because mathematicians prefer the
regular s/es pluralisation of english, though there is ample
precedent for adopting the source language plural form in borrowed
words in english.
But as hinted above "Topos" is used often in pure maths in category
theory, and categories are _very_ close to compsci hearts because of
their use in formalising type theory. Informally, a topos is a
category with category-of-set -like properties.
http://math.ucr.edu/home/baez/topos.html
M Jared Finder <·····@hpalace.com> writes:
> Ron Garret wrote:
>
> > The claim has been made that nothing in Common Lisp is fundamentally
> > broken. I disagree. CL is missing a feature, namely, first-class
> > top-level lexical scopes, what in T were called "locales", what in
> > modern functional programming languages are called "modules."
> > Because CL does not have modules/locales, people try to use the
> > package system instead, but packages are fundamentally unsuitable
> > for this purpose (as evidenced by the perennial confusion that they
> > cause when people try to use them in the way that Andreas has done).
> > Locales can be added to CL as a user-level construct (as
> > demonstrated by my paper presented at ILC03) but only with
> > considerable difficulty, and at the cost of undermining useful
> > vendor-specific features (because adding locales requires
> > redefining/shadowing DEFUN, DEFVAR, etc.) In this sense I submit
> > that CL is fundamentally deficient in a way that can only be
> > addressed by changing (or at least augmenting) the standard.
>
> Sounds interesting. Could you describe what these do in more detail?
> It sounds like you are talking about telling the reader that certain
> read symbols should be placed into *package* while others should be
> placed into some anonymous package. I'm particularly interested in
> how you handle reading special variables.
Locales (my invention for the T language back in 1981 or so, btw) are
not about symbols at all. They don't have to do with interning, and
they won't separate symbol data ever, so all your GET's mostly have to
be (a) still separated by packages, (b) rewritten as accesses to a
GETHASB on a variable that is in-module since otherwise things will
collide, (c) keyed on something different that is unique and not
package-related, or (d) otherwise reconsidered.
Symbols in Scheme are not packaged, so you can think of them in CL as
being a way to force multiple programs into the same package.
Packages are orthogonally useful as a way of partitioning data, where
you don't want MY:WINDOW to be eq to YOUR:WINDOW as a key. Some
people don't want that at all, and should be using ALL-PURPOSE:WINDOW
for anything they do in Lisp (which is how Scheme works in the Scheme
emulators people have written--all Scheme programs go in one
all-purpose Scheme package).
Special variables, you'd think, would clash because of lack of
packages, but I think I can see how not to do that. It's pretty
straightforward. I worked through most of an implementation just now
but it doesn't fit in the margin of this message... heh. (It did fit
in another file that I didn't post, though... I'll maybe try a full
implementation sometime when I'm more awake to see if I'm right. I
really just got up for a drink of water during the night and wanted to
check email and... should be back in bed.)
"Ron Garret" <·········@flownet.com> schrieb im Newsbeitrag
····································@news.gha.chartermi.net...
> In article <···············@news.t-online.com>,
> "Andreas Thiele" <··········@nospam.com> wrote:
>
> > "Kent M Pitman" <······@nhplace.com> schrieb im Newsbeitrag
> > ··················@nhplace.com...
> > > "Andreas Thiele" <··········@nospam.com> writes:
> > >
> > > > CL-USER 1 > (defun foo (&key test) t)
> > > > FOO
> > > >
> > > > CL-USER 2 > (defpackage :cl-test (:export :test))
> > > > #<PACKAGE CL-TEST>
> > > >
> > > > CL-USER 3 > (use-package :cl-test)
> > > >
> > > > Error: Using package CL-TEST results in a name conflict
> > > > for this symbol: TEST.
> > > >
> > > > Should one always use packages, even if I don't know if or what I
> > > > will ever export from that package, just to avoid such conflicts
> > > > (which are no real conflicts)?
> > >
> > > Your real problem here is failing to use the package before you use
> > > it.
>
> Actually, it appears that the real problem was a failure to understand
> how the reader processes symbols (or, to put it another way, a failure
> to understand that symbols are interned by the reader and not the
> evaluator):
>
> > I though[t] that
> >
> > (defun foo (&key test) t)
> >
> > will only intern a symbol 'foo ...
>
> At the risk of beating a dead horse, I will make a point that I have
> made before and gotten roundly beaten up for, but I'll raise it again
> because I think it is relevant in light of the recent discussion taking
> place in the "beyond CL" thread. (Cameron Mackinnon is making similar
> points and getting predictably beaten up for it, so I feel duty-bound to
> come to his aid.)
>
> The claim has been made that nothing in Common Lisp is fundamentally
> broken. I disagree. CL is missing a feature, namely, first-class
> top-level lexical scopes, what in T were called "locales", what in
> modern functional programming languages are called "modules." Because
> CL does not have modules/locales, people try to use the package system
> instead, but packages are fundamentally unsuitable for this purpose (as
> evidenced by the perennial confusion that they cause when people try to
> use them in the way that Andreas has done).
>
> Locales can be added to CL as a user-level construct (as demonstrated by
> my paper presented at ILC03) but only with considerable difficulty, and
> at the cost of undermining useful vendor-specific features (because
> adding locales requires redefining/shadowing DEFUN, DEFVAR, etc.) In
> this sense I submit that CL is fundamentally deficient in a way that can
> only be addressed by changing (or at least augmenting) the standard.
>
> Ron Garret f.k.a. Erann Gat
Is it possible to have the code described in your paper or is this
considered easy to re-write?
I assume the functions parameters are also handled by the LDEFUN macro?
Andreas
In article <···············@news.t-online.com>,
"Andreas Thiele" <······@nospam.com> wrote:
> "Ron Garret" <·········@flownet.com> schrieb im Newsbeitrag
>
> > Locales can be added to CL as a user-level construct (as demonstrated by
> > my paper presented at ILC03) but only with considerable difficulty, and
> > at the cost of undermining useful vendor-specific features (because
> > adding locales requires redefining/shadowing DEFUN, DEFVAR, etc.) In
> > this sense I submit that CL is fundamentally deficient in a way that can
> > only be addressed by changing (or at least augmenting) the standard.
> >
>
> Is it possible to have the code described in your paper or is this
> considered easy to re-write?
That depends on your level of skill as a programmer. The concept is
tricky but not fundamentally hard. Personally I found it quite a
challenge to get right, but I'm sure someone like Kent or Duane could
rattle of a reference implementation in their sleep.
> I assume the functions parameters are also handled by the LDEFUN macro?
I'm not sure what you mean by that.
rg
In article <·······························@news.gha.chartermi.net>,
Ron Garret <·········@flownet.com> wrote:
> In article <···············@news.t-online.com>,
> "Andreas Thiele" <······@nospam.com> wrote:
>
> > "Ron Garret" <·········@flownet.com> schrieb im Newsbeitrag
> >
> > > Locales can be added to CL as a user-level construct (as demonstrated by
> > > my paper presented at ILC03) but only with considerable difficulty, and
> > > at the cost of undermining useful vendor-specific features (because
> > > adding locales requires redefining/shadowing DEFUN, DEFVAR, etc.) In
> > > this sense I submit that CL is fundamentally deficient in a way that can
> > > only be addressed by changing (or at least augmenting) the standard.
> > >
> >
> > Is it possible to have the code described in your paper or is this
> > considered easy to re-write?
>
> That depends on your level of skill as a programmer. The concept is
> tricky but not fundamentally hard. Personally I found it quite a
> challenge to get right, but I'm sure someone like Kent or Duane could
> rattle of a reference implementation in their sleep.
>
I just realized I only answered the second half of the question. The
answer to the first half is, no, the code is not currently available.
It's mutated into a broken state, and I haven't had time to work on it
for a while. But if there is enough interest I'll see what I can do to
whip it back into shape.
rg
"Ron Garret" <·········@flownet.com> schrieb im Newsbeitrag
····································@news.gha.chartermi.net...
> ...
> > I assume the functions parameters are also handled by the LDEFUN macro?
>
> I'm not sure what you mean by that.
> ...
Just another misunderstanding of mine as one of your next posts to this thread
explains:
>> ...
>> Nope, locales/modules are a fundamentally different beast. They are
>> collections of (lexically scoped) (global) bindings, not collections of
>> symbols.
>> ...
After reading of
http://www.flownet.com/gat/locales.pdf
which just demonstrates the principles, in the context of my OP I thought it deals with symbols.
Andreas
"Andreas Thiele" <··········@nospam.com> writes:
> (defun foo (&key test) t)
>
> will only intern a symbol 'foo in the current package which can lead
> to conflicts. Thus I wondered about a conflicting symbol 'test. Obviously
> a misunderstanding.
Yes.
The right way to understand it is that symbols are processed by the reader
with no assumption whatsoever that you are going to evaluate anything.
You might simply be "saying this expression aloud". e.g., you might have
put a single-quote in front of it. The reader has no awareness that you
are about to evaluate or compile the thing moments later. Consequently,
nothing the reader does is informed by the lexical contours of the program.
Indeed, the language itself is defined not on input syntax but on objects.
In other languages, variables are notations on paper (i.e., characters in
a file). In Lisp, they are symbols. In other languages, forms to execute
are notations on paper (i.e., characters in a file). In Lisp they are
lists. The reason this is relevant is that the reader must produce
symbols and lists FIRST, and then EVAL is handed those symbols and lists for
processing. It would be circular to say that the symbols and lists are
created subject to the rules of evaluation if the evaluator is going to do
what it does only when given symbols and lists. (In fact, it is possible
using functional operators to construct code in Lisp that has no source
code anywhere. Macros do this all the time.)
> in other words (my own recapitulation) use-package expresses package
> dependencies and has to appear before the definition of 'foo
I recommand saying FOO here, not 'FOO. 'FOO is equivalent to (QUOTE FOO).
Nothing in your example is getting defined with the name (QUOTE FOO).
You will find it gets you in more trouble than you want to use that stray
quotation mark there.
> regardless to which package 'foo
FOO.
> might belong. This way I don't run into the conflict.
Right.
"Kent M Pitman" <······@nhplace.com> schrieb im Newsbeitrag
··················@nhplace.com...
...
> I recommand saying FOO here, not 'FOO. 'FOO is equivalent to (QUOTE FOO).
...
Oops, yes, of course - again wrong intuition.
I wanted to emphazise I'm talking about the symbol FOO.
From: Robert Uhl
Subject: Re: professional package use?
Date:
Message-ID: <m3y87sasuy.fsf@4dv.net>
"Andreas Thiele" <··········@nospam.com> writes:
>
> CL-USER 1 > (defun foo (&key test) t)
> FOO
>
> CL-USER 2 > (defpackage :cl-test (:export :test))
> #<PACKAGE CL-TEST>
You don't need to export :test; :test is in the KEYWORD package. All
you'd need to do is export foo--and you would still need to worry about
CL-TEST:FOO conflicting with CL-USER:FOO; your implementation may have a
way to fix this or you may need to call FMAKUNBOUND to fix the problem.
HTH.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Gun control: the theory that a woman found raped and strangled in an
alley is morally superior to a woman explaining why her attacker got a
fatal bullet wound.
"Robert Uhl" <·········@NOSPAMgmail.com> schrieb im Newsbeitrag ···················@4dv.net...
> "Andreas Thiele" <··········@nospam.com> writes:
> >
> > CL-USER 1 > (defun foo (&key test) t)
> > FOO
> >
> > CL-USER 2 > (defpackage :cl-test (:export :test))
> > #<PACKAGE CL-TEST>
>
> You don't need to export :test; :test is in the KEYWORD package. All
> you'd need to do is export foo--and you would still need to worry about
> CL-TEST:FOO conflicting with CL-USER:FOO; your implementation may have a
> way to fix this or you may need to call FMAKUNBOUND to fix the problem.
>
> HTH.
>
> --
> Robert Uhl <http://public.xdi.org/=ruhl>
> Gun control: the theory that a woman found raped and strangled in an
> alley is morally superior to a woman explaining why her attacker got a
> fatal bullet wound.
This was just an example. I wanted to export a function TEST from package CL-TEST. You can use the
keyword :TEST in the export clause of DEFPACKAGE. It will get translated into the symbol TEST.
Indeed you must use the keyword and not the symbol otherwise you'd intern the symbol before it is
used and you'd run into the following:
CL-USER 1 > (defpackage :cl-test (:export test))
#<PACKAGE CL-TEST>
CL-USER 2 > (use-package :cl-test)
Error: Using package CL-TEST results in a name conflict for this symbol: TEST.
1 (continue) Unintern the conflicting symbol from its home package.
...
Of course this is a subtility. You could write
(defpackage :cl-test)
(in-package :cl-test)
(export 'test)
(in-package :common-lisp-user)
(use-package :cl-test)
and (symbol-package 'test) will return something like #<PACKAGE CL-TEST>.
I left out the actual declaration of the function TEST because DEFPACKAGE was sufficient to
illustrate the problem. My problem was, I did not expect a conflict between the key TEST of function
FOO and the function CL-TEST:TEST. But exactly this will occur if you use USE-PACKAGE after you
already defined FOO. The key TEST is just a symbol which will get interned when the Lisp reader
reads
(defun foo (&key test) t)
I thought, I could simply call USE-PACKAGE anywhere in the code. This seems to be no good practice
;). USE-PACKAGE should express package dependencies and be one of the first lines in a package, or,
even more succint, expressed by a (:use :cl-test) form in DEFPACKAGE.
Andreas
Robert Uhl wrote:
> "Andreas Thiele" <··········@nospam.com> writes:
>>
>> CL-USER 1 > (defun foo (&key test) t)
>> FOO
>>
>> CL-USER 2 > (defpackage :cl-test (:export :test))
>> #<PACKAGE CL-TEST>
>
> You don't need to export :test; :test is in the KEYWORD package.
He doesn't export :TEST. He exports the symbol named by the symbol-name
of :TEST. Normally, the symbol name of :TEST would be "TEST".
> All you'd need to do is export foo--and you would still need to worry about
> CL-TEST:FOO conflicting with CL-USER:FOO; your implementation may have a
> way to fix this or you may need to call FMAKUNBOUND to fix the problem.
FMAKUNBOUND doesn't unintern symbols from a package, so it won't solve a
package conflict. UNINTERN /does/ unintern symbols.
From: Robert Uhl
Subject: Re: professional package use?
Date:
Message-ID: <m3vf2vc16x.fsf@4dv.net>
Never mind--I was wholly wrong.
--
Robert Uhl <http://public.xdi.org/=ruhl>
The shortest possible instant of time, far shorter than the so-called
'Planck time,' is the interval between hitting a key and realizing that
one should NOT have hit that key.