In my formative years I was a fan of T, which for those of you who don't
know, is a member of the Lisp family of languages ;-) that resembles
Scheme more than Common Lisp. It is a Lisp-1, but it had a lot of
features not found in Scheme, like an object system, and a setf-like
feature called "setters". ("SETTER" was a function which when called on
another function would return a function that when called would set the
location referred to by the second function. Whew! e.g.: ((setter car)
x 1) == (replaca x 1)
One of T's built-in features was first-class environments, which are data
structures that map symbols to values. Environments were designed to
serve the same purpose as packages in CL: to prevent name collisions
between program modules. The difference between packages and environments
is that packages allow you to have multiple symbols with the same print
name, while environments let you have multiple values associated with a
single symbol. (This is not to be confused with returning multiple values
from a function, which is a completely different issue.)
A mentor of mine at the time (1988 or so) once expounded on the virtues of
environments and the evils of packages. He made an offhand comment that I
still remember to this day: "Common Lisp" he said "really has a flat
namespace." What he meant was that there was little effective difference
between packages as they exist in CL, and a Lisp with only one package and
a reader hack that attached the prefix "package:" (where "package" is
replaced with the value of the global variable *package*) to all symbol
names that didn't already have colons in them before interning them. Now,
this isn't quite right, of course, because of import, export, and
use-package, but his fundamental point has stuck with me through the
years, that discriminating between multiple interpretations of a symbol
name at read time rather than at eval time was the Wrong Thing. (This is
not to say that I necessarily agree with this point of view, just that I
remember it.)
Through the years I have always found the package system to be pretty
annoying. I often find myself doing the following:
> foo
ERROR: foo is unbound ; Doh! Forgot that foo is in foo-package
> (use-package 'foo-package)
ERROR: symbol FOO-PACKAGE:FOO conflicts with symbol FOO ; Arrggh!!!
So I've always considered packages as more of a necessary evil than a
feature. I was told that this view was common in the CL world, as
reflected in one of Guy Steele's many subtle jokes in CLTLn: in both
editions of the book the section dealing with packages is "chapter 11",
which in the American legal system refers to a set of laws dealing with
bankruptcy.
But in the recent discussion of what "first class symbol" means a number
of people have made statements that at least imply (and sometimes
explicitly state) that they like packages, that they think they really are
a cool feature. For those of you who feel this way I have the following
question: were you aware of the eval-time alternative for resolving name
conflicts provided by environments? And if you were, what is it that
makes you prefer packages?
Thanks,
E.
···@jpl.nasa.gov (Erann Gat) writes:
> One of T's built-in features was first-class environments, which are data
> structures that map symbols to values. Environments were designed to
> serve the same purpose as packages in CL: to prevent name collisions
> between program modules.
WRONG! Just because you don't value symbolic processing doesn't mean
that others can't. PLEASE notice that symbols in Lisp ARE VALUES and
can be used as such. Therefore, when passing symbols around, one MUST
be sure that application X's symbol is not the same as application Y's
symbol due to some unintentional name-clash. That is what packages
solve.
> A mentor of mine at the time (1988 or so) once expounded on the virtues of
> environments and the evils of packages.
Amazing that of two things that can cooperate, one is evil and one is good.
> Through the years I have always found the package system to be pretty
> annoying. I often find myself doing the following:
> > foo
> ERROR: foo is unbound ; Doh! Forgot that foo is in foo-package
> > (use-package 'foo-package)
> ERROR: symbol FOO-PACKAGE:FOO conflicts with symbol FOO ; Arrggh!!!
So choose the restart to unintern it from the current package.
> But in the recent discussion of what "first class symbol" means a number
> of people have made statements that at least imply (and sometimes
> explicitly state) that they like packages, that they think they really are
> a cool feature. For those of you who feel this way I have the following
> question: were you aware of the eval-time alternative for resolving name
> conflicts provided by environments?
No, since environments map symbols to values, not strings to symbols.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
>>>>> On Sat, 16 Mar 2002 09:31:27 -0800, Erann Gat ("Erann") writes:
Erann> In my formative years I was a fan of T, which for those of you
Erann> who don't know, is a member of the Lisp family of languages
Erann> ;-) that resembles Scheme more than Common Lisp.
The original description of T (as told to me by the implementors
when they had just started) was: "industrial strength Scheme".
In article <····················@192.168.1.50>,
Erann Gat <···@jpl.nasa.gov> wrote:
>
>Through the years I have always found the package system to be pretty
>annoying. I often find myself doing the following:
>
>> foo
>ERROR: foo is unbound ; Doh! Forgot that foo is in foo-package
>> (use-package 'foo-package)
>ERROR: symbol FOO-PACKAGE:FOO conflicts with symbol FOO ; Arrggh!!!
I sympathize, but I expect to get singed on the
REPL all the time, even in Scheme. I mainly use the
REPL to observe how things crash and burn.
>So I've always considered packages as more of a necessary evil than a
>feature. I was told that this view was common in the CL world, as
>reflected in one of Guy Steele's many subtle jokes in CLTLn: in both
>editions of the book the section dealing with packages is "chapter 11",
>which in the American legal system refers to a set of laws dealing with
>bankruptcy.
:-) :-) All these years with that book, and I
didn't realize that till now.
>But in the recent discussion of what "first class symbol" means a number
>of people have made statements that at least imply (and sometimes
>explicitly state) that they like packages, that they think they really are
>a cool feature. For those of you who feel this way I have the following
>question: were you aware of the eval-time alternative for resolving name
>conflicts provided by environments? And if you were, what is it that
>makes you prefer packages?
Environments are forbiddingly expensive? I mean,
Scheme, whose midwives were well aware of first-class
environments (SICP 1/e mentions them) would have
standardized on them in a jiffy otherwise, no?
--d
* Erann Gat wrote:
> A mentor of mine at the time (1988 or so) once expounded on the virtues of
> environments and the evils of packages. He made an offhand comment that I
> still remember to this day: "Common Lisp" he said "really has a flat
> namespace." What he meant was that there was little effective difference
> between packages as they exist in CL, and a Lisp with only one package and
> a reader hack that attached the prefix "package:" (where "package" is
> replaced with the value of the global variable *package*) to all symbol
> names that didn't already have colons in them before interning them. Now,
> this isn't quite right, of course, because of import, export, and
> use-package, but his fundamental point has stuck with me through the
> years, that discriminating between multiple interpretations of a symbol
> name at read time rather than at eval time was the Wrong Thing. (This is
> not to say that I necessarily agree with this point of view, just that I
> remember it.)
It's quite possible to build a system on top of the `flat' package
namespace which allows it to be quite non-flat. I have a system
called conduits (and there is at least one other such system I think),
which adds a couple of options to DEFPACKAGE which let you define a
package as `extending' another one. For a long time I didn't really
use this in anger but I have done so now, and the package structure of
the system I'm working on now is layered quite deeply.
I have a whole bunch of low-level packages, and then something like:
(defpackage :weld-low
(:use)
(:extends ...n packages...))
and then further up
(defpackage :weld-crs-implementation
(:use :cl :weld-low))
...
(defpackage :weld
(:use)
(:extends :weld-low :weld-crs-implementation ...))
others Of course it's `just a hack' and not hygenic or anything, so
doesn't really qualify as a proper program in our brave, pure, new
world. It also doesn't address the heirarchical package *name* issue
at all which I think ACL does for instance.
Still, it's very useful, I find.
--tim
* Erann Gat
| A mentor of mine at the time (1988 or so) once expounded on the virtues
| of environments and the evils of packages. He made an offhand comment
| that I still remember to this day: "Common Lisp" he said "really has a
| flat namespace." What he meant was that there was little effective
| difference between packages as they exist in CL, and a Lisp with only one
| package and a reader hack that attached the prefix "package:" (where
| "package" is replaced with the value of the global variable *package*) to
| all symbol names that didn't already have colons in them before interning
| them.
I begin to see where you come from and where you went wrong, Erann. This
is such a stupid thing to say that I marvel at the respect you must have
felt for this mentor. I hope _I_ shall never have a student who does not
have in him the ability to say "that's a load of crap, Erik" if I make a
similarly retarded point and expect people to believe it, not laugh.
How about the function and variable values of a symbol? It is just as if
we had used Scheme evaluation rules, but had a reader hack that prefixed
the first position of a form with "operator-" and every other symbol with
"variable-". See? No material difference between Scheme and Common Lisp
-- they are equivelant modulo a reader hack. Right? If you see how
_retarded_ it would be to explain the difference this way, which I
suspect you will, since I am not your highly respected mentor and you are
free to think instead of believe, it should help you realize just how
retarded the explanation that you heard about packages was, too.
| Now, this isn't quite right, of course, because of import, export, and
| use-package, but his fundamental point has stuck with me through the
| years, that discriminating between multiple interpretations of a symbol
| name at read time rather than at eval time was the Wrong Thing.
This is just too incredible to be for real. There is no discrimination
between multiple interpretation of a symbol at read time. That is just
_so_ confused, no wonder you have serious problems. Have you actually
ever understood Common Lisp at all, Erann? I have to wonder. At read
time, a string is interned in only one package to return a symbol. There
_is_ no symbol without the package. There are only the characters in a
symbol's name.
Again and again, you show us that you are _horribly_ confused and that
much of your dislike of Common Lisp comes not from Common Lisp, but from
some staggeringly stubborn misconception and refusal to listen to others.
| (This is not to say that I necessarily agree with this point of view,
| just that I remember it.)
The more I read from you, the more I think you are a Scheme person.
This is not a compliment.
| Through the years I have always found the package system to be pretty
| annoying. I often find myself doing the following:
|
| > foo
| ERROR: foo is unbound ; Doh! Forgot that foo is in foo-package
| > (use-package 'foo-package)
| ERROR: symbol FOO-PACKAGE:FOO conflicts with symbol FOO ; Arrggh!!!
Such are the results of incompetence at work. And how typical to react
emotionally at something so fundamentally silly. How come I never have
this problem? Could it be that I use symbol completion in Emacs? Could
it be that when I once in a while do get an _error_ like this, one of the
available restarts is to unintern the old symbol and proceed, so I have
no _problem_ with it? Could it be that I build my packages with care and
actually want to know which package a symbol is in -- _because_ I do not
consider packages and symbols evil?
| So I've always considered packages as more of a necessary evil than a
| feature.
Yop, Scheme is for you, this is becoming clearer and clearer.
| I was told that this view was common in the CL world, as reflected in one
| of Guy Steele's many subtle jokes in CLTLn: in both editions of the book
| the section dealing with packages is "chapter 11", which in the American
| legal system refers to a set of laws dealing with bankruptcy.
I find this unfunny, not because it is offensive, but because it is so
stupid. It could have been a cute pun if it it has been rephrased as
something like "Common Lisp packages are in Chapter 11", but as stated it
is just dumb, mostly because "Chapter 11" is nothing more than a silly
coincidende and it has to be in an expression that relates it to the
U.S. Bankruptcy Code to make any sense.
But your interpretation of what "Chapter 11" sort of "means" is actually
a very good example of how _wrong_ it is to do eval-time interpretation
instead of read-time. It may make for puns (good, bad, atrocious), but
not understanding. Unless one wants to publish books without a Chapter
11 like some hotels do not have a 13th floor because of a similarly bad
case of numerology and mysticism, there will have to be a Chapter 11 in
books with more than 10. E.g., exceptions are bankrupt in Java in your
"interpretation" because they are in Chapter 11 in both editions of "The
Java Language Specification", also written by Steele, et al, so surely
this is not accidental, either. I am sure this is "fun" to people who do
eval-time interpretation with random environments, but I find it _stupid_.
BTW, Chapter 11 of the U.S. Bankruptcy Code (Title, not Chapter, 11 of
the United States Code) is concerned with reorganization. It applies
when your creditors have some hope that they will recover their money if
they can (forcibly) reorganize the company. Chapter 7 (liquidation)
applies when there is no hope and the creditors accept whatever share
they get from the proceeds of its liquidation. This should have been
common knowledge to anyone who has any interest in referring to the
U.S. legal system. A remarkable level of intellectual sloppiness is
necessary to make this connection and to think it has any meaning.
| But in the recent discussion of what "first class symbol" means a number
| of people have made statements that at least imply (and sometimes
| explicitly state) that they like packages, that they think they really
| are a cool feature.
You know, there are some people who move to other countries, or other
places in the same country, whatever, and who manage to _like_ the place
they have moved to, even though it has lots of flaws and problems and
unlikable people and funny smells and such, probably just like the place
they moved from, which they probably also made up their mind to like, but
it may not have worked out, or they wanted something _different_, not for
lack of like. Then there are people who know what they will and will not
like and who are _never_ satisfied or happy with anything, and who are
more than likely to _avoid_ doing anything than doing something they do
not like through and through. Scheme has a history of not doing anything
because they _feared_ that would not like it, or that somebody had made
up their mind they did not like it even before they tried.
I think the ability to make up your mind to like something you _want_ to
use is kind of crucial to survival. There is so much wrong with the
world that one has to accept flaws and imperfections and just get on with
one's purpose in life. People who _have_ no purpose, do not need this.
There is no such thing as a necessary evil. Thinking in such terms is
itself destructive, not only to one's ability to do what is necessary,
but to appreciate the results. If you have deal with necessary evils all
the time, you will be in a state of permanent frustration, and what
better way of expressing this than "I like Common Lisp, but ...", and of
becoming so frustrated with Common Lisp that one spends one's time
griping about the language instead of just getting on with one's life.
But more importantly, the attitude problems that result in one's
inability to "like" something one has to use or do because of many other
factors, such as liking _them_, is actually pandemic to a personality.
People who have to set _all_ the rules, cannot _follow_ any rules. We
have seen this in people who publicly favor going behind their clueless
boss instead of working _with_ him, we have seen this is people who make
their _living_ from other people's trust that they can follow a standard
specification go public with statements that it is "braindamaged".
However, there are people who are actually able to live and prosper in a
system where respecting authorities, the rule of law, your boss and the
chain of command, etc -- one does not _have_ to be a criminal to make
money or become rich, but it helps some, like Bill Gates and Enron and
such, but by far most criminals end up rather destitute or dead at an
early age. Protesting against authority is an immature youth thing, part
of breaking free from your parents, but some people actually figure out
that authority itself is not what made it necessary to break with your
parents, and they do not have to break with every other authority the
same way.
| For those of you who feel this way I have the following question: were
| you aware of the eval-time alternative for resolving name conflicts
| provided by environments?
Yes, we call them hashtables using strings for keys. Oh, right, Scheme
does not have hashtables. Common Lisp also supports hashtables that use
keywords for keys.
| And if you were, what is it that makes you prefer packages?
This question makes absolutely no sense. If I am aware of the existence
of white meat, why do I prefer red meat? I like both, I eat both, but on
different occasions. I use hashtables with string keys for some things
and keyword for others. I sometimes use the package system because the
reader is such a convenient function that I do not want to reimplement
it, and the package system has some really nifty features that, if you
can come to like what you have, you can find good use for.
If you cannot like what you have freely accepted, there is something
wrong with you. If you do not accept something, but you cannot break
free from it, there is something wrong with you. You have but one life
to live, and it is too short to remain too long with your mistakes and
too long _not_ to leave them behind in time.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> I begin to see where you come from and where you went wrong, Erann. This
> is such a stupid thing to say that I marvel at the respect you must have
> felt for this mentor. I hope _I_ shall never have a student who does not
> have in him the ability to say "that's a load of crap, Erik" if I make a
> similarly retarded point and expect people to believe it, not laugh.
That's a load of crap, Erik. Having respect for someone doesn't mean that
you believe everything they say.
> Have you actually ever understood Common Lisp at all, Erann?
I don't know. That's what I'm trying to figure out. You're not being
much help.
> I have to wonder. At read
> time, a string is interned in only one package to return a symbol. There
> _is_ no symbol without the package.
Uninterned symbols have no package. Have you ever understood Common Lisp
at all, Erik?
> Again and again, you show us that you are _horribly_ confused
That's true. I am horribly confused. Whether that's my fault or the
fault of the people trying to explain things to me is unclear.
> and that much of your dislike of Common Lisp
That is false. I like Common Lisp very much.
> comes not from Common Lisp, but from
> some staggeringly stubborn misconception and refusal to listen to others.
Do you even realize that earlier in this very same post you berated me not
for my refusal to listen, but for having listened?
> | Through the years I have always found the package system to be pretty
> | annoying. I often find myself doing the following:
> |
> | > foo
> | ERROR: foo is unbound ; Doh! Forgot that foo is in foo-package
> | > (use-package 'foo-package)
> | ERROR: symbol FOO-PACKAGE:FOO conflicts with symbol FOO ; Arrggh!!!
>
> Such are the results of incompetence at work.
One could respond the same way to every frustration anyone has ever had
with any programming language. On this view every problem anyone has
with, say, C++, is not a problem with C++ but merely incompetence on the
part of the user. Some people actually believe this.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> > I begin to see where you come from and where you went wrong,
> > Erann. This is such a stupid thing to say that I marvel at the
> > respect you must have felt for this mentor.
> That's a load of crap, Erik. Having respect for someone doesn't
> mean that you believe everything they say.
Then it was worse, it was blind faith.
> > Have you actually ever understood Common Lisp at all, Erann?
> I don't know. That's what I'm trying to figure out. You're not
> being much help.
It helps if you try to understand what he's telling you and stop
bringing up rants from misguided people who confuse orthogonal
concepts.
> > I have to wonder. At read time, a string is interned in only
> > one package to return a symbol. There _is_ no symbol without
> > the package.
> Uninterned symbols have no package. Have you ever understood Common
> Lisp at all, Erik?
It's a good thing you removed (from your mind?) the rest of the
context in order to make it look wrong. You were talking about
choosing the right package to intern into at read time.
> > Again and again, you show us that you are _horribly_ confused
> That's true. I am horribly confused. Whether that's my fault or the
> fault of the people trying to explain things to me is unclear.
That's easy. If you don't understand something that many others
understand and use effectively, they obviously learned it somehow. Why
don't you try learning it, too, instead of trying to figure out whom
to blame next?
> > and that much of your dislike of Common Lisp
> That is false. I like Common Lisp very much.
You seem to complain about it more than enough and intentionally
misunderstand it enough. And as one of the basic principles of Common
Lisp, a dislike of packages implies a dislike of Lisp and symbolic
processing itself.
> > comes not from Common Lisp, but from some staggeringly stubborn
> > misconception and refusal to listen to others.
> Do you even realize that earlier in this very same post you berated
> me not for my refusal to listen, but for having listened?
Blind faith involves the listener consciously choosing to stop
listening at that point.
> > | Through the years I have always found the package system to be pretty
> > | annoying. I often find myself doing the following:
> > |
> > | > foo
> > | ERROR: foo is unbound ; Doh! Forgot that foo is in foo-package
> > | > (use-package 'foo-package)
> > | ERROR: symbol FOO-PACKAGE:FOO conflicts with symbol FOO ; Arrggh!!!
> >
> > Such are the results of incompetence at work.
>
> One could respond the same way to every frustration anyone has ever had
> with any programming language. On this view every problem anyone has
> with, say, C++, is not a problem with C++ but merely incompetence on the
> part of the user. Some people actually believe this.
If someone has a problem with understanding what a feature of C++
means, it's the fault of that person for not understanding it, not the
fault of the language for including it. Maybe it was designed for
people with different goals. In this case, it's clearly a result of
the fact that you forgot to think about what you were doing before
doing it. If you realized that packages formed contexts within which
symbols were interpreted, you wouldn't have had this problem. It's
like looking in the wrong module for a value in a scheme system. Is it
scheme's fault that you chose to look where you didn't want to?
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> You seem to complain about it more than enough and intentionally
> misunderstand it enough. And as one of the basic principles of Common
> Lisp, a dislike of packages implies a dislike of Lisp and symbolic
> processing itself.
Geez! Erann actually *likes* CL, probably more than Scheme, but
(I'm guessing) doesn't happen to think it is Absolutely Perfect. As a
result, he perhaps complains about things once in a while.
And anyone who complains must therefore dislike CL!?
One must think CL packages are really the best thing ever, or else one
not only dislikes CL in general, but also Lisp, and "symbolic
processing itself"?
Puhleez.
> If someone has a problem with understanding what a feature of C++
> means, it's the fault of that person for not understanding it, not the
> fault of the language for including it.
Actually, that's not quite true. One of the tasks of a language
designer is to make the language easy to understand. C++ more or less
fails on that score (at least as judged by the conceptual elegance of
both CL and Scheme). This is a fault to be chalked up to the language
designer as much as to the people who have trouble understanding the
result.
Thomas
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
>
> > You seem to complain about it more than enough and intentionally
> > misunderstand it enough. And as one of the basic principles of Common
> > Lisp, a dislike of packages implies a dislike of Lisp and symbolic
> > processing itself.
>
> Geez! Erann actually *likes* CL, probably more than Scheme, but
> (I'm guessing) doesn't happen to think it is Absolutely Perfect. As a
> result, he perhaps complains about things once in a while.
He seems to not like actually using it, then.
> One must think CL packages are really the best thing ever, or else one
> not only dislikes CL in general, but also Lisp, and "symbolic
> processing itself"?
CL packages are merely an implementation of namespacing for
symbols. Claiming that they should be replaced with a totally
orthogonal system is claiming that symbols should not be namespaced,
which means that having multiple symbolic processing systems operating
on the same data is subject to name clashes.
> Actually, that's not quite true. One of the tasks of a language
> designer is to make the language easy to understand. C++ more or less
> fails on that score (at least as judged by the conceptual elegance of
> both CL and Scheme). This is a fault to be chalked up to the language
> designer as much as to the people who have trouble understanding the
> result.
Except that this is the sole feature which allows people to use the
language in it's professed primary purpose, symbolic processing. If
you misunderstood what the point of the "new" operator in C++ was and
claimed that it should be replaced with interned strings, would that
be a failing of C++?
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> ·········@becket.net (Thomas Bushnell, BSG) writes:
>
> > Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> >
> > > You seem to complain about it more than enough and intentionally
> > > misunderstand it enough. And as one of the basic principles of Common
> > > Lisp, a dislike of packages implies a dislike of Lisp and symbolic
> > > processing itself.
> >
> > Geez! Erann actually *likes* CL, probably more than Scheme, but
> > (I'm guessing) doesn't happen to think it is Absolutely Perfect. As a
> > result, he perhaps complains about things once in a while.
>
> He seems to not like actually using it, then.
So he must like everything about it, or he's against it?
There are lots of things about my Debian GNU/Linux systems that I
complain about. It does not follow that I don't like Debian, or that
I think Posix is a waste.
> CL packages are merely an implementation of namespacing for
> symbols. Claiming that they should be replaced with a totally
> orthogonal system is claiming that symbols should not be namespaced,
> which means that having multiple symbolic processing systems operating
> on the same data is subject to name clashes.
Erann didn't make any such claim at all. He didn't express an
opinion; he just said that packages got in his way once or twice, and
he'd heard from really well connected people that they were (at least
once) regarded as rather a necessary wart on Common Lisp than a great
feature. So he was wondering the reasons why they were now being
toutes as a great feature.
He didn't claim that they should be replaced at all.
> Except that this is the sole feature which allows people to use the
> language in it's professed primary purpose, symbolic processing.
I think this is a great misunderstanding of what "symbolic processing"
is about. However, I'm not interested in having that conversation
with you. (Kent, if you find it worth discussing, then I am
interested in having that conversation with you.)
Thomas
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> > ·········@becket.net (Thomas Bushnell, BSG) writes:
> > > Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> > > Geez! Erann actually *likes* CL, probably more than Scheme, but
> > > (I'm guessing) doesn't happen to think it is Absolutely Perfect.
> > > As a result, he perhaps complains about things once in a while.
Once in a while? What else has he done in c.l.l in the entire time
I've been reading it?
> > He seems to not like actually using it, then.
> So he must like everything about it, or he's against it?
No, but he doesn't seem to like anything about it that he couldn't get
elsewhere, along with other features that he would like better.
> There are lots of things about my Debian GNU/Linux systems that I
> complain about. It does not follow that I don't like Debian, or that
> I think Posix is a waste.
But do you spend most of your posts complaining about debian on
············@l.d.o? Not that I've seen. Note that Erann hasn't made
any suggestions on how to accomodate symbol namespacing without CL
packages yet, and neither have you.
> Erann didn't make any such claim at all. He didn't express an
> opinion; he just said that packages got in his way once or twice, and
> he'd heard from really well connected people that they were (at least
> once) regarded as rather a necessary wart on Common Lisp than a great
> feature. So he was wondering the reasons why they were now being
> toutes as a great feature.
> He didn't claim that they should be replaced at all.
He claimed that he agreed with someone who said that they should be
replaced. I don't see what the material difference is unless you're
claiming that he didn't know what he was agreeing with.
> > Except that this is the sole feature which allows people to use the
> > language in it's professed primary purpose, symbolic processing.
> I think this is a great misunderstanding of what "symbolic processing"
> is about.
Then you misunderstand that name clashes are a fatal situation in
symbolic processing. It's like doing side-effects while ignoring
structure-sharing.
> However, I'm not interested in having that conversation with you.
> (Kent, if you find it worth discussing, then I am interested in
> having that conversation with you.)
I agree that Kent is much more knowledgable than I am. I don't see how
that makes my input useless, but I guess that's your personal bias.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> No, but he doesn't seem to like anything about it that he couldn't get
> elsewhere, along with other features that he would like better.
The fact that he may complain about features X, Y, and Z does not mean
that he doesn't like A, B, and C.
> But do you spend most of your posts complaining about debian on
> ············@l.d.o? Not that I've seen. Note that Erann hasn't made
> any suggestions on how to accomodate symbol namespacing without CL
> packages yet, and neither have you.
I can't speak for Erann. I've already said several times that, in the
general framework of Common Lisp, I think that Common Lisp packages
are the best way I know of to get what someone would want from them.
But that doesn't mean that they always do just what I wish; there are
things about them that I wish were different, but seem essentially
required by the way they have to work to get the other things that are
important, and are well done. This is, I suspect, why Guy Steele also
thought they were a little wartish.
> Then you misunderstand that name clashes are a fatal situation in
> symbolic processing. It's like doing side-effects while ignoring
> structure-sharing.
You are confusing one implementation of symbolic processing with the
very concept of symbolic processing.
* Thomas Bushnell wrote:
> I can't speak for Erann. I've already said several times that, in the
> general framework of Common Lisp, I think that Common Lisp packages
> are the best way I know of to get what someone would want from them.
Well, as someone who seems to have been occasionally tarred with the
`thinks CL is perfect' brush, I'll say that I think this is not so. I
think the CL package system is really not that great. *However* I
don't have any coherent suggestions about how it could be made
compatibly better, so I don't tend to complain too vociferously about
it.
Here are some of the things I'd like to see be different:
Locks on packages (how to do them)?
User-defined external-only packages and automatic-self-binding
packages (like KEYWORD).
Package inheritance (like my conduits system, except better thought
out). This can be done as a user, but it really needs system-level
support to make sure all the errors that should be signaled really
are.
Hierarchical names for packages and some notion of a `current package
directory' and per-directory nicknames. If I'm in the `COM.CLEY'
context I want to be able to say that, as well as WELD refering to
COM.CLEY.WELD, NET refers to ORG.ALU.NET-COMPATIBILITY or something.
User-controlled interning. I want to be able to step in at the point
where the reader has got a string which is a symbol candidate and tell
it what to do. This makes it much easier to use READ in `unsafe'
contexts without interning a mass of symbols that you can't later
find.
The only thing I've even thought about hard is the third of these: I
think that, even if this is an uncontentious set of things people
would like (unlikely) that there is a lot of fairly serious design
work here (not to mention looking at existing implementations).
--tim
Tim Bradshaw <···@cley.com> writes:
> Well, as someone who seems to have been occasionally tarred with the
> `thinks CL is perfect' brush, I'll say that I think this is not so.
CL is by no means perfect, it's just a good compromise for the
features that the Lisp community wanted at the time.
> I think the CL package system is really not that great.
I think it's more than good enough for what it does. Most of what you
talk about below are layers on top of packages or extra features in
other systems which use packages and symbols.
> *However* I don't have any coherent suggestions about how it could
> be made compatibly better, so I don't tend to complain too
> vociferously about it.
Yes, that's what I'm trying to explain to Erann and Thomas. They're
merely complaining about a feature without providing suggestions for
improvement.
> Here are some of the things I'd like to see be different:
> Locks on packages (how to do them)?
ACL has an implementation of this, no? I think it's time to
standardize on an API for it. With more and more Lisp applications out
there, we'll need more and more to ensure that they don't accidentally
do nasty things to symbols they don't own.
> User-defined external-only packages and automatic-self-binding
> packages (like KEYWORD).
That's a good idea. I could especially use the external-only
packages. Not needed, but a nice convenience. Hmm, but there are
issues with local variables used in the defintions of symbols in that
package. I'm not exactly sure how to effectively handle that
situation.
> Hierarchical names for packages and some notion of a `current package
> directory' and per-directory nicknames. If I'm in the `COM.CLEY'
> context I want to be able to say that, as well as WELD refering to
> COM.CLEY.WELD, NET refers to ORG.ALU.NET-COMPATIBILITY or something.
ACL and CMUCL implement the same API for hierarchial names, but I
don't think they have per-directory nicknames. That would be a nice
addition.
> User-controlled interning. I want to be able to step in at the point
> where the reader has got a string which is a symbol candidate and tell
> it what to do. This makes it much easier to use READ in `unsafe'
> contexts without interning a mass of symbols that you can't later
> find.
This is one feature of my generic-reader which is a subproject of
DefDoc. I designed it both so that I can check package access controls
as well as read normal text. All the usual caveats about time apply.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> Yes, that's what I'm trying to explain to Erann and Thomas. They're
> merely complaining about a feature without providing suggestions for
> improvement.
I guess I have to say it again:
I don't have any complaints about the Common Lisp package system.
It's not perfect, but I can't see any better way to solve the problems
that it does solve for Common Lisp. And, from what I understand, that
was Guy Steele's feelings about it too.
Thomas
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> > No, but he doesn't seem to like anything about it that he couldn't get
> > elsewhere, along with other features that he would like better.
> The fact that he may complain about features X, Y, and Z does not mean
> that he doesn't like A, B, and C.
He can get A, B, and C without X, Y, and Z from a different community,
from what I've seen about A, B, C, X, Y, and Z.
> > Then you misunderstand that name clashes are a fatal situation in
> > symbolic processing. It's like doing side-effects while ignoring
> > structure-sharing.
> You are confusing one implementation of symbolic processing with the
> very concept of symbolic processing.
The concept of avoiding name clashes is an implementation of symbolic
processing?
You are confusing constructive criticism with whining. Now figure out
what you really want from symbol namespaces and explain how to get
that or accept them as they are and either use them or don't.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
In article <··············@photino.sid.rice.edu>,
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> ·········@becket.net (Thomas Bushnell, BSG) writes:
>
>> Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
>> > ·········@becket.net (Thomas Bushnell, BSG) writes:
>> > > Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
>
>> > > Geez! Erann actually *likes* CL, probably more than Scheme, but
>> > > (I'm guessing) doesn't happen to think it is Absolutely Perfect.
>> > > As a result, he perhaps complains about things once in a while.
>
> Once in a while? What else has he done in c.l.l in the entire time
> I've been reading it?
couldn't that be because he thinks ngs are for a little bit more than
mutual administration societies? something like "i like cl, vut have
problems with this feature, so what do others think is good about it
or what alternatives are there"?
> ...
hs
--
don't use malice as an explanation when stupidity suffices
··@heaven.nirvananet (Hartmann Schaffer) writes:
> In article <··············@photino.sid.rice.edu>,
> Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> > ·········@becket.net (Thomas Bushnell, BSG) writes:
> >> Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> >> > ·········@becket.net (Thomas Bushnell, BSG) writes:
> >> > > Geez! Erann actually *likes* CL, probably more than Scheme, but
> >> > > (I'm guessing) doesn't happen to think it is Absolutely Perfect.
> >> > > As a result, he perhaps complains about things once in a while.
> > Once in a while? What else has he done in c.l.l in the entire time
> > I've been reading it?
> couldn't that be because he thinks ngs are for a little bit more than
> mutual administration societies?
But they are for a little bit more than people just complaining that
"you lied to me!".
> something like "i like cl, vut have problems with this feature, so
> what do others think is good about it or what alternatives are
> there"?
Erann never asked questions about what is better, he complained to us
that Python is better than CL, and it's our fault that he thought
otherwise. And then he claimed that packages should be removed and
replaced with modules. That is not a useful idea for people who need
to use symbols as objects, a common occurence in the Lisp community,
from all that I can gather.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> ·········@becket.net (Thomas Bushnell, BSG) writes:
>
> > However, I'm not interested in having that conversation with you.
> > (Kent, if you find it worth discussing, then I am interested in
> > having that conversation with you.)
Thomas, I'm enjoying chatting with _both_ of you guys, first of all.
But, just fyi, a quick scan of the last 100 messages shows that you
have replied to nearly every single message of the 20 or so Rahul has
sent in the last day. If you want not to engage him in conversation,
the conventional tool is not to hit "r" when viewing one of his
posts. ;)
> I agree that Kent is much more knowledgable than I am. I don't see how
> that makes my input useless, but I guess that's your personal bias.
I don't personally like mustard or olives or horseradish. That doesn't
make those things without worth. Someone is still buying them from the
grocery store even when I don't.
Worth is a complex commodity and people spend too much time here
debating the worth of others as if any finite number of people were
even in a position to judge this, or as if having judged it there were
any materially interesting action that could then be taken that was
justified by such a judgment. I recommend simply ignoring those you
don't find of worth. Others may still find them of worth, or not, but
the outcome will likely be the best.
Conversations are usefully made of people of all skill levels. Even
people with no skill come with intuitions and these are often
conversationally useful among people who engage in respectful conversation.
Incidentally, Thomas, my entire rant on "data hygiene" was a _direct_
response to something Rahul said. Had he not posted his remarks, I
wouldn't have had occasion to sit for a while pondering that answer,
which I'm quite happy to have penned. I'm not saying Rahul's posts
have no content value, but even if they accomplished only catalyzing
the speech of others, I would not discount that as conversational
value. We each offer value in our own way and at our own time.
Further, I think a much neglected value metric in this forum is "what it
takes to keep the 'interesting' people here". Everyone has their notion
of who's interesting and who's not, so I'm not trying to single anyone
out, but I often feel as if people think that they want the newsgroup
to have only the interesting people and to have the others stand down.
But sometimes the interesting people are here only because of others who
may be disliked, or cause a stir, or be otherwise problematic. In fact,
this is an ecology, and I urge everyone not to think that killing the
mosquitos (whoever you think those people might be) will have no effect
on the food chain. Just bite into the food you find tasty and avoid
the things that taste bad or sting and be happy you live in the richness
of the jungle instead of the arctic where few things grow ...
Kent M Pitman <······@world.std.com> writes:
> Incidentally, Thomas, my entire rant on "data hygiene" was a _direct_
> response to something Rahul said. Had he not posted his remarks, I
> wouldn't have had occasion to sit for a while pondering that answer,
> which I'm quite happy to have penned. I'm not saying Rahul's posts
> have no content value, but even if they accomplished only catalyzing
> the speech of others, I would not discount that as conversational
> value. We each offer value in our own way and at our own time.
Thanks, Kent. :)
By the same logic, Thomas and Erann are at least as valuable to this
thread as I am, and I would have never enumerated my list of features
I find useful in CL if it weren't for their remarks. So thanks to
them, too. :)
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> By the same logic, Thomas and Erann are at least as valuable to this
> thread as I am, and I would have never enumerated my list of features
> I find useful in CL if it weren't for their remarks. So thanks to
> them, too. :)
Yeah, and to join the love fest, I was over-harsh to Rahul in my
stream of recent messages. He too has stimulated my thinking in
productive ways. One thing I can say is that the whole conversation
has certainly helped me understand the whole durn thing better than I
did before, and that's a good thing, all round.
Thomas
"Rahul Jain" <·····@sid-1129.sid.rice.edu> wrote in message
···················@photino.sid.rice.edu...
> ·········@becket.net (Thomas Bushnell, BSG) writes:
>
> > Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> > > ·········@becket.net (Thomas Bushnell, BSG) writes:
> > > > Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
>
> > > > Geez! Erann actually *likes* CL, probably more than Scheme, but
> > > > (I'm guessing) doesn't happen to think it is Absolutely Perfect.
> > > > As a result, he perhaps complains about things once in a while.
>
> Once in a while? What else has he done in c.l.l in the entire time
> I've been reading it?
>
It is not my impression that that is what Erann does. I don't always agree
with his approach but I am interested in his opinions and his accounts of
his personal experiences.
> > > He seems to not like actually using it, then.
>
> > So he must like everything about it, or he's against it?
>
> No, but he doesn't seem to like anything about it that he couldn't get
> elsewhere, along with other features that he would like better.
I think that sentiment is more than being overly sensitive to
criticism/confusion/disagreement. (Just MO)
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
* Thomas Bushnell, BSG
| So he must like everything about it, or he's against it?
It is the other way around. Only those who are against it, express their
dislike of it. Those who are for it, think in a very different way: "It
would be even better if ...". The difference between dislike and like
less than some hypothetical situation can seem hard to grasp, but think
of a line, with zero in the middle. Dislike is on the left of the zero.
Like is on the right of the zero. "Like less than some hypothetical"
ought to have both on the right of the zero, and that is certainly the
case for "it would be even better if ...". But in effect, yes, one's
opinion of all features of something one has chosen to work with and
wishes to become proficient and productive in should all be on the
positive side. That does mean that one has to defend them all or that
one does not prefer one way over another, perhaps never using a feature,
but active dislike is so psychologically destructive that you have people
constantly complain about it instead of just getting over it and on with
their lives. You and Erann Gat keep bad-mouthing Common Lisp all the
time. To those who wish to become proficient and productive in Common
Lisp, this is actually really destructive. It is like going to a bar
with your friends and haveing to suffer someone who berates something or
other about your girlfriend or wife or kids or cat or perhaps your car or
your job or your house or whatever _all_ the time. This pisses most
people off _tremendously_, to the point where people actually resort to
violence to make the shitheads shut up or leave. For a community like
ours, it is like having someone come to a bar regularly only to whine
about the beer or the hygiene or the furniture or the decorations or the
bartender or whatever. That someone would be beaten up if he refused to
leave the others in peace to enjoy themselves. Common decency strongly
suggests that such naysayers and shitheads just get the hell out of the
place, but for some reason, shitheads like you and Erann Gat keep coming
to the same bar and keep deriding and denigrating something that a lot of
the people there actually come there _because_ they like. Now, to keep
this metaphor, everybody will appreciate a suggestion to make something
better if they perceive it to be in good will, i.e., with respect for
what has already been done, but if your suggestion is not adopted, it is
very _rude_ to keep suggesting it over and over (no matter how politely
it has been suggested) To change the scene a little: If someone should
argue that your cat would look a lot better with short hair, the only
appropriate answer is that then it would have to be a different cat. To
really make you destructive shitheads realize what you are doing, suppose
you talked to a black guy in the highly racially sensitized United States
and told him that he would probably be a much better person if he were
white. That probably overstates the case a little, but having you and
Erann Gat and shitheads like you around here to rag Common Lisp all the
time is extremely unwelcome. And the message I keep trying to send to
you obnoxious assholes is just that: Get the fuck out of here if all you
come here to do is deride and berate and denigrate the _one_ common
interest to the people in this forum. People will generally listen to
your problems and try to help you if you have a constructive purpose to
some frustration or other, but if all you want to do is complain that
what you want to do is not perfectly acceptable and you do not _want_ a
solution, people _will_ tire of you, some more quickly than others.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
[Warning: this post contains no technical content whatsoever. If you
don't want to waste your time on such posts stop reading now.]
What an interesting day. I decided to take a usenet break this weekend,
and I got up this morning to find 200+ unread postings in c.l.l. It took
me three hours just to make an initial pass through them to select the
ones that I wanted to go back and study and think about in detail and
maybe respond to. There turned out to be about twenty of those, so I
thought I would consolidate my responses in two posts.
I decided on two posts because there are two classes of resonses I want to
write. The first is technical. The second is responding to posts from
people expounding on what I think, and making various kinds of accusations
against me. This is the non-technical response.
I must say that it has been absolutely fascinating watching myself be
discussed in the third person. It's been almost as educational as reading
the technical discussions (from which I have learned a lot already).
Since I happen to believe that I am somewhat of an authority about what I
think I thought I would weigh in on some points of this discussion.
* Rahul Jain:
> You seem to complain about it more than enough and intentionally
> misunderstand it enough. And as one of the basic principles of Common
> Lisp, a dislike of packages implies a dislike of Lisp and symbolic
> processing itself.
...
> He seems to not like actually using it, then.
As I have said before, I like CL very much. I also like using it. It is
by far my favorite programming language and has been for over twenty
years. CL has been very good to me. In fact, my affection for CL, the
reasons behind it, and why that affection has been somewhat atenuated
recently, is documented in some detail in the post that started the "How I
lost my faith" thread.
Nonetheless, there are things about CL that I don't like, and there are
things about CL that I don't understand. Affecting change about those
things I don't like and achieving understanding about those things I don't
understand has to start with a question that has at least implicit within
it some level of discontent. If everything were perfect there would be
nothing to say. (Likewise if everything were hopeless.)
It is truly ironic hearing people here in c.l.l. tell me and others how
much I dislike CL. At JPL (and Google) my reputation is the exact
opposite. I am the Lisp Freak, the one who thinks Lisp is perfect and the
Answer to Everything. My enthusiasm for Lisp has actually been
detrimental to my career.
The truth is you're all wrong. I'm not a CL fanatic, and I'm not a CL
hater. And if you want to know more about what I think just ask. I'm not
shy about discussing my opinions if I think someone actually cares.
* Rahul Jain:
> He [Erann] claimed that he agreed with someone who said that they [packages]
> should be replaced.
Not so. I fact, I explicitly disclaimed agreement by saying that I merely
recalled this person's opinion, and not necessarily that I agreed with
it. The only opinion of my own that I have expressed about packages is
calling them a "necessary evil", the emphasis in this case being on the
word necessary.
* Rahul Jain:
> > > As a result, [Erann] perhaps complains about things once in a while.
> Once in a while? What else has he done in c.l.l in the entire time
> I've been reading it?
How long have you been reading it? I've been posting on c.l.l. since 1990.
But that aside, could you please cite a few examples of postings of mine
that you consider complaints? I believe that what I've been mostly doing
recently is asking questions.
* Erik Naggum:
> Only those who are against it, express their dislike of it.
This, like much of Erik's rhetoric, is so ridiculous as to barely deserve
response. Nonetheless, people on usenet seem to glom on to lots of
ridiculous ideas, and this particular idea is dangerous if too many people
start to think that Erik might be right about it. So for the record I
express my absolute dissent from this view. This is the rhetoric of the
demagogue. It serves no purpose but to marginalize dissent, which is the
first step on the road to fascism.
* Erik Naggum:
> This arrogance is probably the reason why you never _listen_ to anyone.
Being lectured on arrogance by Erik is so funny that words fail me. Erik,
you should really stop confusing not listening to *you* with not listening
to anyone. They are not the same thing. But in point of fact I listen
even to you, because people I respect keep telling me you have worthwhile
things to say if one takes the time to dig through the crap. So I keep
digging, despite the fact that my personal opinion is that I long since
passed the point of diminishing returns. Such is my respect for some
people's opinions that differ with my own.
* Rahul Jain: (Do we begin to notice a pattern here?)
> Erann never asked questions about what is better,
Yes, that's because I didn't want to start a flame war. What I asked to
start this thread is why the people who like packages like them. This is
because what I am trying to do is not resolve the question of which is
better (I don't think that question can be resolved) but simply to
understand the point of view of people who think differently from me.
* Rahul Jain:
> he complained to us that Python is better than CL,
> and it's our fault that he thought otherwise.
Excuse me? When did I ever say anything of the sort? The closest thing I
can think of is: "For example, my language of choice for doing Web
development now is Python." That was an offhand, almost throwaway comment
at the end of a *very* long post. And note the disclaimer "for doing Web
development." Web development is only a very small part of what I do.
* Nicolas Neuss:
> Your CV looks impressive, but after having this conversation with you
> and reading so much about your problems on c.l.l., I do not believe
> anymore that it tells the truth.
Wow. I've been accused of a lot of things, but this is the first time
anyone has actually accused me of fraud. Nicolas, I will provide you with
documentation for any claim on my CV that you find questionable with the
proviso that if I do so you must agree to apologise pulicly for defaming
me. (Actually, you can verify everything on there yourself if you wish,
and you would have been well advised to do so before making your libelous
acusation.)
This really pisses me off much more than I care to express at the moment.
Erann Gat, Ph.D.
Principal Scientist
Jet Propulsion Laboratory
California Institute of Technology
Pasadena, California
···@jpl.nasa.gov
The views expressed here are my own. I do not speak for JPL.
* Erann Gat
| This, like much of Erik's rhetoric, is so ridiculous as to barely deserve
| response.
I marvel at the psychological problems that produce your need to respond.
| Being lectured on arrogance by Erik is so funny that words fail me.
I would much prefer they _actually_ did.
| Erik, you should really stop confusing not listening to *you* with not
| listening to anyone.
You take the time off from your productive life to complain that people
say bad things about you and you do not find _yourself_ ridiculous when
you spend an _enormous_ amount of time badmouthing me to the point that
people who do not even know me cannot figure out what I could possibly
have done to cause your psychotic break and the scary monsters you see.
What if you tried to understand what I say, Erann? What dangers are your
mind protecting you from when it shut down and you consistently fail to
listen? How much truth have I _really_ said about you that you need to
pretend so much? It is obvious that I have really freaked you out --
into some kind of self-protective position where you _have_ to pretend
that what I say is so "ridiculous" and "funny" that you do not have to
look too closely at it. These are quite obviously defense mechanisms.
Just cut it out. Get over whatever it was that hurt so badly and move
the hell _on_, dude. Whatever it is that I can do that hurts so much
only gets worse every time you stupidly decide to attack me to feel
better. If not, it would have worked and you would have quit, right?
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
···@jpl.nasa.gov (Erann Gat) writes:
> [...]
> * Nicolas Neuss:
>
> > Your CV looks impressive, but after having this conversation with you
> > and reading so much about your problems on c.l.l., I do not believe
> > anymore that it tells the truth.
>
> Wow. I've been accused of a lot of things, but this is the first time
> anyone has actually accused me of fraud. Nicolas, I will provide you with
> documentation for any claim on my CV that you find questionable with the
> proviso that if I do so you must agree to apologise pulicly for defaming
> me. (Actually, you can verify everything on there yourself if you wish,
> and you would have been well advised to do so before making your libelous
> acusation.)
I think you are right here. I apologize. As much as I see the data
given on http://www.flownet.com/gat/resume.html can be certified and
is therefore probably correct. My doubts were more directed towards
your "How I lost my faith"-post and your recent questions. That is:
1. How can anyone do a reasonable Lisp development without
understanding AND ACCEPTING the package mechanism which you started
a discussion about?
2. How can anyone work successfully together with other people at JPL
or at Google, when he has such difficulties in understanding other
people? What I hoped with my question was that someone who
actually worked with you (e.g. Norvig at Google) could clarify
things.
3. Why do you have to follow up every damned message you do not
understand (and these are plenty) asking for further elaboration?
Why can't you simply accept answers people give here, ponder them
several days (at least) and WORK FOR YOURSELF to acquire sufficient
knowledge for continuing. As much as I remember you told us that
you do not actively work with CL anymore, so I get the impression
that you want the people here to teach you without the pondering
and working step you should do. I do not see how I could work
together with someone doing that constantly, so I hoped that some
colleagues of yours could explain it to me.
Nicolas.
In article <··············@ortler.iwr.uni-heidelberg.de>, Nicolas Neuss
<·············@iwr.uni-heidelberg.de> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > [...]
> > * Nicolas Neuss:
> >
> > > Your CV looks impressive, but after having this conversation with you
> > > and reading so much about your problems on c.l.l., I do not believe
> > > anymore that it tells the truth.
> >
> > Wow. I've been accused of a lot of things, but this is the first time
> > anyone has actually accused me of fraud. Nicolas, I will provide you with
> > documentation for any claim on my CV that you find questionable with the
> > proviso that if I do so you must agree to apologise pulicly for defaming
> > me. (Actually, you can verify everything on there yourself if you wish,
> > and you would have been well advised to do so before making your libelous
> > acusation.)
>
> I think you are right here. I apologize.
Accepted.
> 1. How can anyone do a reasonable Lisp development without
> understanding AND ACCEPTING the package mechanism which you started
> a discussion about?
But I *do* accept it and always have! I'm not asking these questions
because I want the package system to change. I'm asking these questions
because the existence of smart people who think packages are cool rather
than annoying indicates to me that I've missed something very important,
and I'm trying to understand what that is. (After being in a certain
mindset for fifteen years that can be significant task.)
> 2. How can anyone work successfully together with other people at JPL
> or at Google, when he has such difficulties in understanding other
> people?
It's not always easy.
> What I hoped with my question was that someone who
> actually worked with you (e.g. Norvig at Google) could clarify
> things.
Accusing me of falsifying my credentials is an odd way to elicit such a
response.
> 3. Why do you have to follow up every damned message you do not
> understand (and these are plenty) asking for further elaboration?
> Why can't you simply accept answers people give here, ponder them
> several days (at least) and WORK FOR YOURSELF to acquire sufficient
> knowledge for continuing. As much as I remember you told us that
> you do not actively work with CL anymore, so I get the impression
> that you want the people here to teach you without the pondering
> and working step you should do. I do not see how I could work
> together with someone doing that constantly, so I hoped that some
> colleagues of yours could explain it to me.
Because I'm not asking about CL per se, I'm asking about people's
mindsets, and I don't have ESP.
E.
Centuries ago, Nostradamus foresaw when ···@jpl.nasa.gov (Erann Gat) would write:
> In article <··············@ortler.iwr.uni-heidelberg.de>, Nicolas Neuss
> <·············@iwr.uni-heidelberg.de> wrote:
>> 3. Why do you have to follow up every damned message you do not
>> understand (and these are plenty) asking for further elaboration?
>> Why can't you simply accept answers people give here, ponder them
>> several days (at least) and WORK FOR YOURSELF to acquire sufficient
>> knowledge for continuing. As much as I remember you told us that
>> you do not actively work with CL anymore, so I get the impression
>> that you want the people here to teach you without the pondering
>> and working step you should do. I do not see how I could work
>> together with someone doing that constantly, so I hoped that some
>> colleagues of yours could explain it to me.
> Because I'm not asking about CL per se, I'm asking about people's
> mindsets, and I don't have ESP.
The problem isn't with your asking some questions.
Compare/contrast with the recent exchange between Thomas Bushnell and
Kent Pitman.
Kent has expressed what I'd regard as "at least some mild irritation"
at Thomas' tendancy to _continually_ post new messages asking for
minor clarifications here and there. Kent has been quite patient in
responding quite completely and has put quite a lot of effort into it.
Things would probably be much more rewarding for _everyone_ (the
assorted writers as well as the silent "peanut gallery") if the
threads involved a bit more "rumination" between responses, so that
instead of seeing 185 messages, with a _little_ bit of illumination in
each one, we had 18 messages, chock full of goodness.
It's not "don't post;" it's more "think for at least 20 minutes before
you post again" so that there's time for questions and answers to
mature.
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://www3.sympatico.ca/cbbrowne/languages.html
God is real unless declared integer.
Christopher Browne <········@acm.org> writes:
> Kent has expressed what I'd regard as "at least some mild irritation"
> at Thomas' tendancy to _continually_ post new messages asking for
> minor clarifications here and there. Kent has been quite patient in
> responding quite completely and has put quite a lot of effort into it.
I should add that Kent has earned my great thanks for his patience;
I've learned a great deal from the discussion. I ask for
clarification because I *have* thought about something and failed to
find the answer, and I'm glad that Kent has helped me understand some
things that I was previously not as clear on.
In article <··············@chvatal.cbbrowne.com>, Christopher Browne
<········@acm.org> wrote:
> Things would probably be much more rewarding for _everyone_ (the
> assorted writers as well as the silent "peanut gallery") if the
> threads involved a bit more "rumination" between responses, so that
> instead of seeing 185 messages, with a _little_ bit of illumination in
> each one, we had 18 messages, chock full of goodness.
>
> It's not "don't post;" it's more "think for at least 20 minutes before
> you post again" so that there's time for questions and answers to
> mature.
And what makes you think I don't? (And if I may make a suggestion: before
you answer that, think for at least twenty minutes, during which you might
go back and count exactly how many messages I posted in the "packages"
thread that were responses to Kent.)
(Hm, interesting. It seems I actually brought this very same issue up
once before -- in 1993. No one responded at all back then.)
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@ortler.iwr.uni-heidelberg.de>, Nicolas Neuss
> <·············@iwr.uni-heidelberg.de> wrote:
>
> > [...]
> > 1. How can anyone do a reasonable Lisp development without
> > understanding AND ACCEPTING the package mechanism which you started
> > a discussion about?
>
> But I *do* accept it and always have! I'm not asking these questions
> because I want the package system to change. I'm asking these questions
> because the existence of smart people who think packages are cool rather
> than annoying indicates to me that I've missed something very important,
> and I'm trying to understand what that is. (After being in a certain
> mindset for fifteen years that can be significant task.)
That was interesting also for me. I was also biased towards packages,
but only before I used them. After I started using them (together
with defsystem and being kindly helped by the CMUCL mailing list),
they proved to be that nice in comparison with C and Guile modules
that I never questioned their usefulness again.
When I try to reconstruct from where my bias arose, then it is maybe
the Scheme efforts to make the "perfect" module system, but also (more
probable) Note 239 of Graham's ANSI CL book. My conclusion is that
this book is probably the best way from Scheme to CL, but necessarily
followed by a pleading for loop and packages.
Yours, Nicolas.
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> When I try to reconstruct from where my bias arose, then it is maybe
> the Scheme efforts to make the "perfect" module system, but also (more
> probable) Note 239 of Graham's ANSI CL book.
What's the note say? (a paraphrase would be nice, not a
copyright-law-violating reporduction :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
>
> > When I try to reconstruct from where my bias arose, then it is maybe
> > the Scheme efforts to make the "perfect" module system, but also (more
> > probable) Note 239 of Graham's ANSI CL book.
>
> What's the note say? (a paraphrase would be nice, not a
> copyright-law-violating reproduction :)
Just because some aspects of the law are vague or hard to be sure of
without a court ruling does not imply that one must be this vague
about it. It's a bad idea to just allow a mythology to build up for
so important an issue. Don't just assume that because some aspects of
the law are vague that all aspects are.
While there is no definitive rule [there are actually four
contributing considerations with no definitive weighting among
them--they simply must all be taken into account], the practical
effect is that small quotes from a large work are often covered under
fair use and require no permission. (The reason this is not a
definitive rule is that this is neither intended as a technique for
stealing the large work piece by piece, nor as a way of taking some
conceptually-critical textually-small section the surroundings of
which are not conceptually critical.) Reviewers, for example,
commonly quote the reviewed work in places, but their use is not the
original author's use. Whether or not you make money from the result
also matters, though the rule is again not hard and fast: quoting in a
professional review might often be permitted but trying to do a
"hostile open sourcing" probably is not. My guess is that this
particular case would be seen more like a review and would not require
paraphrasing "but I'm not a lawyer". For a fuller and more detailed
description of the actual considerations, I suggest
http://fairuse.stanford.edu/ which is quite well-organized on this
subject and something anyone who doing quotation of another's work
should be familiar with.
The copyright law (of the US anyway) is quite approachable even if the
categorization rules for media are oddly drawn (an artifact of how the
issues arose historically). It's all really well indexed at
http://www.law.cornell.edu/uscode/17/
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> What's the note say? (a paraphrase would be nice, not a
> copyright-law-violating reporduction :)
Sorry, thought about it to late...:
On page 239: "The kind of modularity provided by packages is actually
a bit odd. We have modules not of objects, but of names...
[further explanation] [Note 239]
[Note 239, page 411]: Even experienced Lisp hackers find packages
confusing... [further explanation]
The following explanations are quite OK, so this is probably harmless
for someone who is doing real work with lisp. But when reading it
first, I was trying to understand packages while using Scheme, so I
was left with an uneasy feeling for packages.
Nicolas.
Paolo Amoroso <·······@mclink.it> writes:
> On 20 Mar 2002 19:36:08 +0100, Nicolas Neuss
> <·············@iwr.uni-heidelberg.de> wrote:
>
> > ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> >
> > > What's the note say? (a paraphrase would be nice, not a
> [...]
> > [Note 239, page 411]: Even experienced Lisp hackers find packages
> > confusing... [further explanation]
>
> This additional bit of context might be useful in understanding that note:
>
> ...find packages confusing. Is it because packages are gross, or because
> we are not used to thinking about what happens at read time?
> There is a similar kind of uncertainty about defmacro, and there it does
> seem that the difficulty is in the mind of the beholder.
I agree. Writing statements like this becomes a self-fulfilling prophecy,
since it gives a whole generation of readers license to not think for
themselves about an issue of great practical importance.
If this is going to be a part of what the book intends to teach, it warrants
more than a note. As it is, it seems to me it should have been omitted,
especially since it makes no note of any controversy on the matter.
On 20 Mar 2002 19:36:08 +0100, Nicolas Neuss
<·············@iwr.uni-heidelberg.de> wrote:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > What's the note say? (a paraphrase would be nice, not a
[...]
> [Note 239, page 411]: Even experienced Lisp hackers find packages
> confusing... [further explanation]
This additional bit of context might be useful in understanding that note:
...find packages confusing. Is it because packages are gross, or because
we are not used to thinking about what happens at read time?
There is a similar kind of uncertainty about defmacro, and there it does
seem that the difficulty is in the mind of the beholder.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
* Erann Gat
| That's true. I am horribly confused. Whether that's my fault or the
| fault of the people trying to explain things to me is unclear.
It is your fault. Confusion can never be blamed on anyone else. If you
think it can, you are horribly confused.
* Erik Naggum
> Such are the results of incompetence at work.
* Erann Gat
| One could respond the same way to every frustration anyone has ever had
| with any programming language.
Well, there is a crucial distinction between incompetence at the designer
end of the language and incomptence at the user end of the language. You
seem to conclude thet there can be incompetence only at one end, despite
your deriding Common Lisp "flaws". I wonder how you reconcile this with
yourself, but you probably do not bother.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
···@jpl.nasa.gov (Erann Gat) writes:
···@jpl.nasa.gov (Erann Gat) writes:
> In my formative years I was a fan of T, which for those of you who don't
> know, is a member of the Lisp family of languages ;-) that resembles
> Scheme more than Common Lisp. It is a Lisp-1, but it had a lot of
> features not found in Scheme, like an object system, and a setf-like
> feature called "setters". ("SETTER" was a function which when called on
> another function would return a function that when called would set the
> location referred to by the second function. Whew! e.g.: ((setter car)
> x 1) == (replaca x 1)
...
> But in the recent discussion of what "first class symbol" means a number
> of people have made statements that at least imply (and sometimes
> explicitly state) that they like packages, that they think they really are
> a cool feature. For those of you who feel this way I have the following
> question: were you aware of the eval-time alternative for resolving name
> conflicts provided by environments?
Being one of the central parties making this noise, I'll do something I'm
not big on and actually cite my credentials to show that I am not blathering
out of ignorance:
(1) I, along with Jonathan Rees and Norman Adams, was one of a 3-person
team that kicked of the T effort at Yale. I did the initial language
prototype. I basically wanted to design a language but not a compiler,
and Jonathan wanted to design a compiler but not a language, which is
how he and I teamed up. (Norm was new to it all then and his major
contributions I think came after I left.)
I'm personally responsible for the creation of the creation of the
"locale" concept because Jonathan didn't like the "global" notion
and yet I was convinced people wanted the metaphor even if it had
problems in practice. So we made locales, which were, as I initially
described them, "locally global" workspaces that could serve as
bottom-out points for lexicality to home all otherwise-free references.
I'm also the person who, at Jonathan's request (i.e., it was his idea
but I validated its feasibility), first did the hack, in my Maclisp-based
emulator of making message-sending functions basically use their own
identity as the value to be sent. This is a huge awful pun that could
only work cleanly in a Lisp1 (and we knew that) but basically we did
something like (if I recall the technique, though I've forgotten the
operator names--I only know we spelled out whole words and didn't use
abbrevs like I've used here):
(define (make-op)
(letrec ((op (lambda (self . args) (apply send self op args))))
op))
(define kar (make-op)) ;Make a KAR operation
(define kdr (make-op)) ;Make a KDR operation
So that the handler for an object doing this message would handle
a message whose name was the function that sent the message. (Weird.)
So one day I changed over the operation handlers from something that
did (cond ((eq? msg 'kar) ...) ...) to (cond ((eq? msg kar) ...) ...)
which had the neat [lisp1-only] property that if you renamed the kar
message operation, you also renamed its key. So someone in another
environment used to calling it FIRST and LAST could do
(cond ((eq? msg first) ...) ...)
and didn't have to know that in the sender's environment the name of the
message was KAR, not FIRST. Further, since SETTER is an object message
itself, a renaming of KAR means that SETTER gets called on the
right thing and so (SETTER FIRST) in the environment with FIRST renamed
does exactly the right thing.
It's all very cool. But, then again, it's one of those oh-too-cute
kludges that they're referring to when they say "try not to be
too clever". It's a hack. A hack that works. But a serious
pun. It isn't something that falls out of the beauty of Lisp1. It's
a kludge constructed tenuously from the felicity ("accidental truth")
of Lisp1 and other accidental factors--like that you can compare
procedures with EQ? ... there was a move afoot in Scheme a while back
to say that EQ? should not be a "total" function; that is, that it
should be an error to call it on certain types, functions among them.
Had that been so, the entire kludge that was that cool thing in T
would have not worked, Lisp1 or not. Message objects would have had to
be some other datum than the function itself. But it didn't come out
that way and the punsters of the world (Jonathan and I) won out that day.
I _like_ puns mind you, and I don't feel guilty. I loved
this pun in particular and am glad you remember it fondly. But I
have a real laugh when people talk about Lisp2 as if they are the
home of all puns and Lisp1 is free somehow of the urge to pun.
In any language, people will make use of the semantics to their
advantage. Where namespaces are folded on themselves, people
will use that fact; where they are not, people will use that.
We're all sinners. Let he who thinks he is not cast the first
stone.. (Oh, ouch, that's right--they have. Ok. You can stop now.)
(2) I am among the authors of the Scheme report. I don't get my way a
lot in certain votes, but I like to think that it sometimes matters
that I am there. And in any case, I am aware of how the Scheme
people think about modules. It's been discussed many times among
the members over the years.
(3) I have used Scheme in workplace settings for paid work. I do know how
Scheme works from a practical point of view.
(4) The ISLISP committee, for which I was for a time US Representative from
(X3)J13 and Project Editor. [I continue as Project Editor although not
a J13 member because this is a neutral, non-technical role and does not
require me to be a technical participant nor national representative,
just a helpful guy.] Modules and packages are among the topics
that we discussed some years back but deferred for "future work".
In short, if your question was, am I just making up my preference for packages
because I am ignorant of the alternatives, the answer is: No.
> And if you were, what is it that makes you prefer packages?
Do you want me to repeat the stuff I mentioned under the data hygiene thread?
The short answer is that non-symbols are fine, but they do not a symbolic
processing language make. Some days I don't mind passing around Scheme's
symbols (with their characteristic "no associated meaning") + an environment
(to give the symbols meaning). Other days, I like the power of being able
to have symbols like in CL, where the symbol means something all by itself.
(Most days, in fact.) Passing non-symbols is fine computation, but is not
the essence of symbolic computation.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> Being one of the central parties making this noise, I'll do something I'm
> not big on and actually cite my credentials to show that I am not blathering
> out of ignorance:
I won't follow your example because I don't know if I'm blathering out of
ignorance or not. (That's what I'm trying to figure out.) But if you
want to see my credentials my CV is on the Web. Suffice it to say I've
built a successful career in part by writing Common Lisp code. I feel
fairly confident that I'm sufficiently non-idiotic that if someone can't
explain something in this area so that I can understand it there's a good
chance that it's their fault and not mine.
> > And if you were, what is it that makes you prefer packages?
>
> Do you want me to repeat the stuff I mentioned under the data hygiene thread?
No, but I would like you to expand on something:
> I cannot later 'relate', at the symbol
> level, your person-1 with my person-1, without doing a global renaming.
What does that mean? Can you restate this (which seems to be the crucial
point) without scare quotes and without squishy phrases like "at the
symbol level"?
> The short answer is that non-symbols are fine, but they do not a symbolic
> processing language make. Some days I don't mind passing around Scheme's
> symbols (with their characteristic "no associated meaning") + an environment
> (to give the symbols meaning). Other days, I like the power of being able
> to have symbols like in CL, where the symbol means something all by itself.
> (Most days, in fact.) Passing non-symbols is fine computation, but is not
> the essence of symbolic computation.
Suppose CL had no symbols. It seems I could easily add them by defining
two classes: "symbol" with slots name, value, plist, etc. and "package"
that's really just a hash table that maps strings onto instances of the
symbol class. Probably 20-30 LOC at most. Would that be sufficient? Or
would I still be missing some essential capability? What would it be?
Maybe the problem is that I don't really understand what people mean by
"symbolic processing". A concrete non-contrived example of "symbolic
processing" that's easy in CL and hard in Scheme would probably help.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > Being one of the central parties making this noise, I'll do something I'm
> > not big on and actually cite my credentials to show that I am not blathering
> > out of ignorance:
>
> I won't follow your example because I don't know if I'm blathering out of
> ignorance or not. (That's what I'm trying to figure out.) But if you
> want to see my credentials my CV is on the Web. Suffice it to say I've
> built a successful career in part by writing Common Lisp code. I feel
> fairly confident that I'm sufficiently non-idiotic that if someone can't
> explain something in this area so that I can understand it there's a good
> chance that it's their fault and not mine.
Absolutely true. It is certainly not your fault if people cannot
(so far) explain in all detail how they arrived at what they are
talking about now. Everybody is aware of your impressive
credentials, and you know much, much more about Lisp than I do.
But I do know something about ideas. What you are doing now
looks a bit unfair to me -- Kent seems to have had a sudden,
epiphanic, idea on what might be the source, the root of the
difference in character between Lisp and Scheme; why don't you
give this idea a chance? Of course he cannot prove it formally,
let alone right now. But isn't it worth considering for a while?
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID 0xC66D6E6F
Nils Goesche <···@cartan.de> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > <······@world.std.com> wrote:
> >
> > > Being one of the central parties making this noise, I'll do something I'm
> > > not big on and actually cite my credentials to show that I am not blathering
> > > out of ignorance:
> >
> > I won't follow your example because I don't know if I'm blathering out of
> > ignorance or not. (That's what I'm trying to figure out.) But if you
> > want to see my credentials my CV is on the Web. Suffice it to say I've
> > built a successful career in part by writing Common Lisp code. I feel
> > fairly confident that I'm sufficiently non-idiotic that if someone can't
> > explain something in this area so that I can understand it there's a good
> > chance that it's their fault and not mine.
>
> Absolutely true. It is certainly not your fault if people cannot
> (so far) explain in all detail how they arrived at what they are
> talking about now. Everybody is aware of your impressive
> credentials, and you know much, much more about Lisp than I do.
> But I do know something about ideas. What you are doing now
> looks a bit unfair to me -- Kent seems to have had a sudden,
> epiphanic, idea on what might be the source, the root of the
> difference in character between Lisp and Scheme; why don't you
> give this idea a chance? Of course he cannot prove it formally,
> let alone right now. But isn't it worth considering for a while?
Sorry for following up to myself, but I'd like to add something:
Why don't you try to prove it yourself? I have often found that
it is a good way, even if you don't believe in an idea, to try to
prove it nevertheless: You'll find out what the major obstacles
are and thus gain valuable insight -- that would be much more
productive than demanding a formal prove from others.
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID 0xC66D6E6F
Nils Goesche <···@cartan.de> writes:
> productive than demanding a formal prove from others.
proof
Darn, sometimes even English spelling is hard. Sorry.
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID 0xC66D6E6F
* Erann Gat
| I feel fairly confident that I'm sufficiently non-idiotic that if someone
| can't explain something in this area so that I can understand it there's
| a good chance that it's their fault and not mine.
This arrogance is probably the reason why you never _listen_ to anyone.
There is probably no way to make you revert to a mental state where you
realize that you know less than those who try to tell you something.
You have established that you will only listen to very particular points
that people raise, and not listen to their "philosophical" answers. You
even ridicule me for trying to answer your philosophical _question_. In
order for you to stop being such a prick, you have to snap out of the "I
know all I need to know, thank you" attitude. Your confusion comes from
thinking you know something you do not in fact know. The only possible
solution for you is to stop thinking you know, but judging from how you
respond to every suggestion I make, you will take this to mean that you
should be humiliated and ridiculed because that is what happens when you
flout your arrogance. However, if you could start to think and listen,
and actually try to _learn_ something from what people tell you, instead
of going on your fucking annoying fault-finding missions _all_ the time,
you would be unconfused in no time.
I would actually like to help you and any other victim of confusion, but
when you are so dead certain that you know everything you need to know
and can _arbitrarily_ decide that "I don't get it, and it's his fault",
there is no incentive to try to explain anything to you at all. Only the
people who might read your incessant whining are worth talking to.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Erann Gat <···@jpl.nasa.gov> wrote in message
····················@192.168.1.50...
>
> Suppose CL had no symbols. It seems I could easily add them by defining
> two classes: "symbol" with slots name, value, plist, etc. and "package"
> that's really just a hash table that maps strings onto instances of the
> symbol class. Probably 20-30 LOC at most. Would that be sufficient? Or
> would I still be missing some essential capability? What would it be?
>
> Maybe the problem is that I don't really understand what people mean by
> "symbolic processing". A concrete non-contrived example of "symbolic
> processing" that's easy in CL and hard in Scheme would probably help.
>
A question: what is for you the relation between "L has X",
and "X can be implemented (with effort, without effort) in L"?
In article <··········@news.bluewin.ch>, "Samuele Pedroni"
<········@bluewin.ch> wrote:
> A question: what is for you the relation between "L has X",
> and "X can be implemented (with effort, without effort) in L"?
I think I'd say that if X can be implemented without effort in L then L
has X. If X can be implemented with a little effort in L then L doesn't
have X, but it doesn't matter.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··········@news.bluewin.ch>, "Samuele Pedroni"
> <········@bluewin.ch> wrote:
>
> > A question: what is for you the relation between "L has X",
> > and "X can be implemented (with effort, without effort) in L"?
>
> I think I'd say that if X can be implemented without effort in L then L
> has X. If X can be implemented with a little effort in L then L doesn't
> have X, but it doesn't matter.
So, for example, if safety can be implemented without effort in sex, then
sex has safety. If safety can be implemented with a little effort (say,
wearing a condom) in sex then sex doesn't have safety, but it doesn't matter.
Just wanted to make sure you really meant what you said. ;)
To quote a childhood mantra: "almost only counts in horseshoes and
hand grenades" though in more recent days the expression "and atom bombs"
got added by some kids I knew.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
> To quote a childhood mantra: "almost only counts in horseshoes and
> hand grenades"
I know that from my childhood as well, but only because Col. Potter said
it a lot.
Is that *really* a common expression, somewhere?
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@shell01.TheWorld.com>,
> Kent M Pitman <······@world.std.com> wrote:
>
> > To quote a childhood mantra: "almost only counts in horseshoes and
> > hand grenades"
>
> I know that from my childhood as well, but only because Col. Potter said
> it a lot.
>
> Is that *really* a common expression, somewhere?
I use it quite a bit when bowling (stupid game:-), but I usually
substitute "close" for "almost".
I've heard the atom bomb addendum, as well.
[sorry for continuing off-topic; couldn't resist ... ]
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
>Bruce Hoult <·····@hoult.org> writes:
>
>> In article <···············@shell01.TheWorld.com>,
>> Kent M Pitman <······@world.std.com> wrote:
>>
>> > To quote a childhood mantra: "almost only counts in horseshoes and
>> > hand grenades"
>>
>> I know that from my childhood as well, but only because Col. Potter said
>> it a lot.
>>
>> Is that *really* a common expression, somewhere?
>
>I use it quite a bit when bowling (stupid game:-), but I usually
>substitute "close" for "almost".
>
>I've heard the atom bomb addendum, as well.
>
>[sorry for continuing off-topic; couldn't resist ... ]
The addendum goes back to the mid-70s at least, but
it's not really true, except for very distant values of "close".
paul
>>>>> On Tue, 19 Mar 2002 13:13:34 +1200, Bruce Hoult ("Bruce") writes:
Bruce> In article <···············@shell01.TheWorld.com>,
Bruce> Kent M Pitman <······@world.std.com> wrote:
>> To quote a childhood mantra: "almost only counts in horseshoes and
>> hand grenades"
Bruce> I know that from my childhood as well, but only because Col. Potter said
Bruce> it a lot.
Bruce> Is that *really* a common expression, somewhere?
If you're older.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > Being one of the central parties making this noise, I'll do
> > something I'm not big on and actually cite my credentials to show
> > that I am not blathering out of ignorance:
>
> I won't follow your example because I don't know if I'm blathering out of
> ignorance or not. (That's what I'm trying to figure out.) But if you
> want to see my credentials my CV is on the Web.
I'm not questioning your credentials. I thought you had asked effectively
for mine since your question seemed to ask "is it just the case that the
other side is speaking out of ignorance". Anyone can chime in and tell me
if my credentials seem insufficient--I'm not going to do like VeriSign and
offer a self-validating credential where I both assert credentials and tell
you that you can trust them--but I'm comfortable with them for myself and
willing to have them open to inspection. I _think_ I know what the other
options are. I _wish_ I could feel comfortable using the other options,
but I have repeatedly tried and found both Lisp1 and module-based solutions
inadequate to my personal needs.
> Suffice it to say I've
> built a successful career in part by writing Common Lisp code.
No quibble with your credentials here. I'm not suggesting you are not
entitled to engage in this conversation in any way. I'm just suggesting
you're wrong in point of fact if you think there is no valid defense of a
package system. Packages and modules are orthogonal structures and both
have a place. I'm not anti-module, I'm anti-module-qua-panacea.
> I feel fairly confident that I'm sufficiently non-idiotic that if
> someone can't explain something in this area so that I can
> understand it there's a good chance that it's their fault and not
> mine.
I use this same rule of thumb myself, so I can relate. Then again, I
think you should not conclude from someone's inability to articulate a
natural langauge rule to explain a philosophically complex behavior
that they do not have deep-seated and real beliefs, nor even perhaps
well-founded beliefs. Sometimes people understand but cannot
describe. Sometimes adequate description requires the person
receiving the description to 'fess up enough data about their
confusions that a custom explanation can be rendered adequate to their
needs. I have no doubt you are trying. I have neither any doubt that
my belief in packages is technically, not just emotionally or
historically, well-founded. I'm happy to engage in this discussion
with you on that basis. I'm even happy for you to conclude "Because
Kent and others cannot say what I need to hear, I will continue to
believe what I believe." (That is, I'm happy to live with the belief
that you are wrong. Heh... Which incidentally is on a statement that
you are wrong, it is just a statement about my belief structure.) I'm
not happy for you to assert (and I hope you are not asserting, I'm
just checking) that "The inability of various people to articulate a
defense is a de facto proof that no such defense exists." or that kind
of thing.
> > > And if you were, what is it that makes you prefer packages?
> >
> > Do you want me to repeat the stuff I mentioned under the data
> > hygiene thread?
>
> No, but I would like you to expand on something:
>
> > I cannot later 'relate', at the symbol
> > level, your person-1 with my person-1, without doing a global renaming.
>
> What does that mean? Can you restate this (which seems to be the crucial
> point) without scare quotes and without squishy phrases like "at the
> symbol level"?
I'll be as concrete as I can. I'm trying to be brief, too, so I may have
to add detail later if I've left something out, but here's a sketch of a
sample scenario I intended to address. Examples have the virtue of having
detail that abstract discussions do not. Re-generalize anything you see here
in concrete form back to the abstract when done; my point is not to say
"Here is the problem that worries me and if you fix it the world is well."
My point is rather to say, "My belief that there is a problem would lead
me to hypothesize a specific set of concrete and observable design problems.
Here is an example of one." Further, you should understand that when I say
"design problem" I don't mean "There is no way to compute an answer to this
problem i another system." since we are not talking about computability.
The Turing Equivalence of Scheme and CL is not in question. Rather, we are
talking about the use of a specific paradigm to express a particular problem;
so if in "solving" the technical problem, you switch paradigms, then you have
made my case. The intent of this examples is specifically to show a use of
symbols, so saying "we can substitute non-symbols to solve this" make my case,
it does not refute it... Ok, enough prelude. Here we go...
CL allows me, simply in the symbol data, to control whether I'm doing various
kinds of sharing. For example, I can separate my spaces, as in:
(in-package "FLOWER")
(setf (get 'rose 'color) 'red)
(setf (get 'daisy 'color) 'white)
(defun colors-among (things)
(loop for thing in things
when (get thing 'color)
collect thing))
(in-package "PEOPLE")
(setf (get 'rose 'color) 'white)
(setf (get 'daisy 'color) 'black)
(defun colors-among (things)
(loop for thing in things
when (get thing 'color)
collect thing))
(in-package "OTHER")
(flower:colors-among '(flower:rose people:rose flower:daisy))
=> (FLOWER:RED FLOWER:WHITE)
(flower:colors-among '(flower:rose people:daisy people:rose))
=> (FLOWER:RED)
(people:colors-among '(flower:rose people:rose flower:daisy))
=> (PEOPLE:WHITE)
(people:colors-among '(flower:rose people:daisy people:rose))
=> (PEOPLE:BLACK PEOPLE:WHITE)
Some examples of the value here:
- The information is manifest in symbols, a primitive data structure
in the language
- Both the objects and the properties can be named by symbols,
which are easy to type.
- When debugging either the PEOPLE or FLOWER package, you don't worry
about symbols and just type short names.
- In OTHER contexts, when you want to mix people and flowers in the
same list, it's easy to do without perturbing already chosen symbolic
data structures and without yielding confusion.
> > The short answer is that non-symbols are fine, but they do not a symbolic
> > processing language make. Some days I don't mind passing around Scheme's
> > symbols (with their characteristic "no associated meaning") + an environment
> > (to give the symbols meaning). Other days, I like the power of being able
> > to have symbols like in CL, where the symbol means something all by itself.
> > (Most days, in fact.) Passing non-symbols is fine computation, but is not
> > the essence of symbolic computation.
>
> Suppose CL had no symbols. It seems I could easily add them by defining
> two classes: "symbol" with slots name, value, plist, etc. and "package"
> that's really just a hash table that maps strings onto instances of the
> symbol class. Probably 20-30 LOC at most. Would that be sufficient?
No. The critical value is the ability to TYPE the symbol without
doublequotes or other impediment in most cases. Yes, you have to write :
but only in the case where an ambiguity is possible to resolve that
ambiguity. In Scheme, you also don't write : in the unambiguous cases but
you have no notation to fall back on to resolve the ambiguous cases.
You could create a notation wherein for Scheme doing TV:FOO would refer to
(GET-FROM-ENVIRONMENT 'FOO TV). And I vaguely recall in T (Yale Scheme)
we had talked about this notation: #>foo>bar>baz to mean
(GET-FROM-ENVIRONMENT 'BAZ
(GET-FROM-ENVIRONMENT 'BAR
(GET-FROM-ENVIRONMENT 'FOO
(GET-FROM-ENVIRONMENT ROOT-ENVIRONMENT))))
though I don't recall the name of the operator for GET-FROM-ENVIRONMENT.
It probably had "LOCALE" in its name. Anyway, though, the point is that
what this syntax would resolve to is not a symbol, nor is the data that it
would retrieve. This is a computationally ok answer, but it is a refutation
of any claim that the language is using "symbol" processing at that point.
Symbols are used incidentally in here (since they are one of the arguments
to some of the functions involved, but saying that means it's symbol processing
is like saying that numerical processing is what's going on in:
(defun find-longest-name (array-of-symbols)
(let ((longest (aref array-of-symbols 0))) ;!!! assumes at least one elt
(loop for i from 1 below (length array-of-symbols)
for contender = (aref array-of-symbols i)
when (> (length (string longest))
(length (string contender)))
do (setf longest contender))
longest))
Yes, numbers are involved, but that's not the essence of
"numerical processing". I think of numerical processing as something where
the core data are encoded as numbers. I think of symbolic processing as
something where the core data are encoded as symbols.
> Or
> would I still be missing some essential capability? What would it be?
You'd have a symbol datatype but not a serviceable one for me.
Even ignoring lack of packages, this is the reason I can't stand Java
symbols--the syntax is too cumbersome.
FOO is a symbol. foo is a symbol. I don't mind typing 15\r or |15r|
to preserve case. I don't mind typing tv:foo if I'm not in package TV
to get to that symbol. But basically I want unimpeded access to the name
as part of my syntax for literals if it's going to be what I think of as
a symbol. I don't mind quoting symbols. In Macsyma, I could do
X:10;
F(X,Y):=X+Y;
F(X+3,'X+3);
and get back X+16 which contains one symbol and one number. It doesn't
matter to me what the surrounding syntax is when talking about whether it's
symbol processing. I consider infix/prefix to be orthogonal, and lousy
though I find dylan syntax to be I can't see why they couldn't have
made the above kind of syntax work for them.
> Maybe the problem is that I don't really understand what people mean by
> "symbolic processing". A concrete non-contrived example of "symbolic
> processing" that's easy in CL and hard in Scheme would probably help.
The above programs are contrived, but I hope show enough meat that you
can see the problem. Try casting them into Scheme in whatever way suits you
and we can proceed to the next conversational step from there.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> I'm not questioning your credentials.
I didn't think you were.
> I thought you had asked effectively
> for mine since your question seemed to ask "is it just the case that the
> other side is speaking out of ignorance".
No, that wasn't my intent. What did I say that gave you that impression?
> No quibble with your credentials here. I'm not suggesting you are not
> entitled to engage in this conversation in any way. I'm just suggesting
> you're wrong in point of fact if you think there is no valid defense of a
> package system. Packages and modules are orthogonal structures and both
> have a place. I'm not anti-module, I'm anti-module-qua-panacea.
I never said nor meant to imply that there "is no valid defense of a
package system." (I called it a "necessary evil", which is not a glowing
review, but not a condemnation either.) But the only reason I asked the
question that began this thread is that people I respect have a differing
view, and I want to understand why.
> > I feel fairly confident that I'm sufficiently non-idiotic that if
> > someone can't explain something in this area so that I can
> > understand it there's a good chance that it's their fault and not
> > mine.
>
> I use this same rule of thumb myself, so I can relate. Then again, I
> think you should not conclude from someone's inability to articulate a
> natural langauge rule to explain a philosophically complex behavior
> that they do not have deep-seated and real beliefs, nor even perhaps
> well-founded beliefs.
I have drawn no such conclusions. If I had I would no longer be
participating in this discussion. (If you want to see how I participate
in an arena where I *have* drawn such conclusions go look up my postings
on comp.lang.perl.)
> I have neither any doubt that
> my belief in packages is technically, not just emotionally or
> historically, well-founded.
Yes, I believe you, and that's what I want to understand.
> I'm happy to engage in this discussion with you on that basis.
Good! That's the basis on which I want to hold the discussion.
> I'm even happy for you to conclude "Because
> Kent and others cannot say what I need to hear, I will continue to
> believe what I believe."
My position is: because Kent and others have not explained it to my
satisfaction (yet) am going to tentatively continue to believe what I
believe, but fully open to the possibility that I might be wrong. (It is
my hope that anyone engaging me in conversation is also open to the
possibility that they might be wrong, but that's not a prerequisite. What
I *do* insist on is that people not try to ascribe my lack of
understanding to some character flaw, like a refusal to listen or being an
idiot. That point of view I reject a priori. You certainly haven't done
that, Kent, but you are not my only correspondent.)
> (That is, I'm happy to live with the belief
> that you are wrong. Heh... Which incidentally is on a statement that
> you are wrong, it is just a statement about my belief structure.) I'm
> not happy for you to assert (and I hope you are not asserting, I'm
> just checking) that "The inability of various people to articulate a
> defense is a de facto proof that no such defense exists." or that kind
> of thing.
No. I just want the person on the other end of this conversation to
accept part of the responsibility for successful communication. I am
weary of Erik and Rahul who just rail at me for being an idiot when I
don't get it. Maybe I am an idiot, but being repeatedly told so just
doesn't help.
[Technical discussion begins here.]
[Much snippage]
> No. The critical value is the ability to TYPE the symbol without
> doublequotes or other impediment in most cases.
I presume you mean "type" as in the action of pushing keys on a keyboard,
not "type" as in data type.
This sounds like you're saying that being able to type:
'FOO
is significantly better (on *technical* grounds) than having to type:
(setf foo (make-symbol-object :name "foo"))
and then typing "foo" rather than "'foo" from then on.
Is that right?
[T alternative syntax description snipped]
> This is a computationally ok answer, but it is a refutation
> of any claim that the language is using "symbol" processing at that point.
OK, this tells me what symbol processing *is*, but I still don't
understand your reason for believing that symbol processing on this
definition is a Good Thing (tm). In fact, you seem to implicitly be
making the counter argument here. If the T way is "computationally OK" as
you say, what are the technical grounds for preferring symbol processing?
The amount of typing involved can be the same either way with appropriate
reader macros.
Have you read Drew McDermott's paper "Artificial Intelligence Meets
Natural Stupidity"? There he argues that AI gets itself into trouble by
attaching too much implicit meaning to the print names of symbols. This
is (I just realized) implicitly a general argument against what you seem
to be calling "symbol processing". Do you agree with that assessment? If
so, do you disagree with McDermott's argument? (BTW, McDermott is not the
mentor I alluded to in the posting that started this thread, though as my
thesis advisor's thesis advisor he has of course had a significant
influence on my own intellectual development.)
> FOO is a symbol. foo is a symbol. I don't mind typing 15\r or |15r|
> to preserve case. I don't mind typing tv:foo if I'm not in package TV
> to get to that symbol. But basically I want unimpeded access to the name
> as part of my syntax for literals if it's going to be what I think of as
> a symbol.
Why is it not enough to bind the symbol to a variable (or a global
constant) and refer to the symbol by the name of the variable?
> I don't mind quoting symbols. In Macsyma, I could do
> X:10;
> F(X,Y):=X+Y;
> F(X+3,'X+3);
> and get back X+16 which contains one symbol and one number.
Ah! This is an enlightening example. The crucial point here, it seems to
me, is that you can refer to the symbol whose name is the string "X" by
typing "'X", and you can refer to the value of that symbol by typing
simply "X". Is that right?
So consider the following alternative design. Define a reader macro, say,
=X, that expanded to (symbol-value X). (Note that there is no quote in
front of the X.) Now we write:
(defconstant x (make-instance 'symbol-class :name "X" :value 10))
(f x =x) ; == (f 'x x)
Is that "just as good"? If not, why?
E.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@192.168.1.50...
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> I never said nor meant to imply that there "is no valid defense of a
> package system." (I called it a "necessary evil", which is not a glowing
> review, but not a condemnation either.) But the only reason I asked the
> question that began this thread is that people I respect have a differing
> view, and I want to understand why.
Erann,
When it comes to programming languages I try to not attach words like evil
to them. As people have pointed out the package system in many ways is
necessary. When it was decided to have one the people who put the work into
developing it (I am 99% sure) went through the thought processes,
discussions and value judgments that this thread is discussing. The package
system is what they developed.
I can think of three quick approaches to learning about packages is by:
1) Using it, getting familiar with it, trying it out (in real situations),
is one way to get a feel for what the designers had in mind.
2) Trying to develop a package system yourself. With this approach you get
immediate insights into the ideas and problems behind it.
3) Teaching the subject. This forces you into actually learning the
material so you do not fall apart when the first challenging question comes
around.
Most of the time if I have sat down and seriously applied these methods to a
real world product it becomes evident that the designers have thought about
it. It dawns on me that they actually know what they are doing.
Imagine if you have put your sweat and thinking into was brought up for
comment on a newsgroup, not just once but year after year after year. How
would you feel? This is the kind of pressure that is put on the people who
put CL together. I am sure they would appreciate intelligent questions on
their ideas, or even better, someone to build and improve on them.
It is more respectful to strive to comprehend by the above 3 methods (and
then asking questions) than asking critical questions based on just
curiousity.
Wade
In article <············@news3.cadvision.com>, "Wade Humeniuk"
<········@cadvision.com> wrote:
> When it comes to programming languages I try to not attach words like evil
> to them.
So do I. "Necessary evil" is an idiomatic expression in English. In
common usage it doesn't have the same kind of pejorative connotation as
the word "evil" used in isolation. It means something more like
"compromise that no one is really very happy with but which is the most
expedient route to a common goal."
> I can think of three quick approaches to learning about packages is by:
>
> 1) Using it, getting familiar with it, trying it out (in real situations),
> is one way to get a feel for what the designers had in mind.
I've been using it for over fifteen years. How long does it take? I've
used it on software that controlled a $200,000,000 spacecraft. How real
does it have to be?
> 2) Trying to develop a package system yourself. With this approach you get
> immediate insights into the ideas and problems behind it.
I don't see the benefit in this. I'm not questioning the design of the
package system. I'm questioning the nature of its utility.
> 3) Teaching the subject. This forces you into actually learning the
> material so you do not fall apart when the first challenging question comes
> around.
Done that too. I've even been paid for it.
> It is more respectful to strive to comprehend by the above 3 methods (and
> then asking questions) than asking critical questions based on just
> curiousity.
I agree. I also think it's pretty disrespectful to assume that I have
done anything other than that.
E.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@eglaptop.jpl.nasa.gov...
> In article <············@news3.cadvision.com>, "Wade Humeniuk"
> <········@cadvision.com> wrote:
> > 2) Trying to develop a package system yourself. With this approach you
get
> > immediate insights into the ideas and problems behind it.
>
> I don't see the benefit in this. I'm not questioning the design of the
> package system. I'm questioning the nature of its utility.
I do not understand this statement. The package system has a well defined
interface (protocol). Its behavior is predictable. It does what it is
designed to do. Does it not do something that you need done? I have not
needed more than the package system provides. What more utility does one
need? To make a concrete programming language limitations have to be
accepted. Just as one can design arbitrarily complex physical objects, the
actual physical objects than can be produced is limited by machining
capabilities. So it is with programming languages.
What needs do you have for packages and symbols that is not being net? I do
not have any additional needs so there is no driving force for me to do
anything. What is driving you?
From your original post I saw:
>> foo
>ERROR: foo is unbound ; Doh! Forgot that foo is in foo-package
>> (use-package 'foo-package)
>ERROR: symbol FOO-PACKAGE:FOO conflicts with symbol FOO ; Arrggh!!!
Usually when I make this mistake I back out completely using delete-package
and reinitialize. I just try to be careful and take my time or load
everything in my initialization file so everything is set up before I start.
(LispWorks prompts you to resolve the problem anyways if you mistakenly do
it). I have the comaparable problem if I do not insert the fuel nozzle into
the gas tank before I pull the handle, I just have to or bad consequences
result.
Wade
···@jpl.nasa.gov (Erann Gat) writes:
> > No. The critical value is the ability to TYPE the symbol without
> > doublequotes or other impediment in most cases.
>
> I presume you mean "type" as in the action of pushing keys on a keyboard,
> not "type" as in data type.
Yes.
> This sounds like you're saying that being able to type:
>
> 'FOO
>
> is significantly better (on *technical* grounds) than having to type:
>
> (setf foo (make-symbol-object :name "foo"))
Yes.
Though actually you meant to say
(or (find-symbol-object-named "foo")
(make-symbol-object :name "foo")))
or perhaps just
(intern "foo")
since that's what INTERN does. As to whether a SETQ is done or not,
that's a context thing in code; because of INTERN, the SETQ is sometimes
not needed.
> and then typing "foo" rather than "'foo" from then on.
> Is that right?
Yep.
> [T alternative syntax description snipped]
>
> > This is a computationally ok answer, but it is a refutation
> > of any claim that the language is using "symbol" processing at that point.
>
> OK, this tells me what symbol processing *is*, but I still don't
> understand your reason for believing that symbol processing on this
> definition is a Good Thing (tm).
Because although designed before there was an issue over this, its importance
came to be understood later as a counter-theory to what we came to know
as "procedurally embedded data". The more information one can put into
data, the less is in the code. That in turn leads (not all at once but in
many tiny design steps) to the notion of the program that is reprogrammable
without recompilation. Every time you pull a decision back into the code,
you must recompile the code in order to change that decision. I'm not saying
that every datum in a program should be symbolic, but I am saying that in the
cases where people make that information symbolic, there is substantial
opportunity to revise the program behavior by merely pushing symbols around.
> In fact, you seem to implicitly be
> making the counter argument here. If the T way is "computationally OK" as
> you say, what are the technical grounds for preferring symbol processing?
There were a lot of programs in the mid-1980's at the advent of AI
Winter where the assertion was made "this program can be translated to
C++ therefore C++ is better". But there was never any proof that
those programs could have arisen in C++. It's _often_ the case that
once you have gone through design and reached stability, you are going
to have a good chance that knowledge can be procedurally embedded for
better effect. I think this is what newell and simon meant by
practice effects. I think if you look even at massively reflective
systems like 3lisp, you'll see that the reflectivity is not used most
of the time and that in those cases 3lisp will compile down to the
same kind of code as other languages will, or at least, I understand
that to be the thesis. But the ability to compile 3lisp out of a
deployed program is not a proof that 3lisp has no place. The ability
to play tennis better after the mechanics are optimized into something
rigid and non-symbolic is not proof that tennis is better learned
mechanically than abstractly. Symbol processing is a tool for
abstract manipulation and it's hardly surprising on a case by case
basis that you can work the symbolic processing out in the end. What
would be surprising is if you could show that FORTRAN or C could just
as well have been a straightforward implementation strategy for AI
systems.
> The amount of typing involved can be the same either way with appropriate
> reader macros.
Not unless you make A, B, C etc be reader macros, IMO. But even then,
the point is that you will only make an isomorphism to symbols at that point.
Show me a worked example and I'll be clearer.
> Have you read Drew McDermott's paper "Artificial Intelligence Meets
> Natural Stupidity"? There he argues that AI gets itself into trouble by
> attaching too much implicit meaning to the print names of symbols. This
> is (I just realized) implicitly a general argument against what you seem
> to be calling "symbol processing". Do you agree with that assessment?
If I've read it, I don't recall. But I am not arguing for what symbolic
processing is useful for, except as an auxiliary issue when you ask if
one could do without it. I don't see that as what this main debate is
about. I am arguing for what it _is_, and I can't imagine that Drew can
make his arguments without first acknowledging a framework such as what
I'm saying. I'm sure there are people who don't like symbol processing,
but that's different than saying those people should be in charge of what
symbol processing is. That's like putting C people in charge of Lisp design.
Design and control of terminology and tools should be done by advocates,
not opponents. It's too easy to sabotage a facility you don't beleive in.
The question is whether an advocate can do something fun with it.
> If so, do you disagree with McDermott's argument?
I have no info. Is it webbed? If not, maybe he'll volunteer to either
web it or physmail me a copy.
> (BTW, McDermott is not the
> mentor I alluded to in the posting that started this thread, though as my
> thesis advisor's thesis advisor he has of course had a significant
> influence on my own intellectual development.)
Drew was at Yale when I was there designing T. He's a smart guy with some
interesting perspectives on things, which is why I'd be interested in the
paper, whether it disagrees with me or not.
Incidentally, nothing I've said suggests that a reliance on symbol names
is a good thing. So I might not disagree with him. I keep saying "identity".
As it happens, symbols have a name, and that's important to obtaining the
identity. But that's all bootstrap and coding. What the program operates
on at runtime is not the name, but the pointer id. The significance of the
name is not that it has _that_ name, but that it has _a_ name; that is,
that it _can be named_. This is a different issue entirely than the question
of whether (concatenate 'string 'foo- x) is going to work; that is a use of
a symbol as a designator for a string, and I personally tend to use
(concatenate 'string "FOO-" x). I don't see that as symbol processing since
a symbol was never used for its identity here, only its name. If you
substitute (concatenate 'string 'tv:foo- x) you get the same answer.
But if I do (get 'tv:foo- 'author) or (get 'foo- 'author), it matters what
package the various key symbols are, not by their name but by their identity,
and the effect is not changed if I later do [which isn't allowed in CL, but
you get the idea]: (setf (symbol-name 'tv:foo-) "BAR-"). The symbol that
was previously TV:FOO- and is now TV:BAR- will still be the same identical
symbol and all prior operations on it will be the same; it may just be harder
to find, in exactly the same way that (3 4) will be harder to find in an
EQUAL hash-table if you SETF its CAR to 5.
> > FOO is a symbol. foo is a symbol. I don't mind typing 15\r or |15r|
> > to preserve case. I don't mind typing tv:foo if I'm not in package TV
> > to get to that symbol. But basically I want unimpeded access to the name
> > as part of my syntax for literals if it's going to be what I think of as
> > a symbol.
>
> Why is it not enough to bind the symbol to a variable (or a global
> constant) and refer to the symbol by the name of the variable?
Because there is no operational way to tell there is a symbol there.
And that's not what symbol processing is about. If I could find that
symbol independently and use its identity as a key to other operations,
then the symbol is a symbolic name for some other data.
> > I don't mind quoting symbols. In Macsyma, I could do
> > X:10;
> > F(X,Y):=X+Y;
> > F(X+3,'X+3);
> > and get back X+16 which contains one symbol and one number.
>
> Ah! This is an enlightening example. The crucial point here, it seems to
> me, is that you can refer to the symbol whose name is the string "X" by
> typing "'X", and you can refer to the value of that symbol by typing
> simply "X". Is that right?
It is the notion of interning. And the notion that this name-reference
accesses an object that will be compared by identity, not by string, even
though the access to get it in the first place was by name. In DB terms,
it is the object, not the name, that is the foreign key to the database
reference backing up SYMBOL-VALUE if you store your values in a database.
> So consider the following alternative design. Define a reader macro, say,
> =X, that expanded to (symbol-value X). (Note that there is no quote in
> front of the X.) Now we write:
>
> (defconstant x (make-instance 'symbol-class :name "X" :value 10))
In this case, all you've done is haired up the syntax of symbolness needlessly.
That doesn't make it a non-symbol. But it does make your language "designed
badly" if you want it to be a symbolic processing language.
You've left out the interning issue, which is central. I'll continue as
if you had not.
> (f x =x) ; == (f 'x x)
>
> Is that "just as good"? If not, why?
MDL (the language in which Zork was programmed) does this, I think.
I'd have to study it further to see if I think it a Lisp but I'm not
informed enough.
But certainly a problem with this syntax is that you need (f x =x) to
be quoted data because otherwise you have no way to denote the list
containing F, X, and =X. If (f (f x =x) x =x) means not to evaluate
the first arg, then why does the outer form get evaluated? And if the
inner form _is_ evaluated, then you'll need a quoter to inhibit it. As
in (f '(f x =x) x =x). But that means 'x and x are the same thing.
And that means that '=x has to be explained. Or else you have to have
=(f (f x =x) x =x) which is really kind of bizarre if you have to always
be forcing evaluation. My intuition from afar was that MDL addressed this
by the <> vs () distinction. Doing
<LET ((X <+ .Y 3>)) <+ .X 4>)
or some such thing. [I vaguely recall some things that tell me I'm goofing
this up, but it's close enough for you to see what I'm getting at.]
CL has this thought through. I'm sure MDL did, too. But I don't
think you can just change this one aspect of the language and make it
work. Languages are ecologies and you must often redo the entire
ecosystem when you replace one major item in the main food chain with
another.
But whether you can do this or not doesn't really get at the heart of the
problem which is, "what looks good". Ultimately, I want to support both
of these things:
[1] (ELIZA '(I AM SAD))
=> (WHY DO YOU SAY I AM SAD)
In this case, I want symbols to look syntactically as simple as
possible so that I can talk to people who don't understand Lisp
and just say "ignore the parens". It is _MUCH_ harder to talk to
a non-programmer and say
=(ELIZA (LIST =I =AM =SAD))
=> (#S(SYMBOL NAME "WHY") #S(SYMBOL NAME "DO") #S(SYMBOL NAME "YOU") ...)
is something to tolerate. It might work implementationally but I don't
find it evocative. It also doesn't let me see quickly that
#S(SYMBOL NAME "FOO") might _not_ be EQ to another #S(SYMBOL NAME "FOO")
produced by GENSYM. At least in CL, you can do #1=#:FOO in the printer
to clarify both EQ relations among gensyms but _non_ EQ relations among
gensyms and interned symbols.
[2] Complex inter-relationships between things constructed in the simplistic
mode illustrated in [1] but where I need to compose symbols from various
packages with conflicting meanings into data structures whose form is
pre-specified. The simplest example is a Lisp program itself, being:
(hardcopy:print (with-output-to-string (str) (cl:print x str)))
Here, there are two meanings of PRINT, one that works on paper and one
on virtual streams, but no confusion results. I can't simply say
((hardcopy print) (with-output-to-string (str) ((cl print) x str)))
because the syntax is pre-defined and that's not valid syntax, and
because that's not my goal syntax because of my desires in [1].
Kent M Pitman <······@world.std.com> writes:
> The significance of the name is not that it has _that_ name, but
> that it has _a_ name; that is, that it _can be named_.
"His name is Robert Paulsen."
You know, in a way, that's very relevant to this discussion. :)
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > > No. The critical value is the ability to TYPE the symbol without
> > > doublequotes or other impediment in most cases.
> >
> > I presume you mean "type" as in the action of pushing keys on a keyboard,
> > not "type" as in data type.
>
> Yes.
>
> > This sounds like you're saying that being able to type:
> >
> > 'FOO
> >
> > is significantly better (on *technical* grounds) than having to type:
> >
> > (setf foo (make-symbol-object :name "foo"))
>
> Yes.
>
> Though actually you meant to say
> (or (find-symbol-object-named "foo")
> (make-symbol-object :name "foo")))
> or perhaps just
> (intern "foo")
> since that's what INTERN does. As to whether a SETQ is done or not,
> that's a context thing in code; because of INTERN, the SETQ is sometimes
> not needed.
Actually, I meant what I wrote. I used "make-symbol-object" deliberately
because I wanted to set the variable foo to an object that had the same
properties (meant colloquially, not in the sense of plists) as a symbol
but not actually *be* a symbol.
> Because although designed before there was an issue over this, its importance
> came to be understood later as a counter-theory to what we came to know
> as "procedurally embedded data". The more information one can put into
> data, the less is in the code. That in turn leads (not all at once but in
> many tiny design steps) to the notion of the program that is reprogrammable
> without recompilation. Every time you pull a decision back into the code,
> you must recompile the code in order to change that decision. I'm not saying
> that every datum in a program should be symbolic, but I am saying that in the
> cases where people make that information symbolic, there is substantial
> opportunity to revise the program behavior by merely pushing symbols around.
Ah!
One of the great things about CL (or at least MCL, which is the CL
environment I've used since the mid-80's) is that recompiling small parts
of the code has essentially zero cost. (I believe this is true of CL in
general, but I don't have enough experience in other environments to be
sure.) Because of this, perhaps, I do not perceive having to recompile
some code when I change a design decision as a problem. (And I make a
*lot* of design changes while coding. In fact, one of the sources of
friction I have with some of my colleagues is that I think that design and
coding ought to be much more finely interleaved than they do.)
> Show me a worked example and I'll be clearer.
Could you suggest a target problem for me to work?
> > Have you read Drew McDermott's paper "Artificial Intelligence Meets
> > Natural Stupidity"?
...
> I have no info. Is it webbed?
Alas no, but here's the citation: Drew McDermott. Artificial intelligence
meets natural stupidity. In: Haugeland mind-design, pages 143-160.
Originally in SIGART Newsletter No 57, 1976.
It's a good read even today.
> I keep saying "identity".
Yes, I've noticed that. I can't quite figure out what you mean by that
because all Lisp object have identity, not just symbols.
Hm. Must sleep on it.
E.
···@jpl.nasa.gov (Erann Gat) writes:
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > (setf foo (make-symbol-object :name "foo"))
> >
> > Yes.
> >
> > Though actually you meant to say
> > (or (find-symbol-object-named "foo")
> > (make-symbol-object :name "foo")))
> > or perhaps just
> > (intern "foo")
> > since that's what INTERN does. As to whether a SETQ is done or not,
> > that's a context thing in code; because of INTERN, the SETQ is sometimes
> > not needed.
>
> Actually, I meant what I wrote. I used "make-symbol-object" deliberately
> because I wanted to set the variable foo to an object that had the same
> properties (meant colloquially, not in the sense of plists) as a symbol
> but not actually *be* a symbol.
I don't mean literally INTERN in the above, btw. I meant
intern-symbol-object-named. Still, just one function call consolidating
the FIND-OR-MAKE idiom.
But interning somehow is the CRITICAL part. Otherwise, (LIST 'A 'A)
becomes (LIST '#:A '#:A) which is a very different thing because it
contains no duplicates and hence no info shared between list elements.
> One of the great things about CL (or at least MCL, which is the CL
> environment I've used since the mid-80's) is that recompiling small parts
> of the code has essentially zero cost. (I believe this is true of CL in
> general, but I don't have enough experience in other environments to be
> sure.) Because of this, perhaps, I do not perceive having to recompile
> some code when I change a design decision as a problem.
Then you have never tried to deliver code under certain vendors' licenses
that forbid the presence of the compiler without large additional cost.
But, moreover, for building embedded rule-driven languages, there is simply
no need to manipulate compiled code.
And anyway, no matter how easy it is, no one but the program maintainers has
any business manipulating the code in my package. But I may publish data
descriptions they can manipulate.
Also symbols externalize even if functions don't.
(And if functions externalize, it's only because secretly they use names
of symbols internally, because otherwise if you tug on certain functions,
all of creation goes out to a file...)
> (And I make a
> *lot* of design changes while coding. In fact, one of the sources of
> friction I have with some of my colleagues is that I think that design and
> coding ought to be much more finely interleaved than they do.)
>
> > Show me a worked example and I'll be clearer.
>
> Could you suggest a target problem for me to work?
>
> > > Have you read Drew McDermott's paper "Artificial Intelligence Meets
> > > Natural Stupidity"?
> ...
> > I have no info. Is it webbed?
>
> Alas no, but here's the citation: Drew McDermott. Artificial intelligence
> meets natural stupidity. In: Haugeland mind-design, pages 143-160.
> Originally in SIGART Newsletter No 57, 1976.
>
> It's a good read even today.
>
> > I keep saying "identity".
>
> Yes, I've noticed that. I can't quite figure out what you mean by that
> because all Lisp object have identity, not just symbols.
But only symbols have a name registry that interns them.
Actually, in Zetalisp, pathnames also get interned.
Identity is still of value with each object distinct, but symbosl are
about naming and there's less point really to name something you won't
be using again.
Kent M Pitman <······@world.std.com> writes:
> Then you have never tried to deliver code under certain vendors' licenses
> that forbid the presence of the compiler without large additional cost.
That's an argument for free software, not an argument for packages.
·········@becket.net (Thomas Bushnell, BSG) writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Then you have never tried to deliver code under certain vendors' licenses
> > that forbid the presence of the compiler without large additional cost.
>
> That's an argument for free software, not an argument for packages.
And free software is an argument for certain people, me in particular,
to find another profession. In which case you wouldn't be having any
of this conversation with me, at least. That would simplify things too.
So while I'm here, since I exist only in worlds where software for fee is
a given, let's hypothesize this as a given. If you want to start a thread
on why we don't need both software for pay and also Kent, that's fine.
But let's not make the same reasoning errors that a perceptron would by
assuming you can mix and match the parts of the world you want and have no
logical interconnections between the changes for the sake of consistency.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> Then you have never tried to deliver code under certain vendors' licenses
> that forbid the presence of the compiler without large additional cost.
Hm, that's true.
> But, moreover, for building embedded rule-driven languages, there is simply
> no need to manipulate compiled code.
OK...
> Also symbols externalize even if functions don't.
OK...
> But only symbols have a name registry that interns them.
No, that's not true. Adopting your terminology, keywords also have such a
registry.
I think we're whittling away at my confusion, but this core remains: why
do you need common-lisp::symbols rather than scheme::keywords to obtain
the benefits of symbolic processing? It isn't "identity identity
identity" as you put it because both symbols and keywords get interned.
Put this another way: why is it important that a symbol's bindings be part
of the symbol object rather than being stored in a separate environment
object?
E.
···@jpl.nasa.gov (Erann Gat) writes:
> I think we're whittling away at my confusion, but this core remains: why
> do you need common-lisp::symbols rather than scheme::keywords to obtain
> the benefits of symbolic processing? It isn't "identity identity
> identity" as you put it because both symbols and keywords get interned.
The ability to have mulitple applications manipulate the same symbolic
data. Namespaces never matter if you statically analyze all the names
used in an application and make sure that they are always
different. The moment you have multiple (sub)systems, you want
multiple namespaces so that changes in one don't break another.
> Put this another way: why is it important that a symbol's bindings be part
> of the symbol object rather than being stored in a separate environment
> object?
Kent has repeatedly said that it's not. (However, if you want
uninterned symbols and these features and GC of uninterned symbols,
you need to use weak hashtables for this purpose.)
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > Then you have never tried to deliver code under certain vendors' licenses
> > that forbid the presence of the compiler without large additional cost.
>
> Hm, that's true.
>
> > But, moreover, for building embedded rule-driven languages, there is simply
> > no need to manipulate compiled code.
>
> OK...
>
> > Also symbols externalize even if functions don't.
>
> OK...
>
> > But only symbols have a name registry that interns them.
>
> No, that's not true. Adopting your terminology, keywords also have such a
> registry.
>
> I think we're whittling away at my confusion, but this core remains: why
> do you need common-lisp::symbols rather than scheme::keywords to obtain
> the benefits of symbolic processing? It isn't "identity identity
> identity" as you put it because both symbols and keywords get interned.
Because it matters WHERE you intern them.
INTERN says that the object you are looking for is the same object as some
other. You can't let that "some other" be chosen at random. By providing
no firewall between applications, you are accidentally merging your own object
with objects held by other applications unknown to you if you intern in the
keyword package.
Any prohibition on use of the shared CL package or shared KEYWORD package
is an example of something you should not do if you want to avoid problems
in Scheme. So since I've already said that you should not define functions
in the keyword package (because everyone sharese it) and since the spec
itself tells you not to define functsion in the CL package, that is, these
two rules rightly agree, you can conclude that it is simply unsafe to define
functions in Scheme (absent modules, which oddly, it doesn't have).
Scheme is the only language I know of that is merely allowed to posit the
existence of something they wish they had and then try to use that imaginary
thing as a way of winning arguments about whose language is better...
Bleah.
> Put this another way: why is it important that a symbol's bindings be part
> of the symbol object rather than being stored in a separate environment
> object?
I used to get angry at the game of deltas and epsilons played when they
taught me the Calculus. "For any delta, there exists a smaller epsilon..."
I would always say "No, you pick your epsilon first, THEN I'll pick the
delta." Of course the second guy always loses. The fact is that order matters.
I am not saying that it matters to store information in symbols, I'm saying
that if you store information in symbols, you get an advantage. You can't
run the question in the other direction without removing my advantage.
I've copiously explained this.
Here is an analogy: You would say, "why does it matter to do compile time
processing if you can do runtime processing". Answer: That's not the right
question. The right question is: "If I know something at compile time,
why should I have to delay to runtime in order to offer you the info."
I hope you see the parallel.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> INTERN says that the object you are looking for is the same object as some
> other. You can't let that "some other" be chosen at random. By providing
> no firewall between applications, you are accidentally merging your own object
> with objects held by other applications unknown to you if you intern in the
> keyword package.
Understood, but see below (particularly point #6).
> Scheme is the only language I know of that is merely allowed to posit the
> existence of something they wish they had and then try to use that imaginary
> thing as a way of winning arguments about whose language is better...
> Bleah.
I agree, and that's why I'm asking these questions in c.l.l. and not in c.l.s.
> Here is an analogy: You would say, "why does it matter to do compile time
> processing if you can do runtime processing". Answer: That's not the right
> question. The right question is: "If I know something at compile time,
> why should I have to delay to runtime in order to offer you the info."
>
> I hope you see the parallel.
I think I do, but I don't agree that it's the "wrong question." I think
that what you call the "wrong" question is a perfectly valid question, and
that is has an answer: it "matters to do compile-time processing" because:
1. Your program may run faster.
2. You may be able to catch some errors before the program runs.
It also has the following disadvantages:
3. Your program may take more initial effort to write (either because you
have to put more effort into writing it, or because your debug cycle will
be slower because your compiler is doing more work).
4. Your program, once written, will almost certainly be harder to change.
(Your "right question" also has an answer: if you know something at
compile time you may want to delay until runtime to offer the info because
you may want to change your mind at runtime, at which point the compiler
may no longer be available to you.)
> I am not saying that it matters to store information in symbols, I'm saying
> that if you store information in symbols, you get an advantage.
And I'm asking: what is it? Here's my current understanding of the
answer(s). I'll parenthetically add my reactions to these answers not to
spark debate but just to provide feedback to the people offering the
answers to help frame a response (if they choose to respond).
1. It allows you to support legacy applications like Macsyma (but you
explicitly said that was not the main point)
2. It allows you to determine the symbol bindings at compile time, which
offers performance advantages. (Except that CL doesn't really *allow* you
to do this, it *insists* that you do it. Furthermore, it's not clear that
those same performance advantages could not be gotten in other ways. And
finally, it seems at odds with the Lisp philosophy of allowing decisions
to be postponed to late in the development process.)
3. It allows you to have homographs. (But to me this is not a
self-evident advantage the way that faster code and less develoment effort
are. In fact, to me at the moment the ability to have homographs looks
distinctly like a bug. It's kind of like C people who complain about Lisp
not having pointers. Yes, Lisp doesn't have pointers, but that's because
we don't *want* them. They cause more problems than they solve.
Homographs, it seems to me, cause more problems than they solve. The
amount of time spent quibbling over whether Scheme symbols are "really"
symbols seems to me to be ample evidence of this.)
4. Rahul says that it allows you to "do symbolic processing" (whatever
that means -- he never defines it. This is simply not true on my
understanding of what "symbolic processing" means, so until Rahul offers a
definition I reject this out of hand.)
5. Erik has offered up arguments along the lines of that symbols are all
about "meaning" and that scheme:symbols have none. (This strikes me as
more of an aesthetic argument than a technical one (not that there's
anything wrong with an aesthetic argument, just that I expect to get them
more from Scheme people than CL people). While it is true that
Scheme:symbols have no intrinsic meaning, this is easily remedied by
first-class environments. I recognize that Scheme also doesn't have
first-class environments, but the global premise of this conversation is
that I'm talking to people who prefer packages to FCE's on the assumption
that they are being offered.)
6. You (Kent) devoted several posts to expounding on the benefits of
symbols in offering run-time flexibility in delivered applications that
had the compiler stripped out. (But it seems to me that all you need to
have this kind of flexibility is some means of mapping strings onto
meanings at run time. Mapping strings onto symbols that have intrinsic
meaning is certainly one way to do that. But mapping strings onto symbols
that have no intrinsic meaning, and then mapping those symbols onto
meanings in a separate step -- and separating the different meanings
associated with different applications in that second step -- still seems
like a perfectly valid way of achieving the same end result.)
7. Miscellaneous efficiency arguments. (These all seem strange coming
from a langauge community where efficiency is a priori a secondary
consideration. But it's not at all clear that FCE's need to be less
efficient than packages. Before there was CMUCL there was T, which had
FCE's, and whose compiler (called "Orbit") was written specifically to
show that Lisp could be compiled as efficiently as Fortran. Also, there's
no reason why an environment can't be "frozen" or "sealed", allowing the
compiler to constant-fold its bindings into the program behind the
scenes.)
Hm, maybe #2 and #7 are really the same thing, but I've already spent over
two hours composing this post so I think I'm going to quit here.
That can be the end of the conversation as far as I'm concerned. Like I
said, I'm not interested in starting an argument, just in understanding
the other side's position. I would be interested in hearing from anyone
who thinks I'm still missing something important.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> It also has the following disadvantages:
>
> 3. Your program may take more initial effort to write (either because you
> have to put more effort into writing it, or because your debug cycle will
> be slower because your compiler is doing more work).
"may" as in "may or may not" as in "you have no information one way or the
other". Yes, that kind of "may", as in "doesn't belong under disadvantages".
People who don't understand their tools may take longer to use all kinds of
things. Closures and side-effects are things I've heard said make it take
longer to write. I've also seen people say the simple LOOP concept is hard
to write. And recursion. Though few say both loop and recursion take long
to write unless they like gotos. Then again, there are people who see gotos
as hard to write. I don't have much personal tolerance for claiming any of
these should be filed under "properties of the language". I do think it's an
interesting area to talk about "conceptual bugs people have in learning" and
how to avoid them. Absent a serious attempt to fully enumerate such a list,
the selective enforcement of listing one or two of these becomes a political
issue akin to locking up one or two marijuana smokers for life and letting
others grow up to be respectable citizens.
> 4. Your program, once written, will almost certainly be harder to change.
I believe even less in the phrase "almost certainly" than I do in "may".
At least may connotes mere possibility without an attempt to talk stats.
Stats depend greatly on what community you study.
I find almost no programs hard to change if they are in Lisp and I'm editing
with Emacs. Even badly written ones. The WORST case of difficulty to change
happens if I simply fold all of a package's symbols programmatically into the
Lisp package named SCHEME or into a package that uses no package. That's easy
to do without editing the code. And that, in turn, means this is not hard.
The only case in which it can possibly be hard is when it actually matters to
fold some symbols and not others, and then you're simply talking a program
that is not really possible to write "per se" in Scheme, and so no comparative
difficulty measure can be applied.
- - - -
I may reply further on other parts of this message later after more reading
and thought, but wanted to respond specifically to this set since it was of
a particular kind that seemed worth thinking about in isolation.
In article <····················@eglaptop.jpl.nasa.gov>,
···@jpl.nasa.gov (Erann Gat) wrote:
> 6. You (Kent) devoted several posts to expounding on the benefits of
> symbols in offering run-time flexibility in delivered applications that
> had the compiler stripped out. (But it seems to me that all you need to
> have this kind of flexibility is some means of mapping strings onto
> meanings at run time. Mapping strings onto symbols that have intrinsic
> meaning is certainly one way to do that. But mapping strings onto symbols
> that have no intrinsic meaning, and then mapping those symbols onto
> meanings in a separate step -- and separating the different meanings
> associated with different applications in that second step -- still seems
> like a perfectly valid way of achieving the same end result.)
Just in case you're feeling all alone, this is my take on it too. In
Dylan I pretty frequently use hash tables keyed by symbols. It's fast
and convenient and you can have arbitrarily many such hash tables for
different purposes.
The notation in CL is a bit more convenient -- basically being able to
take advantage of the global state of the "current package". Nothing
that couldn't be fixed with a macro or two in Dylan, though.
Actually, I just thought of something ... in CL can you have *anonymous*
or dynamically-created packages, or does the name of the package have to
be a compile time constant?
-- Bruce
Bruce Hoult wrote:
> Actually, I just thought of something ... in CL can you have *anonymous*
> or dynamically-created packages, or does the name of the package have to
> be a compile time constant?
You can have dynamically created packages, but each package must
have a unique name.
Pau
Bruce Hoult <·····@hoult.org> writes:
> In article <····················@eglaptop.jpl.nasa.gov>,
> ···@jpl.nasa.gov (Erann Gat) wrote:
>
> > 6. You (Kent) devoted several posts to expounding on the benefits of
> > symbols in offering run-time flexibility in delivered applications that
> > had the compiler stripped out. (But it seems to me that all you need to
> > have this kind of flexibility is some means of mapping strings onto
> > meanings at run time. Mapping strings onto symbols that have intrinsic
> > meaning is certainly one way to do that. But mapping strings onto symbols
> > that have no intrinsic meaning, and then mapping those symbols onto
> > meanings in a separate step -- and separating the different meanings
> > associated with different applications in that second step -- still seems
> > like a perfectly valid way of achieving the same end result.)
>
> Just in case you're feeling all alone, this is my take on it too. In
> Dylan I pretty frequently use hash tables keyed by symbols. It's fast
> and convenient and you can have arbitrarily many such hash tables for
> different purposes.
You are not considering the full range of possibilities.
This works if all your symbol data is from application A or all from
application B or if all data at any given moment is known to be from
one or the other of these applications. But not if the data is mix
and match.
I was going to provide an example, but I've provided about 50 such
examples. If you're not getting it, you're not getting it.
> The notation in CL is a bit more convenient -- basically being able to
> take advantage of the global state of the "current package". Nothing
> that couldn't be fixed with a macro or two in Dylan, though.
Only if you're not doing "symbol processing". Symbol processing, where
you're using a symbol's identity as a data key in two separately written
modules and then you're going to mix that data with data from another
module, will not work.
> Actually, I just thought of something ... in CL can you have *anonymous*
No.
> or dynamically-created packages,
Yes.
> or does the name of the package have to be a compile time constant?
No.
But that isn't needed in 99.99% of cases. Why does this matter?
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> > In article <····················@eglaptop.jpl.nasa.gov>,
> > ···@jpl.nasa.gov (Erann Gat) wrote:
> >
> > > 6. You (Kent) devoted several posts to expounding on the benefits of
> > > symbols in offering run-time flexibility in delivered applications that
> > > had the compiler stripped out. (But it seems to me that all you need to
> > > have this kind of flexibility is some means of mapping strings onto
> > > meanings at run time. Mapping strings onto symbols that have intrinsic
> > > meaning is certainly one way to do that. But mapping strings onto symbols
> > > that have no intrinsic meaning, and then mapping those symbols onto
> > > meanings in a separate step -- and separating the different meanings
> > > associated with different applications in that second step -- still seems
> > > like a perfectly valid way of achieving the same end result.)
> >
> > Just in case you're feeling all alone, this is my take on it too. In
> > Dylan I pretty frequently use hash tables keyed by symbols. It's fast
> > and convenient and you can have arbitrarily many such hash tables for
> > different purposes.
>
> You are not considering the full range of possibilities.
Quite possible. But I've considered a lot of possiblities.
> This works if all your symbol data is from application A or all from
> application B or if all data at any given moment is known to be from
> one or the other of these applications. But not if the data is mix
> and match.
I've followed your examples but I don't see any such problem.
> I was going to provide an example, but I've provided about 50 such
> examples. If you're not getting it, you're not getting it.
And I've read and thought about your examples. I'm pretty sure I "get
it". Certainly I know how to write each of your examples conveniently
without CL namespaces. The only thing I don't get is "where's the
beef?".
-- Bruce
* Bruce Hoult <·····@hoult.org>
| I've followed your examples but I don't see any such problem.
Most people do not see problems until they have actually experienced
them. It can take a genius to see a previously non-existing problem.
(And a madman to see problems that remain non-existing.) This alone is
sufficient to tell people who "do not see the problem" that maybe they
should not argue that it does not exist, but instead ask how people first
ran into it. I think this has been much more than adequately explained
by Kent, whose tremendously impressive patience I am not sure whether I
admire or consider a waste of his time, so it simply means that Common
Lisp solves a problem that most people will _never_ be aware of, will
therefore not think about, and therefore needs precisely the kind of
solution that Common Lisp offers intuitively and non-intrusively. So the
more you do not see the problem, but consider it smart to go with the
flow instead of refusing to listen to people who have both experienced
the problem and figured out a solution that you do not have to think
about, the more likely you are not to run into the problem, ever. The
larger the number of people who cannot figure out what problem packages
solves, the more successful the concept and its implementation is.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Bruce Hoult <·····@hoult.org> writes:
...
> > I was going to provide an example, but I've provided about 50 such
> > examples. If you're not getting it, you're not getting it.
>
> And I've read and thought about your examples. I'm pretty sure I "get
> it". Certainly I know how to write each of your examples conveniently
> without CL namespaces.
As symbols? I'm not saying they can't be programmed. I'm saying symbols
don't work as the data keys. If you think they do, the burden is on you
to show examples.
> The only thing I don't get is "where's the beef?".
In the fact that those who claim working solutions are all mysteriously
short of examples.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> In the fact that those who claim working solutions are all mysteriously
> short of examples.
Here are two:
1. Between 1988 and 1991 we used T to program what was at the time a
state-of-the-art autonomous mobile robot. (Development was done in a T
emulation package written in Common Lisp, but the robot itself actually
ran T.) It was a large project involving many programmers working more or
less independently. T has environments, but not packages. I don't recall
any name class problems. It certainly wasn't a major issue.
2. The Python library is an example of an enormous number of people
loosely collaborating to write interacting but non-interfering code.
Python, like T, has environments (Python calls them modules) but not
packages.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
> > In the fact that those who claim working solutions are all mysteriously
> > short of examples.
> Here are two:
> 1. Between 1988 and 1991 we used T to program what was at the time a
> state-of-the-art autonomous mobile robot. [...]
> 2. The Python library [...]
Do either of those use symbols as data? (that is, do they do symbolic
processing?)
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> ...
> > > I was going to provide an example, but I've provided about 50 such
> > > examples. If you're not getting it, you're not getting it.
> >
> > And I've read and thought about your examples. I'm pretty sure I "get
> > it". Certainly I know how to write each of your examples conveniently
> > without CL namespaces.
>
> As symbols? I'm not saying they can't be programmed. I'm saying symbols
> don't work as the data keys. If you think they do, the burden is on you
> to show examples.
Using symbols. Instead of having mutable data such as a plist attached
directly to a symbol such as 'package:symbol, you use a plist acessed as
(Dylan) package[symbol:] or (CL) (gethash 'symbol package).
You can then write a three argument version of "get" which explicitly
lists the "package" and a two argument version which takes the "package"
from the *package* global.
(myget 'rose 'colour)
(myget employees 'rose 'salary)
... instead of ...
(get 'rose 'colour)
(get 'employees:rose 'salary)
This gives you all the functionality and convenience of having plists
atached to symbols, but without the danger of different applications
colliding in their use, because instead each application creates its own
hash table to hold the plists.
In what way is this deficient?
-- Bruce
In article <···························@copper.ipg.tsnz.net>, Bruce Hoult
<·····@hoult.org> wrote:
> In article <···············@shell01.TheWorld.com>,
> Kent M Pitman <······@world.std.com> wrote:
>
> > Bruce Hoult <·····@hoult.org> writes:
> >
> > ...
> > > > I was going to provide an example, but I've provided about 50 such
> > > > examples. If you're not getting it, you're not getting it.
> > >
> > > And I've read and thought about your examples. I'm pretty sure I "get
> > > it". Certainly I know how to write each of your examples conveniently
> > > without CL namespaces.
> >
> > As symbols? I'm not saying they can't be programmed. I'm saying symbols
> > don't work as the data keys. If you think they do, the burden is on you
> > to show examples.
>
> Using symbols. Instead of having mutable data such as a plist attached
> directly to a symbol such as 'package:symbol, you use a plist acessed as
> (Dylan) package[symbol:] or (CL) (gethash 'symbol package).
>
> You can then write a three argument version of "get" which explicitly
> lists the "package" and a two argument version which takes the "package"
> from the *package* global.
>
> (myget 'rose 'colour)
> (myget employees 'rose 'salary)
>
> ... instead of ...
>
> (get 'rose 'colour)
> (get 'employees:rose 'salary)
>
>
> This gives you all the functionality and convenience of having plists
> atached to symbols, but without the danger of different applications
> colliding in their use, because instead each application creates its own
> hash table to hold the plists.
>
> In what way is this deficient?
Because you can't write a function that will return a symbolic value that
you can use as an argument to myget that will distinguish these two
cases. All you can return is 'rose (because that's all there is), whose
semantics you now can't disambiguate.
E.
In article <····················@192.168.1.50>,
···@jpl.nasa.gov (Erann Gat) wrote:
> In article <···························@copper.ipg.tsnz.net>, Bruce Hoult
> <·····@hoult.org> wrote:
>
> > In article <···············@shell01.TheWorld.com>,
> > Kent M Pitman <······@world.std.com> wrote:
> >
> > > Bruce Hoult <·····@hoult.org> writes:
> > >
> > > ...
> > > > > I was going to provide an example, but I've provided about 50 such
> > > > > examples. If you're not getting it, you're not getting it.
> > > >
> > > > And I've read and thought about your examples. I'm pretty sure I "get
> > > > it". Certainly I know how to write each of your examples conveniently
> > > > without CL namespaces.
> > >
> > > As symbols? I'm not saying they can't be programmed. I'm saying symbols
> > > don't work as the data keys. If you think they do, the burden is on you
> > > to show examples.
> >
> > Using symbols. Instead of having mutable data such as a plist attached
> > directly to a symbol such as 'package:symbol, you use a plist acessed as
> > (Dylan) package[symbol:] or (CL) (gethash 'symbol package).
> >
> > You can then write a three argument version of "get" which explicitly
> > lists the "package" and a two argument version which takes the "package"
> > from the *package* global.
> >
> > (myget 'rose 'colour)
> > (myget employees 'rose 'salary)
> >
> > ... instead of ...
> >
> > (get 'rose 'colour)
> > (get 'employees:rose 'salary)
> >
> >
> > This gives you all the functionality and convenience of having plists
> > atached to symbols, but without the danger of different applications
> > colliding in their use, because instead each application creates its own
> > hash table to hold the plists.
> >
> > In what way is this deficient?
>
> Because you can't write a function that will return a symbolic value that
> you can use as an argument to myget that will distinguish these two
> cases. All you can return is 'rose (because that's all there is), whose
> semantics you now can't disambiguate.
The thing I'd pass around would be the result of (gethash 'rose
employees), not just 'rose. If that needs to be a data structure
(perhaps a class instance) with slots referring back to the symbol and
"package" (class) as well as the plist then so be it.
-- Bruce
p.s. I'm off to a gliding competition now so don't expect replies until
after the weekend. This is parked in my driveway...
http://www.hoult.org/~bruce/gliderOnTrailer.jpg
In article <···························@copper.ipg.tsnz.net>, Bruce Hoult
<·····@hoult.org> wrote:
> The thing I'd pass around would be the result of (gethash 'rose
> employees), not just 'rose.
You asked "how is this deficient" and I answered "It's deficient because
you can't do X." This reply is, essentially, "But I wouldn't do X, I'd do
Y instead." That's fine, but it doesn't change the fact that solution is
deficient for someone who wants to do X. This deficiency may not impact
you, but that doesn't mean it's not there.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > In the fact that those who claim working solutions are all mysteriously
> > short of examples.
>
> Here are two:
>
> 1. Between 1988 and 1991 we used T to program what was at the time a
> state-of-the-art autonomous mobile robot. (Development was done in a T
> emulation package written in Common Lisp, but the robot itself actually
> ran T.) It was a large project involving many programmers working more or
> less independently. T has environments, but not packages. I don't recall
> any name class problems. It certainly wasn't a major issue.
>
> 2. The Python library is an example of an enormous number of people
> loosely collaborating to write interacting but non-interfering code.
> Python, like T, has environments (Python calls them modules) but not
> packages.
Sorry, you've done it twice now so I should clarify:
I want code. So I can see the _actual_ uses of symbols.
I have presented code to make my case so you could critique it.
I think it's fair to see some in return.
Bruce Hoult <·····@hoult.org> writes:
> The thing I'd pass around would be the result of (gethash 'rose
> employees), not just 'rose.
Please say either "the result of 'ROSE" or "the symbol ROSE"
but don't say "'ROSE" because this is a list whose car is the symbol
QUOTE and whose cadr is the symbol ROSE. See my remarks recently
on the "function designators" thread for an example of the
conversational troubles that can arise from using this bogus textual
notation in conversation.
And please do _not_ say that no one will have this confusion, because
I personally _always_ assume that someone mean the list (QUOTE ROSE)
when they write 'rose in text. I have to go back and re-parse the
sentence in an error-prone way after I don't understand them on the
first pass of their using this "helpful" notation. In a language
where we constantly speak not only of values but of forms, and where
'foo [by which I mean (QUOTE FOO) not FOO] is a common form, it just
is not appropriate to be sloppy like this
... and it is _especially_ not appropriate to be sloppy like this in
the name of being helpful! That is, some people seem to actively
encourage this bogus notation, and it's _wrong_. It reminds me of
people who when I teach them emacs and I say c-x c-f out loud will
write down c-x f on the yellow sticky pad they stick to their console.
I'll repeat "I said c-x c-f" and they say "Oh, I know, but I only
press the c- part once, and I'll 'remember' that I keep the c- key
held down". How they'll "remember", I have no idea. They have just
never run into the problem of c-x c-f vs c-x f, both of which are
valid key sequences. It's a notational disaster waiting to happen,
and good hygiene says to write stuff down in a notation that really
works.
Hmm. This is not the topic I'd intended to respond on. Guess I'll
log it as a separate thread id so it doesn't get confused.
Kent M Pitman wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> > The thing I'd pass around would be the result of (gethash 'rose
> > employees), not just 'rose.
>
> Please say either "the result of 'ROSE" or "the symbol ROSE"
> but don't say "'ROSE" because this is a list whose car is the symbol
> QUOTE and whose cadr is the symbol ROSE. See my remarks recently
> on the "function designators" thread for an example of the
> conversational troubles that can arise from using this bogus textual
> notation in conversation.
...
> ... and it is _especially_ not appropriate to be sloppy like this in
> the name of being helpful! That is, some people seem to actively
> encourage this bogus notation, and it's _wrong_. [...]
Not fair, I think. The convention "In ordinary text, a
single quote introduces a Lisp form that's under consideration
as a piece of code" is internally consistent and entirely
usable.
Another convention (which I think works better) is: "In
ordinary text, all-caps indicates a Lisp form that's under
consideration as a piece of code".
Combining the two produces results that *do* look to me
as if they have one layer of quoting too many:
... blah blah blah, such as the form '(CAR FOO BAR),
don't make any blah blah blah ...
leaves the reader wondering whether the form being cited
is (CAR FOO BAR) or (QUOTE (CAR FOO BAR)). But I don't
see what's *wrong* (as opposed to *confusing for some
readers*) with using a single-quote to signal the start
of embedded Lisp code.
Kent, what would you have made if Bruce had written this?
... not just rose.
I conjecture you'd have felt that it had one layer of
quoting too *few*. If that's so, then adding one layer
of quoting shouldn't make it have one too many.
It's very reasonable to argue that the convention Bruce
is using is unhelpful, and the fact that your brain has
a different convention wired in is evidence of this. But
I don't see how "sloppy" and "wrong" are appropriate
complaints.
*
On the other hand, "sloppy" and "wrong" are entirely
reasonable complaints to direct at Bruce's sentence
as a whole, since he wrote:
> > The thing I'd pass around would be the result of (gethash 'rose
> > employees), not just 'rose.
and the first embedded form has no explicit quotation
at all, whereas the second has that leading quote. Tut!
If Bruce's reason for not putting a quote before the
first form is that then it would have looked like he
was referring to the result of (QUOTE (GETHASH etc)),
then I take it all back: in this instance, Kent was right. :-)
--
Gareth McCaughan ················@pobox.com
.sig under construc
From: Dorai Sitaram
Subject: Re: Those awful 'foo and #'foo notations for symbols [was Re: Packages]
Date:
Message-ID: <a7i17h$sft$1@news.gte.com>
In article <································@g.local>,
Gareth McCaughan <················@pobox.com> wrote:
>Kent M Pitman wrote:
>
>> Bruce Hoult <·····@hoult.org> writes:
>>
>> > The thing I'd pass around would be the result of (gethash 'rose
>> > employees), not just 'rose.
>>
>> Please say either "the result of 'ROSE" or "the symbol ROSE"
>> but don't say "'ROSE" because this is a list whose car is the symbol
>> QUOTE and whose cadr is the symbol ROSE.
>...
>> ... and it is _especially_ not appropriate to be sloppy like this in
>> the name of being helpful! That is, some people seem to actively
>> encourage this bogus notation, and it's _wrong_. [...]
>
>Not fair, I think. The convention "In ordinary text, a
>single quote introduces a Lisp form that's under consideration
>as a piece of code" is internally consistent and entirely
>usable. ...
>
>On the other hand, "sloppy" and "wrong" are entirely
>reasonable complaints to direct at Bruce's sentence
>as a whole, since he wrote:
>
>> > The thing I'd pass around would be the result of (gethash 'rose
>> > employees), not just 'rose.
>
>and the first embedded form has no explicit quotation
>at all, whereas the second has that leading quote. Tut!
>If Bruce's reason for not putting a quote before the
>first form is that then it would have looked like he
>was referring to the result of (QUOTE (GETHASH etc)),
>then I take it all back: in this instance, Kent was right. :-)
Context makes it abundantly clear what Bruce meant.
Kent has campaigned forcefully for enabling and
tolerating the getting of meaning from context,
so this should be all right. :-)
--d
From: Kent M Pitman
Subject: Re: Those awful 'foo and #'foo notations for symbols [was Re: Packages]
Date:
Message-ID: <sfw4rj7thy3.fsf@shell01.TheWorld.com>
····@goldshoe.gte.com (Dorai Sitaram) writes:
> Context makes it abundantly clear what Bruce meant.
> Kent has campaigned forcefully for enabling and
> tolerating the getting of meaning from context,
> so this should be all right. :-)
Ah, yes, so basically when someone asks a question here of the form
why doesn't X work [indicating they don't understand the context] or
how do I do X [indicating they've never had much experience with the
context], we should give them context-dependent notations in response.
Yeah, good plan. That's exactly what I meant. Thanks for setting me
straight... :-)
In article <································@g.local>,
················@pobox.com (Gareth McCaughan) wrote:
> > > The thing I'd pass around would be the result of (gethash 'rose
> > > employees), not just 'rose.
>
> and the first embedded form has no explicit quotation
> at all, whereas the second has that leading quote. Tut!
> If Bruce's reason for not putting a quote before the
> first form is that then it would have looked like he
> was referring to the result of (QUOTE (GETHASH etc)),
> then I take it all back: in this instance, Kent was right. :-)
I regard (perhaps wrongly) the text "the result of" as being just such a
level of quotation. Equally, aren't we talking about "the result of
(QUOTE ROSE)"?
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> The thing I'd pass around would be the result of (gethash 'rose
> employees), not just 'rose.
[I responded to the notational problems in this statement under separate
cover.]
> If that needs to be a data structure
> (perhaps a class instance) with slots referring back to the symbol and
> "package" (class) as well as the plist then so be it.
I have no problem with using non-symbols. I'm not sure if I did that
I'd bother having a slot pointing to a symbol at that point; probably
I'd point to a string with the name and use the non-symbol's class or
identity as a pointer. I bet you would, too.
But I repeat the comment: saying you'd substitute non-symbols for symbols
is not the heart of symbol processing.
Large AI systems, past and present, often use interned symbols in big webs
where the symbols' information is stored on plists. I think they do this
becuase it saves them writing a ton of readmacros, which you often have to
do if you want to use non-symbol data structures and still have the things
be re-readable as literal data. So in symbol processing style, one does:
(allege 'building-17 'owner 'person-13)
[I chose ALLEGE rather than PUTPROP or SETF of GET to encourage people to see
this has nothing to do with standard system functions and where they store
data.] and later someone can ask:
(query '(who-owns building-17))
=> (ambiguous-response (person-13 probability 0.7)
(corporation-3 probability 0.3))
or maybe it does return just the symbol PERSON-13 or the
symbol CORPORATION-3. [The latter might happen if the alleging was not as
strong as some known truth already in the system.]
The advantage of this over using classes is that it can be saved easily
and reloaded freely because lists and symbols have print representations,
and because symbols have a natural tendency to stop the printer from
revealing circularities that often arise in these systems.
Had one used #<CORPORATION "ACME"> it might have been more "modern" to
some people but it might still have been hard to type in queries
interacively. You'd have to write lookup notations for each of the
things. Maybe you'd make #[CORPORATION 3] and have a multi-component
name registry. Or maybe you'd use #S(CORPORATION ...) though the #S
notation has an identity problem; you'd be able to read them fine but
on typein you'd have to type (FIND-CORPORATION-NAMED ...) or something
because making a new #S item would not get you the one with the
identity already in the system. Maybe you'd do the notation
#!CORPORATION-13 but this would be enough to get your almost-symbol to
'intern' as something other than the symbol CORPORATION-13 and is
really a lot like a pseudo-package-system. I have no problem with
this as a solution, it's just worth noticing that it's not doing what
is traditionally symbol processing, which is a much more low-tech and
simple kind of thing.
Real symbol processing means "using symbols". That style comes with
specific advantages and disadvantages.
We are not a single-paradigm language. We don't use functional programming
throughout. I think we don't use symbol processing throughout. But we
support the concept where we want to do that, and to support that paradigm
without wimping out on every hard problem and using "not symbol processing"
to solve every problem, that's why we have packages.
Kent M Pitman <······@world.std.com> writes:
> Real symbol processing means "using symbols". That style comes with
> specific advantages and disadvantages.
>
> We are not a single-paradigm language. We don't use functional programming
> throughout. I think we don't use symbol processing throughout. But we
> support the concept where we want to do that, and to support that paradigm
> without wimping out on every hard problem and using "not symbol processing"
> to solve every problem, that's why we have packages.
Just to let you know, your patience in expounding on this issue has been
appreciated.
I myself have learned something more about the "Lisp Way".
I summarize the issue like this: sure one can solve the identity-conflict
problems with explicit programming, but with CL's symbol and package system
there already exists a mechanism that is simple to use, available, and just
works.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
From: Kent M Pitman
Subject: Re: Those awful 'foo and #'foo notations for symbols [was Re: Packages]
Date:
Message-ID: <sfwofhdth9n.fsf@shell01.TheWorld.com>
Bruce Hoult <·····@hoult.org> writes:
> In article <································@g.local>,
> ················@pobox.com (Gareth McCaughan) wrote:
>
> > > > The thing I'd pass around would be the result of (gethash 'rose
> > > > employees), not just 'rose.
> >
> > and the first embedded form has no explicit quotation
> > at all, whereas the second has that leading quote. Tut!
> > If Bruce's reason for not putting a quote before the
> > first form is that then it would have looked like he
> > was referring to the result of (QUOTE (GETHASH etc)),
> > then I take it all back: in this instance, Kent was right. :-)
>
> I regard (perhaps wrongly) the text "the result of" as being just such a
> level of quotation.
No. It syntactically quotes the English (and is more analogous to
backslash (\) than to singlequote (') in this regard. But "the value
of <xxx>" or "the result of <xxx>" forces a level of evaluation that
"the expression <xxx>" or "the form <xxx>" or "the symbol <xxx>" does
not have.
I think talking about "the result of (QUOTE FOO)" denotes the same item
as "the symbol FOO", except the former shows something of how you got there.
> Equally, aren't we talking about "the result of (QUOTE ROSE)"?
I don't think so. I think it's a bad idea to say that English does
evaluation by default. I try in the HyperSpec to talk about either
"the value of *STANDARD-OUTPUT*" or about "standard output" [i.e., I made
an english phrase whose meaning is "the value of *STANDARD-OUTPUT*"].
I did a similar thing with "around methods" and other terms like that,
though partly for different reasons--one reasno for the "around methods"
term was to avoid the question of whether to pronounce the ":" in :around.
That is, you have to say "a colon-around method" or "an around method",
depending on how you pronounce :around, so by making it a glossary term
I avoided this inelegance. Even so, had I said
"the argument is *STANDARD-OUTPUT*" I think this would have meant
"the argument is the symbol *STANDARD-OUTPUT*". And hence I think
when you mention 'rose, you are talking about the list (QUOTE ROSE),
not the symbol ROSE.
Erann Gat wrote:
> ...
>
> I think we're whittling away at my confusion, but this core remains: why
> do you need common-lisp::symbols rather than scheme::keywords to obtain
> the benefits of symbolic processing? It isn't "identity identity
> identity" as you put it because both symbols and keywords get interned.
>
perhaps it is important to keep in mind that "identity" has two sides.
interning together with IN-PACKAGE not only equates synonyms, it
distinguishes homographs.
...
james anderson <··············@setf.de> writes:
> Erann Gat wrote:
> > ...
> >
> > I think we're whittling away at my confusion, but this core remains: why
> > do you need common-lisp::symbols rather than scheme::keywords to obtain
> > the benefits of symbolic processing? It isn't "identity identity
> > identity" as you put it because both symbols and keywords get interned.
>
> perhaps it is important to keep in mind that "identity" has two sides.
> interning together with IN-PACKAGE not only equates synonyms, it
> distinguishes homographs.
Right. Exactly.
I'm told there's a curious asymmetry in human perceptual evolution
(here I mean the kind of evolution Piaget studied, within an individual,
not the kind Darwin did, where the "individuals" were societies).
As I understand it, a child first manifests "identity" by learning to
say "no". This would seem asymmetric because, as James notes above,
identity has two edges: "yes" and "no". But because kids have had to
basically go along with things for their entire experience, one might say
they come with a built-in understanding of (or at least tolerance of) the
"yes" mode. They don't have to do anything to get "yes". If they don't
say "no" to "do you want to eat some of this" they're going to get "this"
shoved in their mouth. So "no" completes the picture and gives them the
ability to either "go with the flow" or "not go with the flow".
A similar effect occurs with foreign speakers, who find it a survival
skill to smile quietly, assume most around them are both "more
capable" and "operating in their favor anyway" and so say "yes" a lot
until they feel competent enough to know when to say "no".
In both the case of the child and the foreigner, their ability to have
identity asserts itself because they can differentiate from the pack by
a kind of progressive diagonalization (a la Cantor) that establishes their
reality (sorry, stretching probably too far for a pun) as a separate
individual. But to be a true individual, one must not only be able to
assert differentness, but one must be able to do so judiciously.
One can be an individual without thought. A simple computer program that
says "no" to everything can use Cantor's trick to assure it is "different".
But the object ultimately isn't different--different is just a tool. The
object is to locate your identity correctly in a space in order to be
good or happy or helpful or right by some subjective definition of whatever
is driving the thought process of the thing that is differentiating (or
managing the differentiating from outside).
I think perhaps there's an evolution, too, of the student's understanding
of identity in data where at first they think that either folding identity
or not folding identity is the key thing. But these are like the ability
to be "agreeable" or to be "contrary". Done without thought, neither of
these is very good. Aristotle's analysis of virtue ethics [1] suggests that
the really hard work comes in the ability to construct a mean between
unreasonable extremes. The subtle but important truth here is that,
mathematically, he's suggesting finding the midpoint between infinity
and minus infinity, which is a good philosophical puzzle in itself for those
who reason only in the mathematics of the issue; but the goodness metric
Aristotle is after is not really one that is intended to be mathematically
derived, but pragmatically (or, at least, philosophically, which to my eye
seems the same as pragmatically in this limited context). Any point on the
number line can be argued to have infinite points on either side, so any
point can be argued to be right. The trick is to withstand the criticism
that will inevitably come from driving a stake in the ground at just one such
point and justifying your reasoning. And the virtue probably comes more
in your willingness to defend your position than in some objective sense that
you are universally right. And the harshest criticism is likely to come from
those who have not had the courage to drive their own stake, because they
will not truly appreciate the difficulty of having so done.
In this regard, (MAKE-INSTANCE :name x)
[which always makes things unique] is one extreme, and (INTERN x "KEYWORD")
[which always identity-folds x onto all other x's of the same name] are
the two extremes. The package system represents the uncomfortable problem
of choosing which of myriad packages "points along the spectrum where you
get some sharing, some not" you will justify as suitable for a given purpose.
No single package will be right. But the virtue will come from your ability
to name and choose such options rather than simply falling off the end to
the unreasoanble extremes.
If you don't know Aristotle, and I didn't study him in school--all I
know I learned from the web, I highly recommend a visit to some of the
pages on the matter [the one I've cited below is just one of many].
As with all tools of the philosopher, it's not the only way to look at
the many-faceted world we live in, but it's still a coherent and
instructive way to occasionally think about things.
[1] http://www.utm.edu/research/iep/v/virtue.htm
Kent M Pitman <······@world.std.com> writes:
> (flower:colors-among '(flower:rose people:rose flower:daisy))
> => (FLOWER:RED FLOWER:WHITE)
IIUC, what you're saying is,
You can write simple, self-contained Scheme code to do X. However, when
you start mixing in code from different sources, the things you have to
do in Scheme to avoid name conflicts are not as clean or convenient as
with CL packages.
In this case, X happens to be symbolic processing. Couldn't you say
the same thing for any X? It's interesting that CL packages partition
symbol plists and not just their associated functions/variables, but
we're still talking about the same concept.
> - The information is manifest in symbols, a primitive data structure
> in the language
I'd like an example that stresses this feature of CL apart from the
package system.
Regardless of the discussion among CLers about whether its package
system is the best solution, I think it's a given that CL's package
system is better than nothing, which is what R5RS Scheme has.
> The above programs are contrived, but I hope show enough meat that you
> can see the problem. Try casting them into Scheme in whatever way suits you
> and we can proceed to the next conversational step from there.
I doubt whether Erann is likely to take you up on this, but with a less
package-centric example I would.
--
<·······@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.sourceforge.net/
"alum.mit.edu")]>
Bruce Lewis <·······@yahoo.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > (flower:colors-among '(flower:rose people:rose flower:daisy))
> > => (FLOWER:RED FLOWER:WHITE)
>
> IIUC, what you're saying is,
>
> You can write simple, self-contained Scheme code to do X. However, when
> you start mixing in code from different sources, the things you have to
> do in Scheme to avoid name conflicts are not as clean or convenient as
> with CL packages.
>
> In this case, X happens to be symbolic processing. Couldn't you say
> the same thing for any X?
The identity-level issues are the same but central to the notion of a symbol
is interning, which folds two objects into the same object.
In other situations, as with (MAKE-INSTANCE 'MY-CONTAINER) the default is
not to fold but to separate.
Identity folding should not be done without a strong understanding of
the consequences of confusion. It comes down to a statistical
question of whether it is better in the face of no information to
assume two objects distinct or to assume them the same. I think
there's no way you can argue that people should defaultly assume every
object is the same object. (Though I'll listen while you try to make
such a case.)
So the question is really over names, and the question goes on in the prsence
of an understanding that everyone likes short names. Folding all objects
named JOHN into the same space means every parent in the world has to name
they're kid differently. By separating namespaces, one can stay in the realm
of names but still refer to different objects. That's what packages do.
That's what the Scheme system does not do.
Yes, you can move to non-symbols, but then that's just to say that you can
move to a paradigm which doesn't do as much name-folding by default, which is
to say you're admitting that the name-folding was the problem, which is to
say you're admitting that the CL naming system is less prone to the problem
than the Scheme one, which is kind of losing the argument. Or so it seems
to me.
> It's interesting that CL packages partition
> symbol plists and not just their associated functions/variables, but
> we're still talking about the same concept.
No, we're only talking about identity.
The use of functions, variables, and plists is just felicity because
it means we have some sample operations to try. People seem to be not
understanding that functions and variables are already carefully described
by the language not to be "slots" so that you can store them outboard by
doing [approximately]:
(defun symbol-function (name)
(gethash name *the-functions*))
since many symbols don't have functions and vendors involved in the design
of the standard didn't want to require storage to be consumed by all symbols.
As such, we are talking only of identity, and nothing else. This is not
about symbol structure nor primitive operations. It might as well be
(defun get-favorite-movie (person-name)
(gethash person-name *peoples-favorite-movies*))
There is no structural difference other than that we supposedly had to
define one fewer function to make a coherent example. But since people
have managed to get confused by the choice of an existing function, I guess
we can't use short examples. (And I find that sad.)
Identity. Identity. Identity.
That is the only thing under discussion. Everything else is a derived
consequence of identity or an orthogonal issue.
> > - The information is manifest in symbols, a primitive data structure
> > in the language
>
> I'd like an example that stresses this feature of CL apart from the
> package system.
I've lost too much context because you elided stuff. I'm not going to go
digging, but if you dredge up more context and reask the question I will
try to answer.
> Regardless of the discussion among CLers about whether its package
> system is the best solution, I think it's a given that CL's package
> system is better than nothing, which is what R5RS Scheme has.
A happy outcome for me in this would be an agreement to just refer to
scheme symbols, at least in a language-neutral discussion, as
"keywords" and not really as "symbols". This discussion is starting
to look to me very similar tot he question of whether C has integers.
I think Lisp has the moral right to say it has integers, and I'm happy
calling C's truncated integers ints. And these languages can call
their internal data structures whatever suits their language
community. But when interchagne is needed, I think either you have to
agree that no one may use the name that occurs in more than one place
or you must agree that someone has more moral right to it in an
interdisciplinary conversation than someone else... Of course, we're
not involving the Scheme people in this discussion, so I'm not likely
to get a useful agreement on terminology in this forum. But let's call
it part of the "consensus building" process toward some greater end.
> > The above programs are contrived, but I hope show enough meat that you
> > can see the problem. Try casting them into Scheme in whatever way suits you
> > and we can proceed to the next conversational step from there.
>
> I doubt whether Erann is likely to take you up on this, but with a less
> package-centric example I would.
I couldn't parse this.
Kent M Pitman <······@world.std.com> writes:
> Yes, you can move to non-symbols, but then that's just to say that you can
> move to a paradigm which doesn't do as much name-folding by default, which is
> to say you're admitting that the name-folding was the problem, which is to
> say you're admitting that the CL naming system is less prone to the problem
> than the Scheme one, which is kind of losing the argument. Or so it seems
> to me.
When I think about this, my inclination is to say that for many of
these programming problems, the answer in Scheme is going to be "don't
use the symbol type". Indeed, that means the Scheme symbol type is
less suitable for certain kinds of computations.
But the Scheme advice is going to be to use things like procedures
instead for all these things. Now, you point out that whatever other
things you use might well have uglier print syntax--but this is not
inherently clear to me, but even if true, it doesn't really matter all
that much to me. I don't think it's a huge problem, or much of a
problem at all.
Of course, I'm not saying anything here more than a somewhat vague
sketch. It seems to me that in a language like Scheme one simply does
symbolic programming by using different (more flexible) datatypes than
Scheme symbols. I don't think any serious reduction in expressive
power is going on here, though, but I admit I have no good argument
for that at present other than my general intuitions and experience.
Thomas
·········@becket.net (Thomas Bushnell, BSG) writes:
> ... It seems to me that in a language like Scheme one simply does
> symbolic programming by using different (more flexible) datatypes than
> Scheme symbols. ...
It's fine to do this, but then you are inventing at the user level
things that the compiler won't be able to recognize idiomatically and
help you with using operators and data layouts that are primitively
efficient.
I feel about this the same as I felt in Maclisp when people used to
do copy-tree by (subst nil nil x) or in Teco when people would compute
absolute value by using ···@·@ [don't ask--just take my word for it
that ········@ was not intended to do absolute value]. There is a
difference between implementation and expression, and CL allows me to
express my need, not just implement my need. I don't want to substitute
an alternate implementation when I can say directly my desire and let
CL do the data layout and management.
> I don't think any serious reduction in expressive
> power is going on here,
Yes, it is. The shift from expressive tasks to implementation tasks
is the essence
of the difference between Lisp and other languages for me. Every time you
chip away at it, you chip away at Lisp's power. I said before that this
is not about Turing power, and this remark on yours is an appeal to Turing
power. Expressive power is exactly about concise targeted notation.
Suppose we forget Lisp for a moment and talk only Goedel numbers.
Your argument is the same as saying "you don't need a low-numbered
function, since a higher numbered function will work just as well".
But if you really think this, then you don't understand why foo.com is
more valuable as an intellectual property than
thisnameshouldsellforjustasmuchasfoodotcomdoes.com They may be turing
equivalent (each just a pointer) and you might claim there is more
"character" in the longer name, but expressiveness of languages is
about choosing the right things to be short. What Goedel numbering
tells us is that there are a finite number of short names and after
that there are only long names. Expressiveness is about keeping
programs short in the face of that. It's a form of huffman coding, if
you will, but the game is not linearly arranged so you don't always
recognize it thus.
> though, but I admit I have no good argument
> for that at present other than my general intuitions and experience.
I'm not denying you have intuitions, and I value intuitions, but
intuitions cannot win the day. They inform goalsetting but they
cannot dictate goalsetting without forcing bad decisions.
As to experience, its power and relevance is only correctly judged in
the context of a correct (possibly "subjectively correct" and
"subjective judgment", alas) understanding of the problem. Let me be
concrete about this subjectivity: It happened several times that I
came up against people in the design of ISLISP who were national
representatives much older and "more experienced" by some metric.
Certainly they had been programming longer. But I had done 10 years of
Lisp language design, and they had not. And moreover, I had been
present for the design, deployment, and later bug reports of several
dialects of Lisp, something they had never done. Those people brought
important experience that I did not have but also vice versa. We
learned to inform and respect each other.
Although a standard resume would have shown them to simply be "more
experienced than I". I have come to understand experience as
massively a multi-dimensional issue. People are used to this
distinction in resume-writing when they say "n years experience in
buzzword-37" but they are not used to making this distinction at a
finer granularity. But I think the fact that they are not articulate
about their microexperience doesn't mean it doesn't matter. Whether
or not you have experience in general is not in question; whether or
not you have experience at all in the issues I'm raising is an open
question. (You might legitimately say the same of me. I don't mean
this to be insulting in any way. I would not be insulted by the same
statement said back.) The conversationally tricky part is getting to
a point of view where people even agree on the problem.
... And, incidentally, part of the problem in so doing is that words
we use in English have delayed attachment of semantics until the point
of use; they might do better by early attachment of semantics
according to package systems so that more refined uses of words (or,
as I once in a while do in the HyperSpec because I know there is only
one glossary of relevance, subscripted uses of words) are possible.
We say we are all talking about symbols, but we trip over our failure
to say cl:symbol or (scheme symbol) in the conversation in order to
disambiguate whose notion of symbol we mean... So your experience in
having navigated this conversation, and its complexity, due to
late-binding and the absence of an English-based package system should
perhaps tell you that a package system would be helpful. But somehow
it doesn't. So maybe you mean something different about experience
than the experience I see you having. Getting a foothold for an
intelligent conversation is much harder than people generally
acknowledge. They often prefer to ascribe the difficulty to people
being obstinant. It's often more fun to punch someone out than to
ask them for a detailed explanation of how they define all the words
they're using. (And if you're like Clinton and helpfully volunteer
that you've observed a difference in your own meaning of "is" and the
meaning that others are inferring, people don't say "thank you", they
accuse you of obfuscating... go figure.)
ego scripsi:
> > I don't think any serious reduction in expressive
> > power is going on here,
Kent M Pitman <······@world.std.com> scripsit:
> Yes, it is. The shift from expressive tasks to implementation tasks
> is the essence of the difference between Lisp and other languages
> for me. Every time you chip away at it, you chip away at Lisp's
> power. I said before that this is not about Turing power, and this
> remark on yours is an appeal to Turing power. Expressive power is
> exactly about concise targeted notation.
I do understand the difference between expressive and computational
power, and I did intend the former. I grant that there is *some*
reduction in expressive power, but I'm not sure that it's a serious
reduction. But your examples have "gotten my juices flowing" and
before I say something more concrete, I have to give it more time and
thought to get my thoughts together.
Thomas
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> A happy outcome for me in this would be an agreement to just refer to
> scheme symbols, at least in a language-neutral discussion, as
> "keywords" and not really as "symbols".
I am happy to adopt this terminology. Ironically, I think this issue
arises because we are having a symbol clash in our natural language.
We're all using the word "symbols", but half of us mean scheme::symbols
and the other half mean common-lisp::symbols. But both sides intern the
string "symbol" and when they come together the resulting confusion is the
socialogical eqivalent of:
> Error: Using #<Package "Scheme"> in #<Package "COMMON-LISP-USER">
> would cause name conflicts with symbols already present in that
> package: SYMBOL SCHEME:SYMBOL
Rephrasing my question in this terminology then: I have always understood
the need for packages in order to preserve backwards compatibility with
existing software like Maxsyma. However, with that motivation alone one
can reasonably view packages not as a feature that is desirable in and of
itself, but as a hack that is needed in order to incorporate old code that
was written back when people didn't understand as much about software
engineering as they do now. *IF* we had it to do over again (I recognize
that we don't) we might, with the benefit of hindsight, end up with a
design that doesn't have packages.
Until recently I thought this was the dominant view in the CL community,
but I have recently discovered this is not so. Many people believe that
packages are a feature in and of themselves, that they provide some
benefit independent of any legacy considerations, that if they had it to
do over again they would still incorporate packages into the design. I am
now trying to understand that point of view.
So far, the arguments I have heard advanced for the second point of view
have seemed to me to be more philosophical than technical, going something
like: "You need packages in order to support symbolic processing," where
"symbolic processing" is *defined* as computing with
common-lisp::symbols. I grant that argument, but it just begs a different
question: why is "symbolic processing" thus defined a good idea? What
does common-lisp::symbolic-processing buy you that
scheme::keyword-processing does not?
Note that by restating the question I do not mean to imply that it hasn't
already been answered. Kent has written at length about this, but it's
taking me some time to digest everything he's had to say. (I still have
to get some actual work done between newsgroup postings.)
Maybe what I've been doing these many years that I have always thought of
as symbolic processing is really scheme::keyword-processing (except that
I've been doing it in Common Lisp and not Scheme).
E.
I know I shouldn't be continuing on this thread, but....
···@jpl.nasa.gov (Erann Gat) writes:
> So far, the arguments I have heard advanced for the second point of view
> have seemed to me to be more philosophical than technical, going something
> like: "You need packages in order to support symbolic processing," where
> "symbolic processing" is *defined* as computing with
> common-lisp::symbols.
No, it's defined as computing with symbolic identifiers. CL symbols
are an example of such objects which can be used when multiple
applications are around. Scheme symbols are not.
> I grant that argument, but it just begs a different
> question: why is "symbolic processing" thus defined a good idea? What
> does common-lisp::symbolic-processing buy you that
> scheme::keyword-processing does not?
Why do we want modules in scheme? To allow each application to
associate different values with the same identifiers.
Why does symbolic processing require the namespacing of symbols?
Because we need to allow different applications to use their natural
terminology, and manage conflicts and similarities among them.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
···@jpl.nasa.gov (Erann Gat) writes:
> ... one
> can reasonably view packages not as a feature that is desirable in and of
> itself, but as a hack that is needed in order to incorporate old code that
> was written back when people didn't understand as much about software
> engineering as they do now. *IF* we had it to do over again (I recognize
> that we don't) we might, with the benefit of hindsight, end up with a
> design that doesn't have packages.
No. I would not recommend that anything be changed in the design of
Macsyma. I think it was designed very reasonably and I don't want
compatibility for their code, I want compatibility for their design
paradigm, which I consider an important one.
> Until recently I thought this was the dominant view in the CL community,
> but I have recently discovered this is not so. Many people believe that
> packages are a feature in and of themselves, that they provide some
> benefit independent of any legacy considerations, that if they had it to
> do over again they would still incorporate packages into the design.
Yes, that's right.
> I am now trying to understand that point of view.
I thought you were already to that point actually, but ok.
> So far, the arguments I have heard advanced for the second point of view
> have seemed to me to be more philosophical than technical, going something
> like: "You need packages in order to support symbolic processing," where
> "symbolic processing" is *defined* as computing with
> common-lisp::symbols.
No. It is defined as "computing with symbols that can be viewed
simplistically AS IF they had no package while being developed and while
no interaction was needed with other modules, but that can still be shared
or separated as appropriate with other applications when the need for
interaction arises". CL packages are the only kind of symbol data
that implement this goal.
> I grant that argument, but it just begs a different
> question: why is "symbolic processing" thus defined a good idea?
It isn't. You've defined it badly.
> What
> does common-lisp::symbolic-processing buy you that
> scheme::keyword-processing does not?
The ability to ignore identity issues beyond your own sandbox while you
develop things. The ability to just say (integrate '(sin x)) without
worrying that the Christian church will have a different meaning of SIN
but another math package may share the same meaning.
> Note that by restating the question I do not mean to imply that it hasn't
> already been answered. Kent has written at length about this, but it's
> taking me some time to digest everything he's had to say. (I still have
> to get some actual work done between newsgroup postings.)
Heh. So do I, believe it or not. I just had a well-timed activity lull for
work in the last couple of days, so had enough time to pursue this in depth.
> Maybe what I've been doing these many years that I have always thought of
> as symbolic processing is really scheme::keyword-processing (except that
> I've been doing it in Common Lisp and not Scheme).
Maybe. But maybe not.
Scheme always shares all symbols with all others having the same name.
CL allows you to chose whether you will or not.
Being pro-choice doesn't mean being pro-abortion. It means reserving the
right to take one or the other action. The pro-life term "pro-abortion"
incorrectly characterizes the others' movement as always favoring abortion
even though some pro-choicers have never had an abortion and never would;
they simply tolerate choice. Ironically, the pro-choice movement applies
the term "anti-choice" which does, I think, objectively describe their
political opponents.
Being pro-choice in symbol separation doesn't mean either always
sharing your symbols with others or always separating them. It means
getting the choice on a case-by-case basis. Don't make the mistake of
thinking that the opposite of pro-share [the Scheme point of view,
with alias "anti-choice"] is pro-separation. Nothing about the CL
approach keeps you from doing what Scheme does. But the Scheme
approach keeps you from doing what CL does, at least with any data
type called symbol.
And, as often happens, it becomes a war over who gets legitimate use
of the word.
It's worth noting, going back to the abortion debate, that the
argument is so intense that there have been reports of advocacy
organizations purchasing and otherwise influencing dictionaries in
order to get subtle changes in the definition of "life" so that they
can influence the debate on this matter, since some people actually
reason based on the words, rather than on their target meanings.
Words matter. Refined control of when they bind is critical.
There was an occurrence of this name-bonding thing in the design of
ISLISP actually. When WG16 was first working on an international
standard, we got together and talked about what its nature should be.
One national representative (I'll spare that person the embarrassment
of mentioning his country of origin) said to me privately "I don't
care what's in the standard. I care only that the standard is called
Common Lisp." "Why?" I asked, puzzled. "Because I am a consultant
and have told a client that Common Lisp is the future. If the
standard we make is called Common Lisp, whatever its content, then I
have told the truth. It doesn't matter what's in the language, only
that the words I said were true. If what we make has the semantics of
Common Lisp but is called something else, I will have given bad
advice." So you see, late-binding the meaning of a name ("Common
Lisp" in this case) may be helpful to some (this representative), but
is not helpful to all (his client, the committee, ...). It's a point
of view thing.
[I'll leave aside as irrelevant to this point an analysis of the fact
that this person, whose country had so little interest in the language
that they would let someone with this "design motivation" sit on a
committee, got the same "one vote" in the design of an international
lisp standard as the United States, who had done by then 30 years and
hundreds of millions of dollars worth of business in the same arena.]
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > A happy outcome for me in this would be an agreement to just refer to
> > scheme symbols, at least in a language-neutral discussion, as
> > "keywords" and not really as "symbols".
>
> I am happy to adopt this terminology. Ironically, I think this issue
> arises because we are having a symbol clash in our natural language.
But then if I say "Keywords would make a nice extension to Scheme,"
referring to keyworded arguments, confusion would arise.
> Until recently I thought this was the dominant view in the CL community,
> but I have recently discovered this is not so. Many people believe that
> packages are a feature in and of themselves, that they provide some
> benefit independent of any legacy considerations, that if they had it to
> do over again they would still incorporate packages into the design. I am
> now trying to understand that point of view.
That's exactly the question Kent answered in the post you're replying
to. I'm trying to get him to answer a different question, and you're
interfering. ;-)
It's all about identity. Not identity in the sense of eq, but in the
sense of how objects are named, i.e. how the programmer identifies
things. I'll speak of naming rather than identity to avoid the
confusion about all objects having identity in the sense of eq.
Kent is pointing out that it's not a bug, but a feature that symbols are
renamed by the package system. Merely renaming functions to be exported
would not be enough.
The issues regarding naming are the same, whether it's a programmer
naming a function, or a program naming some object with a symbol.
Keeping the names straight in different contexts is what the package
system does. A module system would only help keep the function names
straight.
I thought Kent's answer was clear, but perhaps the 3-paragraph summary
above will help.
I'm satisfied with Kent's answer as to why the CL package system is a
good thing. However, what I want is an answer to a different question.
I tried to ask this question in a previous post, but it wasn't clear, so
I'll try again with some background.
Scheme does not have a module system. Different implementations have
module systems as extensions, but there is no standard Scheme module
system, and I think some implementations don't even have one.
When using programs from different sources, you rely on luck to avoid
naming conflicts, or on uniqueness of prefixes chosen by the programmer
(e.g. Dorai's pregexp), much as you do with C. However, nobody claims
that C and R5RS Scheme are not examples of programming languages, even
though there is a serious naming issue that affects programming.
However, now that Kent has discovered that there's a serious naming
issue that affects symbolic processing, he's ready to conclude that
Scheme is not an example of a symbolic processing language. Sure, you
can do symbolic processing on a small scale, but start to integrate
symbolic processing code from different sources and you'll hit naming
conflicts.
Note that in the above paragraph, you could substitute any style of
programming for "symbolic processing", the only difference being that
the naming conflicts in question would be function names rather than
symbol names. Shall we go on to say that Scheme is not an exemplar of
*any* style of programming, at least until such time as it gets a
standardized module system?
--
<·······@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.sourceforge.net/
"alum.mit.edu")]>
In article <··················@magic-pi-ball.mit.edu>,
Bruce Lewis <·······@users.sourceforge.net> wrote:
>···@jpl.nasa.gov (Erann Gat) writes:
>
>> In article <···············@shell01.TheWorld.com>, Kent M Pitman
>> <······@world.std.com> wrote:
>>
>> > A happy outcome for me in this would be an agreement to just refer to
>> > scheme symbols, at least in a language-neutral discussion, as
>> > "keywords" and not really as "symbols".
>>
>> I am happy to adopt this terminology. Ironically, I think this issue
>> arises because we are having a symbol clash in our natural language.
>
>But then if I say "Keywords would make a nice extension to Scheme,"
>referring to keyworded arguments, confusion would arise.
I suggest that there is a technical, as opposed to mere
naming-cultural, roadblock also. :keywords in Common
Lisp are self-evaluating constants. Symbols (or
whatever they must now be called) in Scheme still have
the identifier role to play that symbols in general
(not the ones that are keywords) do in CL. Scheme
symbols are not (in general) self-evaluating, and CL
keywords are useless as variable identifiers.
Each category can do something significant the other
cannot. The "happy" identification of them that Kent
is suggesting and Erann is agreeing to requires an
amount of stretching that may not just be unhappy
but impossible.
--d
Bruce Lewis <·······@yahoo.com> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > <······@world.std.com> wrote:
> >
> > > A happy outcome for me in this would be an agreement to just refer to
> > > scheme symbols, at least in a language-neutral discussion, as
> > > "keywords" and not really as "symbols".
> >
> > I am happy to adopt this terminology. Ironically, I think this issue
> > arises because we are having a symbol clash in our natural language.
>
> But then if I say "Keywords would make a nice extension to Scheme,"
> referring to keyworded arguments, confusion would arise.
Say "keyword arguments". That's what they are. Arguments named by keywords.
> Scheme does not have a module system. Different implementations have
> module systems as extensions, but there is no standard Scheme module
> system, and I think some implementations don't even have one.
If they had packages, they could put one module system in each package. ;)
Sorry, just kidding. Couldn't resist.
> When using programs from different sources, you rely on luck to avoid
> naming conflicts, or on uniqueness of prefixes chosen by the programmer
> (e.g. Dorai's pregexp), much as you do with C. However, nobody claims
> that C and R5RS Scheme are not examples of programming languages, even
> though there is a serious naming issue that affects programming.
>
> However, now that Kent has discovered that there's a serious naming
> issue that affects symbolic processing, he's ready to conclude that
> Scheme is not an example of a symbolic processing language. Sure, you
> can do symbolic processing on a small scale, but start to integrate
> symbolic processing code from different sources and you'll hit naming
> conflicts.
Well, it's probably an extreme thing for you or me to summarize it that way.
More what I really mean is that if you want to learn what symbolic processing
is, you should learn it from CL, not from Scheme, since Scheme doesn't
exemplify the full range of issues that can really come up. As nearly as
I could tell when I looked the other day, Scheme doesn't even have GENSYM,
which it could have even absent packages...
> Note that in the above paragraph, you could substitute any style of
> programming for "symbolic processing", the only difference being that
> the naming conflicts in question would be function names rather than
> symbol names. Shall we go on to say that Scheme is not an exemplar of
> *any* style of programming, at least until such time as it gets a
> standardized module system?
I think it's a good example of Functional Programming. If the FP people
really believe that there's any importance to Church numerals, I'm sure
they can work around modules with similar "ease" until they get some,
muttering "functions are enough" all the way.
Bruce Lewis <·······@yahoo.com> writes:
> It's interesting that CL packages partition symbol plists and not
> just their associated functions/variables, but we're still talking
> about the same concept.
this sounds quite confused.
the package system partitions _symbols_. the objects themselves. it
doesn't care specifically for any slots in the symbol.
FOO:JOE and BAR:JOE are different symbols (objects!).
the source form "(get 'BAZ:COOKIE 'JOE)" gives different results when
evaluated in the FOO package and in the BAR package. that's because
"'JOE" gets interned as either FOO:JOE or BAR:JOE, and these are
different symbols (objects!). but the plist in question is the same
in both situations, because it belongs to BAZ:COOKIE, which is named
explicitly means the same object everywhere.
perhaps this is what you meant?
--
Shit doesn't hurt the world. It provides valuable fertilizer to help
plants grow, grass to help cows, and at least 33% of the content of
off-brand chocolates. --Dave Lynch in rec.music.progressive
Michael Livshin <········@yahoo.com> writes:
> Bruce Lewis <·······@yahoo.com> writes:
>
> > It's interesting that CL packages partition symbol plists and not
> > just their associated functions/variables, but we're still talking
> > about the same concept.
>
> this sounds quite confused.
>
> the package system partitions _symbols_. the objects themselves. it
> doesn't care specifically for any slots in the symbol.
>
> FOO:JOE and BAR:JOE are different symbols (objects!).
>
> the source form "(get 'BAZ:COOKIE 'JOE)" gives different results when
> evaluated in the FOO package and in the BAR package. that's because
> "'JOE" gets interned as either FOO:JOE or BAR:JOE, and these are
> different symbols (objects!). but the plist in question is the same
> in both situations, because it belongs to BAZ:COOKIE, which is named
> explicitly means the same object everywhere.
The above can be restated slightly more clearly as:
The _string_ "(get 'BAZ:COOKIE 'JOE)" will result in two different
_source forms_, when _read_ in the FOO package and the BAR package,
namely in the source forms (get 'BAZ:COOKIE 'FOO::JOE) vs. (get
'BAZ:COOKIE 'BAR::JOE). Since they are different source forms, they
will generally yield different results when being evaluated.
The interesting thing is that this separation of symbols will help you
in all cases where symbols are used as data (either keys or values or
whatever) in "global" data-structures, including, but not limited to,
the property lists of symbols themselves (when the same symbol is
shared between applications), but also other "global" lists, or
hash-tables, or other data-structures.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> writes:
> The interesting thing is that this separation of symbols will help you
> in all cases where symbols are used as data (either keys or values or
> whatever) in "global" data-structures, including, but not limited to,
> the property lists of symbols themselves (when the same symbol is
> shared between applications), but also other "global" lists, or
> hash-tables, or other data-structures.
Kent pointed out something broader--which I had missed until recently.
This is not just true of global data structures. It's also true of
data structures that the packages export to some third place, which
then combines them. That is, even if it is all really local, it still
works.
However, it seems to me that there is still a curious kind of "global
variable" thing going on here, though I can't quite put my finger on
it yet. I need to think more.
Thomas
·········@becket.net (Thomas Bushnell, BSG) writes:
> "Pierre R. Mai" <····@acm.org> writes:
>
> > The interesting thing is that this separation of symbols will help you
> > in all cases where symbols are used as data (either keys or values or
> > whatever) in "global" data-structures, including, but not limited to,
> > the property lists of symbols themselves (when the same symbol is
> > shared between applications), but also other "global" lists, or
> > hash-tables, or other data-structures.
>
> Kent pointed out something broader--which I had missed until recently.
>
> This is not just true of global data structures. It's also true of
> data structures that the packages export to some third place, which
> then combines them. That is, even if it is all really local, it still
> works.
That is what I label under "global", or "shared" as I've also put it
(since a resource that is shared between two, even unrelated, packages
might not necessarily be available just for everyone).
> However, it seems to me that there is still a curious kind of "global
> variable" thing going on here, though I can't quite put my finger on
> it yet. I need to think more.
And this global vs. local thing is completely unrelated to the issue
of global vs. local variables. E.g. a hash-table can be a global, or
shared resource, even if it is only ever bound to a lexical variable,
like in:
(let ((my-secret-hash (make-hash-table)))
(defun add-definition (name definition)
(setf (gethash name my-secret-hash) definition))
(defun lookup-definition (name)
(gethash name my-secret-hash)))
Given that other packages/programs are given access to add-definition
and lookup-definition, the hash-table bound to my-secret-hash becomes
a shared or possibly global resource. The package system will ensure
that people in different packages can use symbols as definition names,
without having to worry that they trample on other people's
definitions.
_Furthermore_ the package system even allows distinct packages to
cooperate in an orderly fashion, allowing one package to see the
definitions of another package for some things, but not clash with
other things.
You can either disallow shared data structures, or disallow interned
symbols (i.e. people will have to explicitly share gensyms/uninterned
symbols/strings in order to both refer to the same symbol), or use a
package system to deal with such a situation. I'm very certain that I
don't want to live with the former two "solutions".
[ Aside: Many CL programmers would prefer making the hash-table in the
above available through a special variable, instead of hiding it
away inside closures, aiding interactive debugging ]
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
One would have to be nuts to get involved in this packages discussion, so my sanity
must be wobblier than I thought.
Kent M Pitman wrote:
> CL allows me, simply in the symbol data, to control whether I'm doing various
> kinds of sharing. For example, I can separate my spaces, as in:
>
> (in-package "FLOWER")
> (setf (get 'rose 'color) 'red)
> (setf (get 'daisy 'color) 'white)
>
> (defun colors-among (things)
> (loop for thing in things
> when (get thing 'color)
> collect thing))
>
> (in-package "PEOPLE")
> (setf (get 'rose 'color) 'white)
> (setf (get 'daisy 'color) 'black)
>
> (defun colors-among (things)
> (loop for thing in things
> when (get thing 'color)
> collect thing))
>
> (in-package "OTHER")
>
> (flower:colors-among '(flower:rose people:rose flower:daisy))
> => (FLOWER:RED FLOWER:WHITE)
>
> (flower:colors-among '(flower:rose people:daisy people:rose))
> => (FLOWER:RED)
>
> (people:colors-among '(flower:rose people:rose flower:daisy))
> => (PEOPLE:WHITE)
>
> (people:colors-among '(flower:rose people:daisy people:rose))
> => (PEOPLE:BLACK PEOPLE:WHITE)
>
> Some examples of the value here:
>
> - The information is manifest in symbols, a primitive data structure
> in the language
> - Both the objects and the properties can be named by symbols,
> which are easy to type.
> - When debugging either the PEOPLE or FLOWER package, you don't worry
> about symbols and just type short names.
> - In OTHER contexts, when you want to mix people and flowers in the
> same list, it's easy to do without perturbing already chosen symbolic
> data structures and without yielding confusion.
There are plenty of good examples like this, and I have learned to cope with the
package system, but there are times when it does exactly the wrong thing. Suppose I
have written two programs, 'wordhack' and 'letterhack'. I encapsulate them in
packages as recommended, but as it happens I don't plan to use them together.
'wordhack' takes a file and returns a list of all the words that occur at least once
in it, represented as symbols in the "WH" package. It's convenient to export the
short words like 'a', 'the', etc. 'letterhack' takes a file and returns an alist
of (letter integer) pairs giving the frequencies of letters: ((a 762) (qu 3) ...),
where the symbols are interned in the "LH" package. I want to treat certain
two-character sequences as letters, but I want to get EQness, so I use symbols. I
export all the "letters."
Now several months later I write a third program that uses both packages, and I
suddenly discover that there is a name conflict between 'wh:a' and 'lh:a'. I don't
use the property list, value cell, or function cell of either symbol, so what I'd
really like to say is, "Treat these as the same symbol; they will never occur in the
same context, so there will never be any ambiguity about which is meant." Obviously,
this example is contrived, but this sort of thing has happened to me more than once.
Another example is where package 1 defines a macro that uses various symbols as
"local syntax" markers (such as 'for', 'in', when', etc. in '(loop for thing in
things when (get thing 'color) collect thing))), and package 2 defines another macro
that happens to use 'for' and 'collect' as local syntax markers. Now I write a
program that uses both packages. There seems to be no reason in the world to have
to write
(loop pkg1:for thing in things
when (get thing 'color)
pkg1:collect thing)
and
(wait pkg2:for (event e ...)
then pkg2:collect e)
but that's what I have to do.
Of course, in both these cases I can decide to make package "PKG1" or package "LH"
primary, and have "PKG2" and package "WH" import the conflicting symbols from their
partner before re-exporting them, or set up a third package to play the role of
dispenser of awkward symbols, but then this breaks all the applications that just
want to use, say, 'wordhack' without 'letterhack.' (In the actual example above,
'for' and 'collect' happen to be in the "CL" package, so the problem, by
happenstance, wouldn't arise; I just chose 'loop' so I could use a familiar macro.)
For these and other reasons, over the years my Common Lisp style has evolved away
from being "symbol-dependent." Whenever possible, I make sure my macros use local
syntax markers from the keyword package only. I always use tables instead of
property lists. I often define variant symbol types that print something like
symbols, and when appropriate read something like symbols, but differ from symbols
in various ways (such as not being interned until after the first time they are
printed).
However, symbols are a wonderful thing. Note that the whole reason symbols and
packages come up as an issue in the Scheme-Lisp world, and not in the Haskell-ML
world is that the language uses the same reader that user code uses. That makes
macros possible, but it also raises all these complications about binding time. On
balance I think I would prefer a module system to the package system, but it's not a
strong preference.
And now apparently I have to tack on some verbiage about how I love
"symbol-processing languages," and I despise Scheme (which, believe it or not, I do,
pretty much), and I'm competent to talk about all this because I once coauthored a
book on Lisp programming. Really, the tone on this newsgroup often sounds like a
meeting of a Communist Party cell circa 1935, with the main item on the agenda being
how to detect the Trotskyites among us.
-- Drew McDermott
Drew McDermott <··············@yale.edu> writes:
> Now several months later I write a third program that uses both packages, and I
> suddenly discover that there is a name conflict between 'wh:a' and 'lh:a'. I don't
> use the property list, value cell, or function cell of either symbol, so what I'd
> really like to say is, "Treat these as the same symbol; they will never occur in the
> same context, so there will never be any ambiguity about which is meant." Obviously,
> this example is contrived, but this sort of thing has happened to me more than once.
Why do you need to make (eq 'wh:a 'lh:a), then? Why not leave them
alone, since they will never occur in the same context?
> Another example is where package 1 defines a macro that uses various symbols as
> "local syntax" markers (such as 'for', 'in', when', etc. in '(loop for thing in
> things when (get thing 'color) collect thing))), and package 2 defines another macro
> that happens to use 'for' and 'collect' as local syntax markers. Now I write a
> program that uses both packages. There seems to be no reason in the world to have
> to write
LOOP uses the symbol-name. But the alternative of using keywords is
acceptable, since they are, in fact, keyword markers. That is, they
are being used for their texual name, not their application-dependent
symbolic identity.
> And now apparently I have to tack on some verbiage about how I love
> "symbol-processing languages," and I despise Scheme (which, believe it or not, I do,
> pretty much), and I'm competent to talk about all this because I once coauthored a
> book on Lisp programming. Really, the tone on this newsgroup often sounds like a
> meeting of a Communist Party cell circa 1935, with the main item on the agenda being
> how to detect the Trotskyites among us.
Well, we're not detecting anything, we're just telling people that
just because they don't use a feature doesn't mean that the feature
should be removed. Along the way, I suppose we're trying to defend the
validity of having namespaces for symbols.
Modules are not a replacement or alternative to packages. They cover
an aspect of namespacing that never occurs when you're doing purely
symbolic processing, since you're not using symbols for associated
values, but for the value of the symbol itself.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
In article <··············@photino.sid.rice.edu>, Rahul Jain
<·····@sid-1129.sid.rice.edu> wrote:
> Modules are not a replacement or alternative to packages. They cover
> an aspect of namespacing that never occurs when you're doing purely
> symbolic processing, since you're not using symbols for associated
> values, but for the value of the symbol itself.
I think I am slowly beginning to figure out what you're talking about
here, and it has led me to a new question (or maybe it's just a different
way of asking the old question):
If you're using symbols purely for their own values and not for any
associated values, how can you have interference between applications?
It's self-evident how two applications can interfere if they use the same
symbol for associated values (they'll stomp on the symbol's value, plist,
etc.) But if they don't use any associated values I don't see any way to
get in trouble.
So can you cite an example of how two applications can interfere with each
other by using the same symbol purely as a data value?
Thanks,
E.
···@jpl.nasa.gov (Erann Gat) writes:
> If you're using symbols purely for their own values and not for any
> associated values, how can you have interference between applications?
By the applications using the same symbol to refer to different information.
> It's self-evident how two applications can interfere if they use the same
> symbol for associated values (they'll stomp on the symbol's value, plist,
> etc.) But if they don't use any associated values I don't see any way to
> get in trouble.
Do you not see that name conflicts are horribly fatal when the name
_is_ the data?
> So can you cite an example of how two applications can interfere with each
> other by using the same symbol purely as a data value?
Say you have a list lists. The first element of each of the inner
lists is an object and the second element is a list of properties that
different applications have added to that object. Here we are using
``plists'', not attached to symbols, but to cons cells. If two
applications call a property by the same name, but don't intend to
share the property -> value mapping, that is a horrible mistake which
will, at best, cause one of the applications to die with a type-error.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
In article <··············@photino.sid.rice.edu>, Rahul Jain
<·····@sid-1129.sid.rice.edu> wrote:
> Do you not see that name conflicts are horribly fatal when the name
> _is_ the data?
No. It doesn't seem any more self-evident to me that this should be so
than that different applications sharing the same numbers should be
horribly fatal just because the numbers are the data.
> > So can you cite an example of how two applications can interfere with each
> > other by using the same symbol purely as a data value?
>
> Say you have a list lists. The first element of each of the inner
> lists is an object and the second element is a list of properties that
> different applications have added to that object. Here we are using
> ``plists'', not attached to symbols, but to cons cells. If two
> applications call a property by the same name, but don't intend to
> share the property -> value mapping, that is a horrible mistake which
> will, at best, cause one of the applications to die with a type-error.
I see that is a problem. But I would ascribe the problem not to the
sharing of the symbols, but to the sharing of the list. Obivously if two
applications, which by your stipulation do not intend to share data, place
their data in the same mutable data structure there will be problems. But
you'd have exactly the same problem if you used numbers for the keys
rather than symbols.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@photino.sid.rice.edu>, Rahul Jain
> <·····@sid-1129.sid.rice.edu> wrote:
>
> > Do you not see that name conflicts are horribly fatal when the name
> > _is_ the data?
>
> No. It doesn't seem any more self-evident to me that this should be so
> than that different applications sharing the same numbers should be
> horribly fatal just because the numbers are the data.
10 is defined to be eql to 10 no matter what application you're in.
Not the case with app1:foo and app2:foo.
> I see that is a problem. But I would ascribe the problem not to the
> sharing of the symbols, but to the sharing of the list.
Sharing of the list is the POINT of the system. If we didn't have
packages, it would be impossible.
> Obivously if two applications, which by your stipulation do not
> intend to share data,
I never stipulated that. In fact, I was thinking the opposite. They do
not intend to share their INTERNALS with each other in order for one
to introspect the other and magically change all symbol conflicts that
are unintended by the programmers of the two applications.
> place their data in the same mutable data structure there will be
> problems. But you'd have exactly the same problem if you used
> numbers for the keys rather than symbols.
No, numbers are globally interned, like keywords. Symbols are interned
in packages, so we can keep our application's internal structure
internal instead of requiring every other application to somehow
introspect our application about all its uses of symbols.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
In article <··············@photino.sid.rice.edu>, Rahul Jain
<·····@sid-1129.sid.rice.edu> wrote:
> > Obivously if two applications, which by your stipulation do not
> > intend to share data,
>
> I never stipulated that.
Then what did you mean by the following?
> If two
> applications call a property by the same name, but don't intend to
^^^^^^^^^^^^^^^^^^^
> share the property -> value mapping, ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@photino.sid.rice.edu>, Rahul Jain
> <·····@sid-1129.sid.rice.edu> wrote:
> > > Obivously if two applications, which by your stipulation do not
> > > intend to share data,
> > I never stipulated that.
> Then what did you mean by the following?
> > If two
> > applications call a property by the same name, but don't intend to
> ^^^^^^^^^^^^^^^^^^^
> > share the property -> value mapping, ...
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The properties are stored on the SAME data, but are meant to refer to
DIFFERENT properties. Because Lisp is a symbolic processing language,
it already have symbols that let me create uniqified keys that are
private to my application.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@photino.sid.rice.edu>, Rahul Jain
> <·····@sid-1129.sid.rice.edu> wrote:
>
> > Do you not see that name conflicts are horribly fatal when the name
> > _is_ the data?
>
> No. It doesn't seem any more self-evident to me that this should be so
> than that different applications sharing the same numbers should be
> horribly fatal just because the numbers are the data.
Yes, but numbers ARE NOT first-class identity (unless you are talking about
the first-class identity of a number or you are talking about machine
addresses). Just because you have a social security number that is "unique"
doesn't entitle you to conclude that if you have 555555555 as your SSN
that you can pass the result of (LIST MY-SSN (1+ 555555554)) and then
perform operations on the result on the assumption that you can sort out
"SSN's" from "addition results". If you think of the issuance of SSN
and "addition results" as separate applications both yielding data of type
INTEGER, then it is wrong to "uniquify" these two values. You really
want packaged integers so that (EQ SSN:555555555 ADDITION:555555555) are
different.
Before you go calling this ridiculous, you should know that in fact MACLISP
did eqify integers below a small nubmer (which varied between compilations,
since it used up the wasted space on the last page of the image to round
it out, and that number varied) that was at least 128. You could rely on
heap-consed small numbers like (+ 1 2) to be EQ, so 3 arriving in a function
that was not "number-compiled" (number-compiled functions received args in
registers reserved for raw numeric data instead of registers reserved for
pointers) would be EQ. "Large fixnums" (heh) were those that were big enough
that they did not get interned. You could get one of these and RPLACD it
(which changed the right-half of the machine word) with data that turned
its value to a new value, and you could force the value to be small again,
which would make effectively an "uninterned small fixnum". In Maclisp, now,
there was no character datatype. You just did (TYO 65) to print an A.
And eventually we made #/A [maclisp used / not \ for syntax quoting, and
before you ask, division was done by //] that would read as 65 so you didn't
have to remember all the ASCII codes, though even today I can still remember
a great many by number because we mostly had to debug code where we saw
the number. But by using "unintern small fixnums", which math operations
would never return, I was able to make numbers from 0 to 127 that the system
would never generate (you can call them character:0 to character:127 if you
like CL notation) and I was able to modify the printer so that it would show
this 65 as #/A becuase it could tell the difference between
(LIST #/A 65) and it could really actually know that this was
(#/A 65) rather than (65 65), which was the normal Maclisp interpretation.
That's not to say that you couldn't use (= #/A 65) and get T ... And
(+ #/A 1) wasn't doing class dispatch, so you got 66, not #/B, but I could
have my own (CHAR+ #/A 1) that did return #/B. It was a kludge, although
one of great fun because we struggled so long against integers there before
we had a character datatype, and there as a big thrill of finally beating
down the "identity problem" of 65 qua integer and 65 qua character.
So don't say numbers don't have the problem of packaging. ANYTHING WITH
IDENTITY has the problem of packaging. They just don't all have a mechanism
for managing that. And just because they don't have the mechanism doesn't
mean you don't feel that burden. The packaging issue is not about whether
CHAR+ can be written, because CHAR+ knows its first arg is a character and
its second arg isn't by virtue of the fact you're calling it or not. CHAR+
just does (AREF *THE-CHARS* (+ ARG1 ARG2)) without regard to the identity.
And this is more analogous to what you mean when you say "I can work around
this with no packages". But PRINT does not know it's getting a character
or a number. It is a true generic. And true generics look at an object's
identity to know what to do. PRINT in Maclisp could be made to know that
#/A was #/A and 65 was 65 even though they were both numbers. THAT is the
result of exploiting identity, and failing to do that is a failure to have
a real sense of the importance of identity.
Incidentally, Drew McDermott sent a bug report soon after we rolled out T
(Yale Scheme) complaining that we had made it impossible to rplacd
fixnums in T. [This fact is why I had a suspicion he was going to be more
"neutral" (or "Machiavellian"? :-) on the matter of identity. I knew
from history that Drew had a keen seat-of-the-pants understanding of object
identity if he'd gotten that far along. rplacd'ing fixnums was not something
most users knew about and it was not something you were "supposed" to do.
But life was simpler back then and we worked with what we had.]
>
> > > So can you cite an example of how two applications can interfere with each
> > > other by using the same symbol purely as a data value?
> >
> > Say you have a list lists. The first element of each of the inner
> > lists is an object and the second element is a list of properties that
> > different applications have added to that object. Here we are using
> > ``plists'', not attached to symbols, but to cons cells. If two
> > applications call a property by the same name, but don't intend to
> > share the property -> value mapping, that is a horrible mistake which
> > will, at best, cause one of the applications to die with a type-error.
>
> I see that is a problem. But I would ascribe the problem not to the
> sharing of the symbols, but to the sharing of the list. Obivously if two
> applications, which by your stipulation do not intend to share data, place
> their data in the same mutable data structure there will be problems. But
> you'd have exactly the same problem if you used numbers for the keys
> rather than symbols.
But all of symbol processing is "about" sharing lists. Actually, more to the
point, about sharing recursive data strucures. You simply can't require
that all symbols in your application are "of a kind" nor can you require that
you never make lists of more than one kind of data. It is not a
"list sharing error" to do (list (call-application-a) (call-application-b)).
That's _why_ we have heterogeneous lists in Lisp, and not, as in C, typed
lists. And the types LIST and SYMBOL are primitive "all-purpose" types
that must be used judiciously or you will trip over each other's data.
But judiciously implies cooperation, and since you can't rely on cooperation
to have with applications designed separately, then ALL other applications
are a perpetual threat to you unless at the application granularity the
default is "don't merge symbols" even though intrapplicatioin the default is
"merge symbols". It is critical to understand this.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> Yes, but numbers ARE NOT first-class identity (unless you are talking about
> the first-class identity of a number
Huh? Is that really what you meant?
> You really
> want packaged integers so that (EQ SSN:555555555 ADDITION:555555555) are
> different.
The SSN example seems a little contrived because I don't think of my SSN
as a number, I think of it as a string that happens to be made mostly of
digits.
How about this: we at NASA have in the past gotten ourselves into trouble
by failing to distinguish between "meters:5.1" and "inches:5.1". Is that
a valid example of the point you're making here? <aside> One of the
projects I'm involved in is dealing with exactly this issue. </aside>
> Before you go calling this ridiculous,
FWIW, my initial reaction to all this was not "this is ridiculous" but
rather "Hm, what an interesting idea. This feels like it may lead
somewhere."
> So don't say numbers don't have the problem of packaging.
I didn't mean to say that. It does seem to me that whatever packaging
problems symbols and numbers have they should be the same in both cases.
Common Lisp doesn't package numbers, and that doesn't seem to cause major
problems.
> But all of symbol processing is "about" sharing lists.
Yes, but is it necessarily about sharing *mutable* lists? It seems to me
that mutability is a necessary condition for serious problems to result.
> It is critical to understand this.
I'm working on it. I really am. And I really appreciate all your help.
(That goes for everyone who has responded, but Kent, you in particular
have gone above and beyond the call of duty.)
I'm off to ruminate.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> > You really
> > want packaged integers so that (EQ SSN:555555555 ADDITION:555555555) are
> > different.
>
> The SSN example seems a little contrived because I don't think of my SSN
> as a number, I think of it as a string that happens to be made mostly of
> digits.
Which kind of answers your question below:
> I didn't mean to say that. It does seem to me that whatever packaging
> problems symbols and numbers have they should be the same in both cases.
> Common Lisp doesn't package numbers, and that doesn't seem to cause major
> problems.
We normally only assign mathematical meaning to numbers, so that all
applications sharing the number 5 will more or less interpret it in
compatible ways, _and_ use other data-types, such as measures,
strings, or indeed symbols for things that don't fit this "unique"
interpretation rule.
Or in other words, people have gotten used to viewing numbers as
keywords, and not symbols, and hence (sub)consciously work around the
problems that the one-package regime of those entails.
That doesn't mean that numbers couldn't profit from a package system,
just like symbols can. OTOH, given current coding practice -- in most
current languages --, which more or less universally assumes the one
package system with unique interpretation state of affairs,
introducing such a system might cause some upheaval.
Indeed, given that state of affairs, one might probably want to export
all numbers from the COMMON-LISP package (or some other package like
MATH-NUMBER that is in the default :use-package list), so that all
packages get shared numbers by default.
> > But all of symbol processing is "about" sharing lists.
>
> Yes, but is it necessarily about sharing *mutable* lists? It seems to me
> that mutability is a necessary condition for serious problems to result.
No, the issue isn't at all about mutability of the list. It is about
the sharing of a list that contains symbols, and the ability to keep
seperate those keys which should be kept separate, and conflate those
keys that should be conflated.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Eureka!
I finally had my "aha!" moment this evening as I was out walking my dog.
I think it was Kent's bringing numbers into the picture that did it for
me. I had always thought of numbers as just symbols that happened to have
a total ordering defined on them. Then it dawned on me that this total
ordering *defines* the semantics of numbers in a way that everyone agrees
on. There is no such convention for non-numeric symbols. So if I want to
use Bills '5 and Bob's '5 at the same time it's a good bet (though not a
sure one) they'll mean the same thing. That is not true for Bill's 'foo
and Bob's 'foo, so if I want to use them both at the same time (and
particularly if I want to use them as key values into some associative
data structure - mutable or not) they have to be different 'foo's.
Then I got home and found this:
In article <··············@orion.bln.pmsf.de>, "Pierre R. Mai"
<····@acm.org> wrote:
> We normally only assign mathematical meaning to numbers, so that all
> applications sharing the number 5 will more or less interpret it in
> compatible ways, _and_ use other data-types, such as measures,
> strings, or indeed symbols for things that don't fit this "unique"
> interpretation rule.
>
> Or in other words, people have gotten used to viewing numbers as
> keywords, and not symbols, and hence (sub)consciously work around the
> problems that the one-package regime of those entails.
So I think I get it now.
Thanks Kent, and everyone else, for bearing with me. I'm going to stop
asking questions for a couple of days now. :-)
E.
···@jpl.nasa.gov (Erann Gat) writes:
I don't hope to explain myself better than Kent but...
> I see that is a problem.
Well.
> But I would ascribe the problem not to the
> sharing of the symbols, but to the sharing of
> the list.
Now, imagine that I *need* to do this for some
bizarre reason. Doesn't matter why, just believe
that it has to be that way.
> Obivously if two applications, which by your
> stipulation do not intend to share data, place
> their data in the same mutable data structure
> there will be problems.
Then packages will help me to solve this problem
(or will make the problem vanish).
Conclusion: I have two applications not intended
to share data with a third one. Sometime later I
*need* (no matter why) to share symbols with a
third one. Packages will be usefull then.
HTH
--
Eduardo Mu�oz
In article <·············@jet.es>, "Eduardo =?iso-8859-1?q?Mu=F1oz?="
<···@jet.es> wrote:
> > But I would ascribe the problem not to the
> > sharing of the symbols, but to the sharing of
> > the list.
>
> Now, imagine that I *need* to do this for some
> bizarre reason. Doesn't matter why, just believe
> that it has to be that way.
<suspending disbelief> OK.
> > Obivously if two applications, which by your
> > stipulation do not intend to share data, place
> > their data in the same mutable data structure
> > there will be problems.
>
> Then packages will help me to solve this problem
> (or will make the problem vanish).
Granted.
> Conclusion: I have two applications not intended
> to share data with a third one. Sometime later I
> *need* (no matter why) to share symbols with a
> third one. Packages will be usefull then.
Yes. That makes perfect sense.
</suspending disbelief>
So now I understand everything except one little detail: your "bizzare
reason" (as you put it) to share data between two independently developed
applications in the same mutable data structure.
We've already covered the case where the reason is support of legacy
code. But what if you were starting from a clean slate (and when I say a
clean slate I mean so clean that you could write your code in T rather
than Common Lisp if you chose to)?
E.
In article <····················@eglaptop.jpl.nasa.gov>,
···@jpl.nasa.gov (Erann Gat) writes:
> ...
> So now I understand everything except one little detail: your "bizzare
> reason" (as you put it) to share data between two independently developed
> applications in the same mutable data structure.
lets assume there are two packages that process some information about
certain objects, keep some of this information using symbols attached
to the objects. for some reason somebody wants to process both sets
simultaneously
hs
--
don't use malice as an explanation when stupidity suffices
··@heaven.nirvananet (Hartmann Schaffer) writes:
> In article <····················@eglaptop.jpl.nasa.gov>,
> ···@jpl.nasa.gov (Erann Gat) writes:
> > ...
> > So now I understand everything except one little detail: your "bizzare
> > reason" (as you put it) to share data between two independently developed
> > applications in the same mutable data structure.
>
> lets assume there are two packages that process some information about
> certain objects, keep some of this information using symbols attached
> to the objects. for some reason somebody wants to process both sets
> simultaneously
Now we've gone from "a bizarre reason" to "some reason". Could you be a bit
more specific? Maybe even concrete?
Matthias
···@jpl.nasa.gov (Erann Gat) writes:
> We've already covered the case where the reason is support of legacy
> code.
No, you have dismissed as legacy code anything that has certain design
criteria that you don't use and that you assume is a thing of the
past. I don't think you could define legacy code in a way as to make
it possible to dismiss.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > We've already covered the case where the reason is support of legacy
> > code.
>
> No, you have dismissed as legacy code anything that has certain design
> criteria that you don't use and that you assume is a thing of the
> past. I don't think you could define legacy code in a way as to make
> it possible to dismiss.
Sorry, I didn't mean to sound dismissive. I just meant to say that this
had been discussed, and so it shouldn't be discussed again.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> So now I understand everything except one little detail: your "bizzare
> reason" (as you put it) to share data between two independently developed
> applications in the same mutable data structure.
I don't know, profiling, call recording and other introspection tools
like doc generators don't seem all that bizzare to me. Nor do USQL
editing contexts or other MOP hackeries for that matter. All of these
are things I've written or worked with in the last few months.
> We've already covered the case where the reason is support of legacy
> code. But what if you were starting from a clean slate (and when I
> say a clean slate I mean so clean that you could write your code in
> T rather than Common Lisp if you chose to)?
Most of the tools I mention above would still be much simpler to
implement with a package system since their managing mutable data
structures with data from any number of systems, most of which are not
known at runtime and would not really work reliably with just some
non-standard coding convention for prefixing or whatever.
If Lisp is about symbolic computation, than most anything dealing with
reflection and introspection as a general tool will benefit from
having the symbolic elements have object identity.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
Ask me about Common Lisp Enterprise Eggplants at Red Bean!
Craig Brozefsky wrote:
> I don't know, profiling, call recording and other introspection tools
> like doc generators don't seem all that bizzare to me. Nor do USQL
> editing contexts
I recently looked at the source for USQL. Most of it seemed pretty
understandable, but I couldn't figure out the purpose of editing
contexts. Could you explain how they're used?
Thanks.
···@jpl.nasa.gov (Erann Gat) writes:
> I see that is a problem. But I would ascribe the problem not to the
> sharing of the symbols, but to the sharing of the list. Obivously if two
> applications, which by your stipulation do not intend to share data, place
> their data in the same mutable data structure there will be problems. But
> you'd have exactly the same problem if you used numbers for the keys
> rather than symbols.
With your permission :-), may I put forward another attempt at
explaining why packages are such a big deal in (Common-)Lisp, while
they are not so important in other langages, including fairly similar
languages (but still non-Lisps :-) such as Scheme.
Erann had it almost when he said that the big deal is the sharing of
the lists. The more comprehensive explanation, however, can be
summarized in one word: "state".
I claim that the fundamental difference between a Lisp symbol and a
Scheme symbol (much like between a Lisp symbol and a number) is that
the former has state while the latter is a pure value.
Two Scheme applications using symbols and using them in a such a way
that they ascribe "meaning" to them will have to use some kind of map
data structure (aka "environment"). Each of these applications will
have its own environment(s), so even if some of the symbols are used
by both, their respective meanings will not get confused. This is
because these shared symbols will be used to index separate mappings.
Moreover, because of the statelessness of symbols (symbols "simply
are"), they have no inherent meaning. When you pass symbols around,
you have to be aware of the fact that you are only passing the keys,
not the associated meanings. If you want to pass the meaning, then do
so explicitly (by passing the value associated with the key, not the
key, or even by passing the map along with the key). A good example
for this is the way symbols are not procedures in Scheme (even if they
are bound to procedures by some environment). When we fold + over
a list of numbers, we do not pass the symbol + but its value. If we
pass the symbol, we get a runtime exception.
In Lisp, on the other hand, symbols have state. What does that mean
semantically? It means that symbols are represented by records of
/locations/, where these locations are then mapped by one single,
global, system-wide mapping (that is usually referred to as the
/store/) to values. Therefore, even Lisp's symbols are *mapped* to
values, the only difference is that all applications are forced to
share one single map. (The map is typically implemented directly in
hardware by your computer's memory subsystem.) And since everyone
uses the same map and *knows* that everyone else is also using that
map, one can pass symbols around not just as keys but /as if/ they
were the actual data. (The receiver can always get at that data by
"looking up" the key. He already has the map.)
This should make it all clear: If we can't keep the maps separate, we
*better* keep the keys (that is: the symbols) separate. Hence the
need for things like Common Lisp's package system.
Now, in all fairness, it should be said that this one single map is
pretty darn efficient. On the other end of the spectrum, Scheme's
symbols distinguish themselves by a definite lack of efficiency when
it comes to using them as keys. One thing that could help a lot would
be to have an arbitrary but stable total order imposed on symbols,
which would make it possible to use them as keys in balanced
trees. (Actually, you could extract the symbol's name, which is a
string, and then compare strings. But that's still pretty awful.)
Even better would be to have associated with each symbol a unique
integer that can be used to index hash tables etc.
By the way, the package system does not really solve the name clash
problem, it merely postpones it. Symbols encapsulated in packages can
no longer clash, but it is still possible that packages themselves
clash. When this happens, I suppose one can hack around the problem by
using RENAME-PACKAGE (which mucks around with the package namespace --
of which there is only one), but that's conceptually no different
(albeit much more succinct in practice) than having a similar
RENAME-SYMBOL (and a single symbol namespace).
For a more comprehensive approach to solving the name clash problem, I
invite the interested reader to having a look at our TOPLAS paper where
we explain the concept of /Hierarchical Modularity/.
Matthias Blume, Andrew W. Appel: Hierarchical modularity.
TOPLAS 21(4): 813-847 (1999)
Best regards,
Matthias
Matthias Blume <········@shimizu-blume.com> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > I see that is a problem. But I would ascribe the problem not to the
> > sharing of the symbols, but to the sharing of the list. Obivously if two
> > applications, which by your stipulation do not intend to share data, place
> > their data in the same mutable data structure there will be problems. But
> > you'd have exactly the same problem if you used numbers for the keys
> > rather than symbols.
>
> With your permission :-), may I put forward another attempt at
> explaining why packages are such a big deal in (Common-)Lisp, while
> they are not so important in other langages, including fairly similar
> languages (but still non-Lisps :-) such as Scheme.
This is a fine thing to talk about but has not been the topic of conversation.
We aren't talking about packages being a big deal in a language, but rather
it being a big deal in a language _if_ you are encoding information as symbols.
That's like the difference between a probability and a conditional probability,
if you're looking for an analogy. Your previous paragraph implies you
want to speak about the parent topic (the analog of general probabilities),
which has not been in focus.
> Erann had it almost when he said that the big deal is the sharing of
> the lists. The more comprehensive explanation, however, can be
> summarized in one word: "state".
>
> I claim that the fundamental difference between a Lisp symbol and a
> Scheme symbol (much like between a Lisp symbol and a number) is that
> the former has state while the latter is a pure value.
No. This completely and utterly misses the point. None of anything I've
been arguing would be any different if symbols didn't have state. It would
be an utter pain, but one could model all the issues we've been talking
about in a state=free language. I don't plan to try, however.
I consider the pursuit of statefree-ness to be largely a waste except
for very specialized circumstances.
> Two Scheme applications using symbols and using them in a such a way
> that they ascribe "meaning" to them will have to use some kind of map
> data structure (aka "environment"). Each of these applications will
> have its own environment(s), so even if some of the symbols are used
> by both, their respective meanings will not get confused. This is
> because these shared symbols will be used to index separate mappings.
No. The key issue here is that if you use only symbols as keys, and not
formulas of mixed keys from diffrent applications, you indulge the mistaken
idea that you can, in fact, use one or the other environment. If you
have a list containing some symbols from one application and some from
another, and there is no "compiler map" telling you how to traverse it so
that you can secretly tell which is which by "convention" rather than
"identity", you're cheating too. But if you're a truly generic function
whose only clue to which application owns which symbol is the symbol's
identity itself, then you're going to lose, even in a state-free system.
Lisp source forms themselves are such an example.
Scheme has to "paint" symbols to keep the environments straight, but has to
use something other than color to do the painting since it has only one color.
Lisp symbols come pre-painted and don't require this mechanism.
> Moreover, because of the statelessness of symbols (symbols "simply
> are"), they have no inherent meaning. When you pass symbols around,
> you have to be aware of the fact that you are only passing the keys,
> not the associated meanings. If you want to pass the meaning, then do
> so explicitly (by passing the value associated with the key, not the
> key, or even by passing the map along with the key). A good example
> for this is the way symbols are not procedures in Scheme (even if they
> are bound to procedures by some environment). When we fold + over
> a list of numbers, we do not pass the symbol + but its value. If we
> pass the symbol, we get a runtime exception.
>
> In Lisp, on the other hand, symbols have state. What does that mean
> semantically? It means that symbols are represented by records of
> /locations/, where these locations are then mapped by one single,
> global, system-wide mapping (that is usually referred to as the
> /store/) to values. Therefore, even Lisp's symbols are *mapped* to
> values, the only difference is that all applications are forced to
> share one single map. (The map is typically implemented directly in
> hardware by your computer's memory subsystem.) And since everyone
> uses the same map and *knows* that everyone else is also using that
> map, one can pass symbols around not just as keys but /as if/ they
> were the actual data. (The receiver can always get at that data by
> "looking up" the key. He already has the map.)
>
> This should make it all clear: If we can't keep the maps separate, we
> *better* keep the keys (that is: the symbols) separate. Hence the
> need for things like Common Lisp's package system.
This all misses the point.
> Now, in all fairness, it should be said that this one single map is
> pretty darn efficient. On the other end of the spectrum, Scheme's
> symbols distinguish themselves by a definite lack of efficiency when
> it comes to using them as keys. One thing that could help a lot would
> be to have an arbitrary but stable total order imposed on symbols,
> which would make it possible to use them as keys in balanced
> trees. (Actually, you could extract the symbol's name, which is a
> string, and then compare strings. But that's still pretty awful.)
> Even better would be to have associated with each symbol a unique
> integer that can be used to index hash tables etc.
The symbol's name has nothing to do with anything either, other than it's
used for initial lookup when loading the system. Once the system is running,
the name is irrelevant.
> By the way, the package system does not really solve the name clash
> problem, it merely postpones it. Symbols encapsulated in packages can
> no longer clash, but it is still possible that packages themselves
> clash.
This is both true and not true. One could say the same of memory in a
computer, too. It's all just numbered locations. But we can build and
use structures that mediate this problem. I've been using the Java-style
naming of packages like COM.HYPERMETA.NET.HTTP.SERVER and my chosen names
are nicely general even if the namespace is flat.
> When this happens, I suppose one can hack around the problem by
> using RENAME-PACKAGE (which mucks around with the package namespace --
> of which there is only one), but that's conceptually no different
> (albeit much more succinct in practice) than having a similar
> RENAME-SYMBOL (and a single symbol namespace).
It doesn't have to be done after-the-fact. Also, it doesn't change
object identity. And if you correctly understood the problem of identity,
you'd realize that rename-symbol wouldn't help the problem we're discussing
either. I'm not saying you don't know how to program. I'm saying you're
completely missing the discussion we're having and you're talking about
an unrelated topic that we're not talking about.
At least, that's my take.
Kent M Pitman <······@world.std.com> writes:
> > I claim that the fundamental difference between a Lisp symbol and a
> > Scheme symbol (much like between a Lisp symbol and a number) is that
> > the former has state while the latter is a pure value.
>
> No. This completely and utterly misses the point. None of anything I've
> been arguing would be any different if symbols didn't have state. It would
> be an utter pain, but one could model all the issues we've been talking
> about in a state=free language. I don't plan to try, however.
I wish you would. Then I could refute you.
> I consider the pursuit of statefree-ness to be largely a waste except
> for very specialized circumstances.
Have you been reading what I wrote? "State" is nothing but a map
(just like an environment), except that there is only one such map,
and it is shared by everyone. All the problems with Lisp symbols
arise from their statefulness -- which is to say that they are all
interpreted relative to one and the same context. While I agree that
sometimes it is inconvenient to get rid of all state, I found that
most of the time having state around is an utter pain in the neck in
the long run.
> > Two Scheme applications using symbols and using them in a such a way
> > that they ascribe "meaning" to them will have to use some kind of map
> > data structure (aka "environment"). Each of these applications will
> > have its own environment(s), so even if some of the symbols are used
> > by both, their respective meanings will not get confused. This is
> > because these shared symbols will be used to index separate mappings.
>
> No. The key issue here is that if you use only symbols as keys, and not
> formulas of mixed keys from diffrent applications, you indulge the mistaken
> idea that you can, in fact, use one or the other environment.
Using the correct environment, of course, is crucial. But correct
programs, by definition, use the correct environments in their
respective correct situation. This is exactly like your number
example: Yes, an integer could be the result of adding two other
numbers or it could by a SSN. But confusing the two wouldn't happen
in a sensible program since the two do *not* get mixed (except in
generic situations such as output routines). And as I said, I would
not pass symbols around in mixed formulas, I would pass around what
they denote within their respective home contexts.
> If you
> have a list containing some symbols from one application and some from
> another, and there is no "compiler map" telling you how to traverse it so
> that you can secretly tell which is which by "convention" rather than
> "identity", you're cheating too.
Could you give a real-world example for this situation?
(If I truly were in the above situation, I would program the
distinction explicitly, marking each symbol with its "kind". This
corresponds to forming the discriminated sum of two domains. What you
are apparently advocating is to use the package as the sum tag.)
> But if you're a truly generic function
> whose only clue to which application owns which symbol is the symbol's
> identity itself, then you're going to lose, even in a state-free system.
I truly generic function should certainly not have to care which
application owns which symbol. Otherwise it wouldn't be "truly
generic", would it?
[ A long explanation, which I think was very much to the point, snipped... ]
> This all misses the point.
Sorry, could you elaborate? I think that it was exactly to the point.
Summarily dismissing an argumentation as "missing the point" is not
going to help a meanigful discussion.
(I am really puzzled how you could possibly think that I am talking
about something unrelated.)
Matthias
Matthias Blume <········@shimizu-blume.com> writes:
> ... confusing the two wouldn't happen
> in a sensible program since the two do *not* get mixed (except in
> generic situations such as output routines). And as I said, I would
> not pass symbols around in mixed formulas, I would pass around what
> they denote within their respective home contexts.
Then you are excluding the programming situations that require packages.
Not everyone does.
If you could control the set of ways that people use a general purpose
language, then you could get rid of all kinds of things.
It is the case that modern programming often uses other data types than
symbols, but this is not to say that they are doing "symbol processing".
A great many AI systems that people have built use symbols to denote
everything, and encode various formulas and rules as combinations of
symbols in a general-purpose way that you are lining out. That _is_
symbol processing. If you don't like it, and you are content to make it
break, then indeed you can get rid of packages. But not otherwise.
But it has nothing to do with state.
You could say that someone has done
(DEFPACKAGE "FLOWER"
(:USE "CL")
(:EXPORT "ADD-RANDOM-FLOWER" "COUNT-FLOWERS"))
(IN-PACKAGE "FLOWER")
(DEFVAR *FLOWERS* '())
(DEFUN MAKE-FLOWER (NAME)
(PUSHNEW NAME *FLOWERS*))
(MAKE-FLOWER 'ROSE)
(MAKE-FLOWER 'TULIP)
(MAKE-FLOWER 'DAISY)
(DEFUN COUNT-FLOWERS (LIST) (COUNT-IF (LAMBDA (X) (MEMBER X *FLOWERS*)) LIST))
(DEFUN ADD-RANDOM-FLOWER (THINGS)
(ADJOIN (ELT *FLOWERS* (RANDOM (LENGTH *FLOWERS*)))
THINGS))
(DEFPACKAGE "PEOPLE"
(:USE "CL")
(:EXPORT "ADD-RANDOM-PERSON" "COUNT-PEOPLE"))
(IN-PACKAGE "PEOPLE")
(DEFVAR *PEOPLE* '())
(DEFUN MAKE-PERSON (NAME)
(PUSHNEW NAME *PEOPLE*))
(MAKE-PERSON 'FRED)
(MAKE-PERSON 'ROSE)
(MAKE-PERSON 'DAISY)
(DEFUN COUNT-PEOPLE (LIST) (COUNT-IF (LAMBDA (X) (MEMBER X *PEOPLE*)) LIST))
(DEFUN ADD-RANDOM-PERSON (THINGS)
(ADJOIN (ELT *PEOPLE* (RANDOM (LENGTH *PEOPLE*)))
THINGS))
(DEFPACKAGE "SCENERY" (:USE "PEOPLE" "FLOWER"))
(IN-PACKAGE "SCENERY") ;uses PEOPLE and FLOWER
(COUNT-FLOWERS (ADD-RANDOM-PERSON (ADD-RANDOM-FLOWER '())))
=> 1
In this case, there is no 'state'. The problem doesn't happen because of
proper package separation.
Now, if you do this in Scheme sans state, and you assume a module system
such that FLOWER-MODULE and PEOPLE-MODULE are written separately, then you
get something like:
(LET ((FLOWER-MODULE
(LET ((FLOWERS '(ROSE TULIP DAISY)))
(LET ((COUNT-FLOWERS
(LAMBDA (LIST)
(COUNT-IF (LAMBDA (X) (MEMBER X FLOWERS))
LIST)))
(ADD-RANDOM-FLOWER
(LAMBDA (THINGS)
(ADJOIN (ELT FLOWERS (RANDOM (LENGTH FLOWERS)))
THINGS))))
(LIST 'COUNT-FLOWERS COUNT-FLOWERS
'ADD-RANDOM-FLOWER ADD-RANDOM-FLOWER))))
(PEOPLE-MODULE
(LET ((PEOPLE '(ROSE TULIP DAISY)))
(LET ((COUNT-PEOPLE
(LAMBDA (LIST)
(COUNT-IF (LAMBDA (X) (MEMBER X PEOPLE))
LIST)))
(ADD-RANDOM-PERSON
(LAMBDA (THINGS)
(ADJOIN (ELT PEOPLE (RANDOM (LENGTH PEOPLE)))
THINGS))))
(LIST 'COUNT-PEOPLE COUNT-PEOPLE
'ADD-RANDOM-PERSON ADD-RANDOM-PERSON)))))
(LET ((SCENERY-MODULE (APPEND FLOWER-MODULE PEOPLE-MODULE)))
(LET ((COUNT-FLOWERS (GET SCENERY-MODULE 'COUNT-FLOWERS))
(COUNT-PEOPLE (GET SCENERY-MODULE 'COUNT-PEOPLE))
(ADD-RANDOM-PERSON (GET SCENERY-MODULE 'ADD-RANDOM-PERSON))
(ADD-RANDOM-FLOWER (GET SCENERY-MODULE 'COUNT-FLOWERS)))
(FUNCALL COUNT-FLOWERS
(FUNCALL ADD-RANDOM-PERSON
(FUNCALL ADD-RANDOM-FLOWER '()))))))
=> 2
In this case, there is no 'state' and yet the problem still occurs.
Kent M Pitman <······@world.std.com> writes:
[ ... sample code snipped ... ]
>
> In this case, there is no 'state' and yet the problem still occurs.
Sorry, all that yelling made my eyes hurt. :-) I did not read your
example, but I have independently arrived at the conclusion that you
are right: State is not the root of the problem. Instead, the root of
the problem is "throwing symbols into a single context if they
originally came from different contexts". State is one (but
widespread) example for this situation (as I have explained) but
"context" can also have other manifestations, including simply the
interpretation of symbols as done by the person who is feeding input
to the program.
In any case, packages do not really solve this problem. In fact, no
language technology can solve it automatically. Here is why:
Suppose you have two applications A and B that were developed
independently. A uses a set of symbols SA while B uses its set of
symbols SB. Now take any x \in SA and any y \in SB and ask the question
"is x the same symbol as y".
In the non-package case, the question will be answered with "yes" iff
x and y were spelled the same in their respective applications. In
the package case, the answer will uniformely be "no". But in reality,
the answer is sometimes "yes" and sometimes "no", it can be "yes"
regardless of whether x and y were spelled the same, and likewise it
can be "no" regardless of spelling. Packages remove false positives,
but they do nothing about false negatives. Moreover, they can
introduce additional false negatives.
Since the question of whether x and y are "the same" depends on what A
and B are trying to do, the only true solution can be obtained by
actually sitting down and making a decision case-by-case, for every x
\in SA and every y \in SB. This simply cannot be automated at all
because it is application-specific.
--
-Matthias
Matthias Blume <········@shimizu-blume.com> writes:
> Suppose you have two applications A and B that were developed
> independently. A uses a set of symbols SA while B uses its set of
> symbols SB. Now take any x \in SA and any y \in SB and ask the question
> "is x the same symbol as y".
>
> In the non-package case, the question will be answered with "yes" iff
> x and y were spelled the same in their respective applications. In
> the package case, the answer will uniformely be "no". But in reality,
> the answer is sometimes "yes" and sometimes "no", it can be "yes"
> regardless of whether x and y were spelled the same, and likewise it
> can be "no" regardless of spelling. Packages remove false positives,
> but they do nothing about false negatives. Moreover, they can
> introduce additional false negatives.
Packages allow false-negatives to be removed via export/import mechanisms.
> Since the question of whether x and y are "the same" depends on what A
> and B are trying to do, the only true solution can be obtained by
> actually sitting down and making a decision case-by-case, for every x
> \in SA and every y \in SB. This simply cannot be automated at all
> because it is application-specific.
I may be wrong, but I don't recall anyone saying anything about packages
being fully automatic in this discussion. Exporting and importing is
necessarily a manual task.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Matthias Blume <········@shimizu-blume.com> writes:
>
> > Suppose you have two applications A and B that were developed
> > independently. A uses a set of symbols SA while B uses its set of
> > symbols SB. Now take any x \in SA and any y \in SB and ask the question
> > "is x the same symbol as y".
> >
> > In the non-package case, the question will be answered with "yes" iff
> > x and y were spelled the same in their respective applications. In
> > the package case, the answer will uniformely be "no". But in reality,
> > the answer is sometimes "yes" and sometimes "no", it can be "yes"
> > regardless of whether x and y were spelled the same, and likewise it
> > can be "no" regardless of spelling. Packages remove false positives,
> > but they do nothing about false negatives. Moreover, they can
> > introduce additional false negatives.
>
> Packages allow false-negatives to be removed via export/import mechanisms.
Could you kindly show me how? If A calls something "foo" and B calls
the same thing "bar", how can import/export magic make the respective
symbols identical?
(I looked at the HyperSpec, but I couldn't figure out how this trick
would work. I guess I am not looking in the right place...)
Matthias
Matthias Blume <········@shimizu-blume.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Matthias Blume <········@shimizu-blume.com> writes:
> >
> > > Suppose you have two applications A and B that were developed
> > > independently. A uses a set of symbols SA while B uses its set of
> > > symbols SB. Now take any x \in SA and any y \in SB and ask the question
> > > "is x the same symbol as y".
> > >
> > > In the non-package case, the question will be answered with "yes" iff
> > > x and y were spelled the same in their respective applications. In
> > > the package case, the answer will uniformely be "no". But in reality,
> > > the answer is sometimes "yes" and sometimes "no", it can be "yes"
> > > regardless of whether x and y were spelled the same, and likewise it
> > > can be "no" regardless of spelling. Packages remove false positives,
> > > but they do nothing about false negatives. Moreover, they can
> > > introduce additional false negatives.
> >
> > Packages allow false-negatives to be removed via export/import mechanisms.
>
> Could you kindly show me how? If A calls something "foo" and B calls
> the same thing "bar", how can import/export magic make the respective
> symbols identical?
It can't, of course - not in any Lisp I know of. The problem is in the
understanding of what the potential for a false negative is. As you
have indicated above in the text reproduced below:
> > > But in reality,
> > > the answer is sometimes "yes" and sometimes "no", it can be "yes"
> > > regardless of whether x and y were spelled the same, and likewise it
> > > can be "no" regardless of spelling.
The fallicy of this statement is that it can never be "yes" if x and y
are spelled differently, because of the definition of internment. To
intern a symbol is to use its name to map to its identity. Thus, names
not spelled the same will never cause a false negative, since they are
definitionally true negatives.
In Kent's example which you responded to, he defines a couple of
different roses and daisys, each representing non-identical symbols
in flowers and people packages. If you indeed decided that Rose was
both a flower and a person, then you would export it from one package
and import it into the other, then it would be available to you as the
identical symbol. No magic here, just a modification to the internment
rules. At that point, referring to rose from either package would yield
the same rose [sorry, I tried to work in some cute saying like "a rose
from any other package has the same plist", but it really doesn't work]
> (I looked at the HyperSpec, but I couldn't figure out how this trick
> would work. I guess I am not looking in the right place...)
You're asking for tricks, magic (above), and (in the post I responded
to) automated decision making. You won't find them in packages. It
would be similar to reading in the Hyperspec that NTH works on lists,
and then wondering why you can't access your arrays with it.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Matthias Blume <········@shimizu-blume.com> writes:
>
> > Duane Rettig <·····@franz.com> writes:
> >
> > > Matthias Blume <········@shimizu-blume.com> writes:
> > >
> > > > Suppose you have two applications A and B that were developed
> > > > independently. A uses a set of symbols SA while B uses its set of
> > > > symbols SB. Now take any x \in SA and any y \in SB and ask the question
> > > > "is x the same symbol as y".
> > > >
> > > > In the non-package case, the question will be answered with "yes" iff
> > > > x and y were spelled the same in their respective applications. In
> > > > the package case, the answer will uniformely be "no". But in reality,
> > > > the answer is sometimes "yes" and sometimes "no", it can be "yes"
> > > > regardless of whether x and y were spelled the same, and likewise it
> > > > can be "no" regardless of spelling. Packages remove false positives,
> > > > but they do nothing about false negatives. Moreover, they can
> > > > introduce additional false negatives.
> > >
> > > Packages allow false-negatives to be removed via export/import mechanisms.
> >
> > Could you kindly show me how? If A calls something "foo" and B calls
> > the same thing "bar", how can import/export magic make the respective
> > symbols identical?
>
> It can't, of course - not in any Lisp I know of. The problem is in the
> understanding of what the potential for a false negative is. As you
> have indicated above in the text reproduced below:
>
> > > > But in reality,
> > > > the answer is sometimes "yes" and sometimes "no", it can be "yes"
> > > > regardless of whether x and y were spelled the same, and likewise it
> > > > can be "no" regardless of spelling.
>
> The fallicy of this statement is that it can never be "yes" if x and y
> are spelled differently, because of the definition of internment. To
> intern a symbol is to use its name to map to its identity. Thus, names
> not spelled the same will never cause a false negative, since they are
> definitionally true negatives.
If I write a program and call something "Zwerg" and you write a
program and call *that same thing* "dwarf", then we meant to refer to
the same thing. But the symbols we chose to refer to it are, by Lisp
rules, always different. That's what I call a "false negative". So
the answer can be "yes" or "no" if you look at the intended meaning
(even if the spelling is different). I already know that it can never
be "yes" in Lisp -- which is exactly what I am complaining about.
Now, as Kent has already explained, in current CL you can't program
around this sort of false negative without actually modifying one of
the two programs in question. But even he thinks that different rules
for this would have been reasonable to adopt, too.
Matthias
Matthias Blume <········@shimizu-blume.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Matthias Blume <········@shimizu-blume.com> writes:
> >
> > > Duane Rettig <·····@franz.com> writes:
> > >
> > > > Matthias Blume <········@shimizu-blume.com> writes:
> > > >
> > > > > But in reality,
> > > > > the answer is sometimes "yes" and sometimes "no", it can be "yes"
> > > > > regardless of whether x and y were spelled the same, and likewise it
> > > > > can be "no" regardless of spelling.
> >
> > The fallicy of this statement is that it can never be "yes" if x and y
> > are spelled differently, because of the definition of internment. To
> > intern a symbol is to use its name to map to its identity. Thus, names
> > not spelled the same will never cause a false negative, since they are
> > definitionally true negatives.
>
> If I write a program and call something "Zwerg" and you write a
> program and call *that same thing* "dwarf", then we meant to refer to
> the same thing. But the symbols we chose to refer to it are, by Lisp
> rules, always different. That's what I call a "false negative".
It's not a false negative. What it means is that you can't use symbols'
identities to create the mapping you want. It's simply a bug in your
design.
> So
> the answer can be "yes" or "no" if you look at the intended meaning
> (even if the spelling is different). I already know that it can never
> be "yes" in Lisp -- which is exactly what I am complaining about.
If you redesign your program not to have the bug of relying on symbols'
identities to be mapped from different names, then of course it can
be "yes". There are several ways in any current Lisp to associate two
different symbols to have the same meaning.
> Now, as Kent has already explained, in current CL you can't program
> around this sort of false negative without actually modifying one of
> the two programs in question. But even he thinks that different rules
> for this would have been reasonable to adopt, too.
He was explicit about it _not_ being CL. He said "... a Lisp dialect
could exist ...". But then we might be discussing whether or not such
a dialect is really a Lisp ...
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Matthias Blume <········@shimizu-blume.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> [ ... sample code snipped ... ]
> >
> > In this case, there is no 'state' and yet the problem still occurs.
>
> Sorry, all that yelling made my eyes hurt. :-) I did not read your
> example, but I have independently arrived at the conclusion that you
> are right: State is not the root of the problem. Instead, the root of
> the problem is "throwing symbols into a single context if they
> originally came from different contexts". State is one (but
> widespread) example for this situation (as I have explained) but
> "context" can also have other manifestations, including simply the
> interpretation of symbols as done by the person who is feeding input
> to the program.
>
> In any case, packages do not really solve this problem. In fact, no
> language technology can solve it automatically. Here is why:
>
> Suppose you have two applications A and B that were developed
> independently. A uses a set of symbols SA while B uses its set of
> symbols SB. Now take any x \in SA and any y \in SB and ask the question
> "is x the same symbol as y".
This is the philosophical problem I often refer to as the
"morning star/evening star" problem. The term refers to Venus, which
is often called the "morning star" or "the evening star". The question is
whether if you are told that Venus is the morning star, you then "know" that
Venus in the evening star. Of course you don't, since they are separate
objects until you join them. And the joining can be quite non-trivial
no matter how you do it.
At least packages give us a terminology for talking about the issues.
> In the non-package case, the question will be answered with "yes" iff
> x and y were spelled the same in their respective applications. In
> the package case, the answer will uniformely be "no". But in reality,
> the answer is sometimes "yes" and sometimes "no", it can be "yes"
> regardless of whether x and y were spelled the same, and likewise it
> can be "no" regardless of spelling. Packages remove false positives,
> but they do nothing about false negatives. Moreover, they can
> introduce additional false negatives.
As a matter of pragmatic engineering design, though, having two options
gives you more choices than one.
> Since the question of whether x and y are "the same" depends on what A
> and B are trying to do, the only true solution can be obtained by
> actually sitting down and making a decision case-by-case, for every x
> \in SA and every y \in SB. This simply cannot be automated at all
> because it is application-specific.
Of course, if you're allowed to go back and change things,
sharing can be introduced centrally without disturbing the
programs themselves by doing
(defpackage "AB-COMMON"
(:use)
(:export "Z" "MMM" "QZY"))
(defpackage "A"
(:use "CL" "AB-COMMON"))
(defpackage "B"
(:use "CL" "AB-COMMON"))
It's harder to describe this concisely in a non-packaged world.
The presence of packages makes this action 'modular' in the sense of
being able to be isolated programmatically from uses of the symbols
in a way that it's hard to do in a non-packaged world.
In practice, there are usually two cases: (a) The system has no
maintainer and cannot be changed without paying consultants lots of $$
to learn the system. In this case, it's probably easier to get
approval to edit a package definition for old code than to get into
the guts of the system. (b) The system is maintained. In this case,
getting someone to check for and include a package declaration like
the above is a nice modular change to request, rather than detailing a
lot of edits within a system the client doesn't own.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> This is the philosophical problem I often refer to as the
> "morning star/evening star" problem. The term refers to Venus, which
> is often called the "morning star" or "the evening star". The question is
> whether if you are told that Venus is the morning star, you then "know" that
> Venus in the evening star. Of course you don't, since they are separate
> objects until you join them. And the joining can be quite non-trivial
> no matter how you do it.
FWIW, I actually wrote my master's thesis about this very problem lo these
many years ago. There's an extensive literature on this problem that goes
back hundreds of years.
You can actually "solve" the philosophical problem with environments.
(You can never really solve a philosophical problem; the best you can do
is tell a satisfying story about it.) The "problem" is only a problem if
you insist that a label be tightly bound to its denotation, that is, that,
that you do not distinguish between the label "Venus" and the planet
Venus. (There are some additional requirements for the problem to
manifest itself having to do with what the meaning of the word "is" is.
No, I'm not kidding.) If you admit both the label and the planet as
distinct first-class objects then the problem evaporates, because what you
"know" when you know that the Morning Star "is" Venus is simply that the
denotations of the labels "Venus" and "Morning Star" (which in Lisp
parlance means the result of looking up "Venus" and "Morning Star" in your
binding environment) are the same object. You don't necessarily know that
the denotation/binding of "Evening Star" also is that same object.
There are more interesting variations on the problem, like the Jekyl/Hyde
problem. If Holmes knows that Mr. Hyde is a murderer, does he know that
Dr. Jekyl is a murderer? One could argue that he does, since what he
knows is that the denotation of "Hyde" is a murderer, and the denotation
of "Hyde" is the same object as the denotation of "Jekyl". (In my thesis
I proposed solving this problem with environments whose bindings were a
function of time.)
The problem with symbols is that when you use them for symbolic processing
they are their own denotations, so you can't separate the denotation from
the object. Trying to distinguish between symbols (or words) and
entitities that denote them gets you quickly tangled in all kinds of
practical and logical knots, like trying to distinguish between the word
"Venus" and the phrase "the word 'Venus'". If you try to follow this
through to its conclusion you end up with a version of the Russel paradox
involving the phrase "phrases that do not denote themselves" or something
like that.
It's distressingly easy to waste inordinate amounts of time worrying about
such things.
E.
Matthias Blume <········@shimizu-blume.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Matthias Blume <········@shimizu-blume.com> writes:
> >
> > > Suppose you have two applications A and B that were developed
> > > independently. A uses a set of symbols SA while B uses its set of
> > > symbols SB. Now take any x \in SA and any y \in SB and ask the question
> > > "is x the same symbol as y".
> > >
> > > In the non-package case, the question will be answered with "yes" iff
> > > x and y were spelled the same in their respective applications. In
> > > the package case, the answer will uniformely be "no". But in reality,
> > > the answer is sometimes "yes" and sometimes "no", it can be "yes"
> > > regardless of whether x and y were spelled the same, and likewise it
> > > can be "no" regardless of spelling. Packages remove false positives,
> > > but they do nothing about false negatives. Moreover, they can
> > > introduce additional false negatives.
> >
> > Packages allow false-negatives to be removed via export/import mechanisms.
>
> Could you kindly show me how?
I think they meant symbols with the same name.
> If A calls something "foo" and B calls
> the same thing "bar", how can import/export magic make the respective
> symbols identical?
>
> (I looked at the HyperSpec, but I couldn't figure out how this trick
> would work. I guess I am not looking in the right place...)
By CL definition, these are not and cannot be identical symbols since symbols
have only one name. To have two names, you have to have two identities.
It's not the only way it could have been defined. It's just how we defined
things, and so it's a bit arbitrary, I suppose.
It's not inconceivable to me that a Lisp dialect could exist which allowed
what you say, of course. The symbol names would be outboard and (as with
the exported-from-package question) you'd have to ask for a symbol
name with respect to a package. You'd also probably want a default
name of the symbol which was, effectively, an intrinsic property of the
symbol (such as symbol-name is now) or else with every new package you'd
have to specify a name for all other symbols with respect to that package,
etc.
READ and PRINT are not defined to go through such a mechanism in CL,
but the notion of packages isn't bankrupt for not addressing this. It
could be trivially fixed in a dialect motivated to permit this.
(There might be some performance cost, though, because symbols
couldn't be printed without first checking the package's exception
table to see if an alternate name was in play.)
So it depends on whether you are trying to talk about CL or about packages
as to the answer here. For most of this discussion, I think we've been
talking about the idea of packages in general, and so I think it's fair for
me to identify that this is fixable.
Kent M Pitman <······@world.std.com> writes:
> Matthias Blume <········@shimizu-blume.com> writes:
>
> > Duane Rettig <·····@franz.com> writes:
> >
> > > Matthias Blume <········@shimizu-blume.com> writes:
> > >
> > > > Suppose you have two applications A and B that were developed
> > > > independently. A uses a set of symbols SA while B uses its set of
> > > > symbols SB. Now take any x \in SA and any y \in SB and ask the question
> > > > "is x the same symbol as y".
> > > >
> > > > In the non-package case, the question will be answered with "yes" iff
> > > > x and y were spelled the same in their respective applications. In
> > > > the package case, the answer will uniformely be "no". But in reality,
> > > > the answer is sometimes "yes" and sometimes "no", it can be "yes"
> > > > regardless of whether x and y were spelled the same, and likewise it
> > > > can be "no" regardless of spelling. Packages remove false positives,
> > > > but they do nothing about false negatives. Moreover, they can
> > > > introduce additional false negatives.
> > >
> > > Packages allow false-negatives to be removed via export/import mechanisms.
> >
> > Could you kindly show me how?
>
> I think they meant symbols with the same name.
>
> > If A calls something "foo" and B calls
> > the same thing "bar", how can import/export magic make the respective
> > symbols identical?
> >
> > (I looked at the HyperSpec, but I couldn't figure out how this trick
> > would work. I guess I am not looking in the right place...)
>
> By CL definition, these are not and cannot be identical symbols since symbols
> have only one name. To have two names, you have to have two identities.
>
> It's not the only way it could have been defined. It's just how we defined
> things, and so it's a bit arbitrary, I suppose.
>
> It's not inconceivable to me that a Lisp dialect could exist which allowed
> what you say, of course. The symbol names would be outboard and (as with
> the exported-from-package question) you'd have to ask for a symbol
> name with respect to a package. You'd also probably want a default
> name of the symbol which was, effectively, an intrinsic property of the
> symbol (such as symbol-name is now) or else with every new package you'd
> have to specify a name for all other symbols with respect to that package,
> etc.
>
> READ and PRINT are not defined to go through such a mechanism in CL,
> but the notion of packages isn't bankrupt for not addressing this. It
> could be trivially fixed in a dialect motivated to permit this.
> (There might be some performance cost, though, because symbols
> couldn't be printed without first checking the package's exception
> table to see if an alternate name was in play.)
>
> So it depends on whether you are trying to talk about CL or about packages
> as to the answer here. For most of this discussion, I think we've been
> talking about the idea of packages in general, and so I think it's fair for
> me to identify that this is fixable.
Right. But it would be fixable even without packages if one would
allow symbols to be established as aliases of each other. A way of
establishing aliases, and a way of removing name-symbol associations
is all that's needed. It would be clumsy, to be sure (because you
have to take care of each symbol individually), but it would work just
fine. First you read in application A. Then you establish those
symbols of B that are meant to be aliases of symbols in A as such.
Then you remove (unintern) those of A's symbols whose names are used
for other symbols by B. Then you read in B. Voila!
Matthias
Matthias Blume <········@shimizu-blume.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Matthias Blume <········@shimizu-blume.com> writes:
> >
> > > Duane Rettig <·····@franz.com> writes:
> > >
> > > > Matthias Blume <········@shimizu-blume.com> writes:
> > > >
> > > > > Suppose you have two applications A and B that were developed
> > > > > independently. A uses a set of symbols SA while B uses its set of
> > > > > symbols SB. Now take any x \in SA and any y \in SB and ask the question
> > > > > "is x the same symbol as y".
> > > > >
> > > > > In the non-package case, the question will be answered with "yes" iff
> > > > > x and y were spelled the same in their respective applications. In
> > > > > the package case, the answer will uniformely be "no". But in reality,
> > > > > the answer is sometimes "yes" and sometimes "no", it can be "yes"
> > > > > regardless of whether x and y were spelled the same, and likewise it
> > > > > can be "no" regardless of spelling. Packages remove false positives,
> > > > > but they do nothing about false negatives. Moreover, they can
> > > > > introduce additional false negatives.
> > > >
> > > > Packages allow false-negatives to be removed via export/import mechanisms.
> > >
> > > Could you kindly show me how?
> >
> > I think they meant symbols with the same name.
> >
> > > If A calls something "foo" and B calls
> > > the same thing "bar", how can import/export magic make the respective
> > > symbols identical?
> > >
> > > (I looked at the HyperSpec, but I couldn't figure out how this trick
> > > would work. I guess I am not looking in the right place...)
> >
> > By CL definition, these are not and cannot be identical symbols since symbols
> > have only one name. To have two names, you have to have two identities.
> >
> > It's not the only way it could have been defined. It's just how we defined
> > things, and so it's a bit arbitrary, I suppose.
> >
> > It's not inconceivable to me that a Lisp dialect could exist which allowed
> > what you say, of course. The symbol names would be outboard and (as with
> > the exported-from-package question) you'd have to ask for a symbol
> > name with respect to a package. You'd also probably want a default
> > name of the symbol which was, effectively, an intrinsic property of the
> > symbol (such as symbol-name is now) or else with every new package you'd
> > have to specify a name for all other symbols with respect to that package,
> > etc.
> >
> > READ and PRINT are not defined to go through such a mechanism in CL,
> > but the notion of packages isn't bankrupt for not addressing this. It
> > could be trivially fixed in a dialect motivated to permit this.
> > (There might be some performance cost, though, because symbols
> > couldn't be printed without first checking the package's exception
> > table to see if an alternate name was in play.)
> >
> > So it depends on whether you are trying to talk about CL or about packages
> > as to the answer here. For most of this discussion, I think we've been
> > talking about the idea of packages in general, and so I think it's fair for
> > me to identify that this is fixable.
>
> Right. But it would be fixable even without packages if one would
> allow symbols to be established as aliases of each other. A way of
> establishing aliases, and a way of removing name-symbol associations
> is all that's needed. It would be clumsy, to be sure (because you
> have to take care of each symbol individually), but it would work just
> fine. First you read in application A. Then you establish those
> symbols of B that are meant to be aliases of symbols in A as such.
> Then you remove (unintern) those of A's symbols whose names are used
> for other symbols by B. Then you read in B. Voila!
Are you asking for something like
(define-alias current-package:s1 some-other-package:s2)
?
If so, would (untested: Kent will come up with something better :) )
(defmacro define-alias (s1 s2)
`(define-symbol-macro ,s1 ,s2))
(defmacro define-aliases (aliases)
`(progn ,@(mapcar (lambda (alias-pair)
`(define-alias ,(first alias-pair)
,(second alias-pair))))))
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Are you asking for something like
>
> (define-alias current-package:s1 some-other-package:s2)
> If so, would (untested: Kent will come up with something better :) )
>
> (defmacro define-alias (s1 s2)
> `(define-symbol-macro ,s1 ,s2))
That wouldn't help symbolic identity, just identifier relationships.
(define-alias foo:bar baz:foo)
will not make (eq 'foo:bar 'baz:foo), so it has no relation to
symbolic processing, only to cases where the lisp evaluator is
used. In effect, you're telling the evaluator that, in its
environment, the two symbols map to the same values.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Are you asking for something like
> >
> > (define-alias current-package:s1 some-other-package:s2)
>
> > If so, would (untested: Kent will come up with something better :) )
> >
> > (defmacro define-alias (s1 s2)
> > `(define-symbol-macro ,s1 ,s2))
>
> That wouldn't help symbolic identity, just identifier relationships.
>
> (define-alias foo:bar baz:foo)
>
> will not make (eq 'foo:bar 'baz:foo), so it has no relation to
> symbolic processing, only to cases where the lisp evaluator is
> used. In effect, you're telling the evaluator that, in its
> environment, the two symbols map to the same values.
Right. You could, of course, do
(defun meq (x y) (eq (macroexpand x) (macroexpand y)))
but that would be a lot of overhead.
_However_, DEFINE-SYMBOL-MACRO doesn't do much more than GET or
GETHASH. Its only purpose as a separate operator is to make those
actions happen at a particular point in evaluation. If you aren't
evaluating, you might as well use simpler and more well-known operations.
I suspect this is the reason that AI expert system shells have often used
symbols whose names are unimportant. Things that look more like they came
out of GENTEMP (though hopefully generated by better bookkeeping).
Presumably they effectively know that the Lisp-name of the thing is not the
right name to use, and by associating a name and perhaps even identity
information as properties, one can flexibly interconnect symbols with
different Lisp-names in a way that is resolvable by appropriately created
equality predicates appropriate to the expert system shell, rather than
the clumsy blunt nearly semantically bankrupt equality predicates CL comes
with by default.
Incidentally, lest you think that calling them clumsy and blunt and
nearly semantically bankrupt is a criticism, I should note that I have
a memory that Joel Moses (long-ago-co-creator of MACSYMA) make
an argument that effectively said that overly exacting semantics for
things like Macsyma, which did a lot of symbol processing, would have
crippled its usefulness. On some days I'd very much disagree with
him, but on others I can see his point. The same issue recently came
up when discussing InterLisp. So when I speak critically of EQUAL and
EQUALP in this way, you should understand I mean it in the nicest of
ways.
I wish I could remember whether JM wrote up those remarks on MACSYMA
and where... Maybe someone else remembers, too, and can cite a
reference? It was in the context of the hopelessly complicated EV
function (kind of like EVAL on steroids, with massive numbers of weird
options for almost being able to control it in about 20 different
ways). I might have been inclined to say it should have been instead
20 different functions, but then no one would probably have used it
because keeping "precise" track of the interactions of 20 such
functions as they recursively descended an expression of arbitrary
kind would have probably been harder to deal with than the
strangenesses that come from just using a single operator that is
easier to call and sometimes surprisese you with its output.
Kent M Pitman <······@world.std.com> writes:
> Matthias Blume <········@shimizu-blume.com> writes:
>
> > Duane Rettig <·····@franz.com> writes:
> >
> > > Matthias Blume <········@shimizu-blume.com> writes:
> > >
> > > > Suppose you have two applications A and B that were developed
> > > > independently. A uses a set of symbols SA while B uses its set of
> > > > symbols SB. Now take any x \in SA and any y \in SB and ask the question
> > > > "is x the same symbol as y".
> > > >
> > > > In the non-package case, the question will be answered with "yes" iff
> > > > x and y were spelled the same in their respective applications. In
> > > > the package case, the answer will uniformely be "no". But in reality,
> > > > the answer is sometimes "yes" and sometimes "no", it can be "yes"
> > > > regardless of whether x and y were spelled the same, and likewise it
> > > > can be "no" regardless of spelling. Packages remove false positives,
> > > > but they do nothing about false negatives. Moreover, they can
> > > > introduce additional false negatives.
> > >
> > > Packages allow false-negatives to be removed via export/import mechanisms.
> >
> > Could you kindly show me how?
>
> I think they meant symbols with the same name.
I did.
> > If A calls something "foo" and B calls
> > the same thing "bar", how can import/export magic make the respective
> > symbols identical?
> >
> > (I looked at the HyperSpec, but I couldn't figure out how this trick
> > would work. I guess I am not looking in the right place...)
>
> By CL definition, these are not and cannot be identical symbols since symbols
> have only one name. To have two names, you have to have two identities.
Right.
> It's not the only way it could have been defined. It's just how we defined
> things, and so it's a bit arbitrary, I suppose.
>
> It's not inconceivable to me that a Lisp dialect could exist which allowed
> what you say, of course. The symbol names would be outboard and (as with
> the exported-from-package question) you'd have to ask for a symbol
> name with respect to a package. You'd also probably want a default
> name of the symbol which was, effectively, an intrinsic property of the
> symbol (such as symbol-name is now) or else with every new package you'd
> have to specify a name for all other symbols with respect to that package,
> etc.
What you are really describing is a different way of specifying the
interning process. You could either do so by replacing the existing
one or by creating a new style of mapping name/package combinations
(or name/alias combinations) to symbols' identities.
> READ and PRINT are not defined to go through such a mechanism in CL,
> but the notion of packages isn't bankrupt for not addressing this. It
> could be trivially fixed in a dialect motivated to permit this.
> (There might be some performance cost, though, because symbols
> couldn't be printed without first checking the package's exception
> table to see if an alternate name was in play.)
> So it depends on whether you are trying to talk about CL or about packages
> as to the answer here. For most of this discussion, I think we've been
> talking about the idea of packages in general, and so I think it's fair for
> me to identify that this is fixable.
I assume that by using the word "fix", you would consider (under some
different Lisp dialect) the lack of ability to perform the suggested
mappings to be a bug. In order to design such new methods of interning,
we would have to consider what would be affected in relation to the
current CL package system; I'm not sure if any of these design goals
were explicit when CL was designed (some may have been inherited from
previous Lisps), but I'm sure that they included terseness, consistency,
determinism, ability to arbitrate conflicts, etc. I think such a more
explicit and "flexible" interning system would necessarily have negative
impacts on most of these design goals.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Kent M Pitman <······@world.std.com> writes:
...
> What you are really describing is a different way of specifying the
> interning process. You could either do so by replacing the existing
> one or by creating a new style of mapping name/package combinations
> (or name/alias combinations) to symbols' identities.
Yes. I just wanted to acknowledge the possibility, since it had been
vaguely alluded to as an issue. I wasn't advocating that we solve
this problem, just noting that it's not impossible to try. (Success,
on the other hand would be judged by criteria such as those enumerated
by you below.)
> > READ and PRINT are not defined to go through such a mechanism in
> > CL, but the notion of packages isn't bankrupt for not addressing
> > this. It could be trivially fixed in a dialect motivated to
> > permit this. (There might be some performance cost, though,
> > because symbols couldn't be printed without first checking the
> > package's exception table to see if an alternate name was in
> > play.)
>
> > So it depends on whether you are trying to talk about CL or about
> > packages as to the answer here. For most of this discussion, I
> > think we've been talking about the idea of packages in general,
> > and so I think it's fair for me to identify that this is fixable.
>
> I assume that by using the word "fix", you would consider (under
> some different Lisp dialect) the lack of ability to perform the
> suggested mappings to be a bug. In order to design such new methods
> of interning, we would have to consider what would be affected in
> relation to the current CL package system; I'm not sure if any of
> these design goals were explicit when CL was designed (some may have
> been inherited from previous Lisps), but I'm sure that they included
> terseness, consistency, determinism, ability to arbitrate conflicts,
> etc. I think such a more explicit and "flexible" interning system
> would necessarily have negative impacts on most of these design
> goals.
Yes, I did realize this and do agree. My parenthetical remark in the
prior paragraph was intended to leave room for such concerns, which I
shouldn't have labeled as merely performance cost. I'm glad you
expanded the list to show the full breadth of issues.
Nor does the fact that this list is longer mean the problem is
necessarily unsolvable. It just highlights that language designers
often have tremendous burdens on them to think about the whole
ecological effect of seemingly isolated changes....
Matthias Blume <········@shimizu-blume.com> writes:
> Even better would be to have associated with each symbol a unique
> integer that can be used to index hash tables etc.
I think it is certainly true that when we compare Common Lisp and
Scheme on these sorts of points, we have to allow for actual
full-blooded Scheme systems, which do have things like hash tables.
Scheme does not lack hash tables, what it lacks is *standardized* hash
tables. This is still a deficiency, indeed, but it's a different sort
of deficiency.
Thomas
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@photino.sid.rice.edu>, Rahul Jain
> <·····@sid-1129.sid.rice.edu> wrote:
>
> > Modules are not a replacement or alternative to packages. They cover
> > an aspect of namespacing that never occurs when you're doing purely
> > symbolic processing, since you're not using symbols for associated
> > values, but for the value of the symbol itself.
>
> I think I am slowly beginning to figure out what you're talking about
> here, and it has led me to a new question (or maybe it's just a different
> way of asking the old question):
>
> If you're using symbols purely for their own values and not for any
> associated values, how can you have interference between applications?
> It's self-evident how two applications can interfere if they use the same
> symbol for associated values (they'll stomp on the symbol's value, plist,
> etc.) But if they don't use any associated values I don't see any way to
> get in trouble.
>
> So can you cite an example of how two applications can interfere with each
> other by using the same symbol purely as a data value?
I don't know if it is what you are looking for, but how about this:
(defpackage "FOO"
(:use "COMMON-LISP")
(:export "A" "BINGO"))
(in-package "FOO")
(defclass a ()
((x :initarg bingo)))
(defpackage "BAR"
(:use "COMMON-LISP")
(:export "B" "BINGO"))
(in-package "BAR")
(defclass b ()
((y :initarg bingo)))
(defpackage "BOOM"
(:use "COMMON-LISP")
(:export "C"))
(in-package "BOOM")
(defclass c (foo:a bar:b)
())
Now, this works very nice:
CL-USER 23 > (inspect (make-instance 'boom:c 'foo:bingo 42 'bar:bingo 17))
#<BOOM:C 2065AD14> is a BOOM:C
X 42
Y 17
Something like this, maybe?
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID 0xC66D6E6F
In article <··············@darkstar.cartan>, Nils Goesche <···@cartan.de> wrote:
> > So can you cite an example of how two applications can interfere with each
> > other by using the same symbol purely as a data value?
>
> I don't know if it is what you are looking for, but how about this:
[snipped example where a class in one package multiply-inherits from
classes in two other packages, each of which has an initarg named by a
symbol with the print name "bingo" or something like that]
So this isn't quite what I was looking for. First, it's an example of
things working, not breaking, though I infer that your intention was that
things *would* break if not for packages (which I grant they would).
Second, it feels more like "object oriented programming" than "symbolic
processing", which is where the problems at issue are purported to lie.
And third, it's not really an example of things interfering with each
other; it's an example of things not working together, which is not the
same thing. What I mean when I say that A and B interfere is that both A
and B work fine when they are the only things loaded (or running) but that
one or both breaks when they are both loaded (or running). What's
happening in this case is that a third application, C, is trying to use
facilities from A and B and combine them in a way that the designers of A
and B never intended. It's not clear that this would "work" even if
packages save you from naming conflicts.
I've been re-reading a lot of the posts in this thread, and the following
lines by Kent seem to be key:
> [What's important is s]eparation of data from one application to another.
>
> Modules are about program separation, not data separation.
>
> Data is about identity, nothing more.
>
> This notion of slots is utterly and completely orthogonal to the problem.
So I'm looking for an example where symbolic data is not separated from
one application to another, and that ends up getting you into trouble.
I don't see how sharing *symbols* (as opposed to sharing *bindings*) can
get you into trouble. Symbols considered as data independent of their
bindings are immutable. How can sharing them cause problems?
E.
···@jpl.nasa.gov (Erann Gat) writes:
[... discussion of use of symbols as guide words in make-instance ...]
> Second, it feels more like "object oriented programming" than "symbolic
> processing", which is where the problems at issue are purported to lie.
Because of the co-opting of the term "object oriented programming" to
merely mean the term "implements encapsulation", I often prefer the
term "identity oriented programming" or "identity-centric
programming". Maclisp had no object system (until SFAs, the
conceptual precursor to Flavors) but it was called "object oriented"
because we used to just mean "using the identity of objects to convey
information" + "every datum is an object"). Maclisp would have done
stuff just like this (e.g and did for DEFSTRUCT) and did get into
trouble because no one did good hygiene in Maclisp to partition
world-models. Lisps were assumed to be single-application and used
IPC if they wanted to cooperate with one another.
> And third, it's not really an example of things interfering with each
> other; it's an example of things not working together, which is not the
> same thing. What I mean when I say that A and B interfere is that both A
> and B work fine when they are the only things loaded (or running) but that
> one or both breaks when they are both loaded (or running).
If A and B are componentware and C uses the components, then SURELY
this is an example of them not working. To use a real world analogy
chosen at random, I would re-characterize your remarks something like
"gee, it wasn't a bug in the O-rings. O-rings are just rubber rings.
When you put them into a spaceship, that's a spaceship, not an O-ring
and we're not obliged to test it."
> What's
> happening in this case is that a third application, C, is trying to use
> facilities from A and B and combine them in a way that the designers of A
> and B never intended.
Nonsense. Did you see documentation that they never intended it? Or
is it that you think the early proponents of object-oriented
programming never thought about re-use and just woke up one day to say
"my gosh, all this stuff we've been working on in little components
all these years fits together. isn't that a coincidence?"
> It's not clear that this would "work" even if
> packages save you from naming conflicts.
Give an example.
> I've been re-reading a lot of the posts in this thread, and the following
> lines by Kent seem to be key:
>
> > [What's important is s]eparation of data from one application to another.
> >
> > Modules are about program separation, not data separation.
> >
> > Data is about identity, nothing more.
> >
> > This notion of slots is utterly and completely orthogonal to the problem.
This is quoted out of context. I didn't meant to say that data is never
used by programs. I meant that to understand the issues, you needn't look
to programming constructs to see the issues.
> So I'm looking for an example where symbolic data is not separated from
> one application to another, and that ends up getting you into trouble.
This is a case where copious examples have been offered that show the
theoretical possibility of this yet you are failing to acknowledge that
this is a general effect. I really think you need to just trust people more.
We LIVED the world you are talking about for more than a decade before
INVENTING packages to solve the problem that was commonplace before
inventing it.
It is not likely to be a coincidence that packages first arose on the
Lisp Machine where every "job"/"fork"/"process" (whatever you'd like
to call it) ran in the same address space instead of, as usually the
case in operating systems, in multiple address spaces. So when you
loaded large numbers of AI applications on top of lots of system
facilities like mail and message browsers, file and data editors,
network access programs, etc. you QUICKLY noticed symbol clashes of all
kinds. In the early Lisp machine manuals, you see functions with names
like TV-BEEP that later were separated more formally into TV:BEEP because
it was just too much work to keep all these namespaces separate and because
you couldn't rely on new programs to have been sufficiently written this way.
The most egregious case was Macsyma which had the habit of taking user names
like FOO(x) and turning it to ((%FOO) $X) or (($FOO) $X) internally, where
%FOO meant "noun form" [do not try to apply function, just maintain it as
a call] and $FOO meant verb form [apply the function]. UNFORTUNATELY,
The Lisp Machine internals had chosen %xxx names to mean "this is a low-level
operation that is obscure and you should never try to use if you are not a
wizard because it bypasses the ordinary protocols for type tags, pointers,
etc." It once in a while happened that a clash of these symbols, due to
well-meaning attempts on both implementors' parts to choose "obscure"
symbols (%xxx in both cases) led to people choosing the same "secret name"
and also in this particular case to mysteriouis system crashes because
Macsyma application programmers managed to sometimes clobber system
functionality. Choosing package separation was _MUCH_ safer.
One other example that comes to mind was that in MACLISP
if you store properties on commonly named symbols, it's pretty easy to
bash other programs' data. Someone who didn't know that MACLISP did
(defprop foo (lambda (x) x) expr)
when they did
(defun foo (x) x)
was going to get screwed pretty fast if they just did (putprop 'foo '37 'expr)
and later called a function FOO. This was made even more weird because if
you _only_ ran your program compiled, MACLISP did _not_ do the above
defprop but _instead_ did
(defprop foo #<compiled-subroutine> subr)
The MACLISP operation GETL (called GET-PROPERTIES in CL) was used to get
the first of about a half dozen properties that occurred on the plist
(expr, subr, fexpr, fsubr, lexpr, lsubr, macro [no compiled form--weirder
than that], array, ...) and that value was cached in a way that was very fast
to call a second time [without doing the GETL again]. It could have been
that no one would even notice the data conflict for a long time but if they
ever ran their code interpreted they would. This made the bug very subtle.
But ANY symbol-naming trick is subject to someone choosing the same naming
trick, hence one really can't store any data associated with a symbol if
there's any chance any symbol data coming form an unrelated source will be
attempted as a key in the associative lookup.
I have often said this of the use of keywords in CL: NEVER use a keyword
if the space of other values for the situation the keyword serves is not
finitely enumerable. So, for example, in STANDARD method combination, you
know there is only :before, :after, and :around so that's fine. But you
should not call the method combination by a keyword name :FOO because someone
else might pick that name. If you want to manufacture names, you should do
it in a package, like FOO, so that you can isolate your name choices from
others' name choices until you've had a chance to negotiate proper sharing.
[Think about the way First Contact is carefully managed among alien races
on Star Trek.]
> I don't see how sharing *symbols* (as opposed to sharing *bindings*) can
> get you into trouble.
The short answer to this is that you are trying to substitute knowledge for
experience. You hear, but you do not trust what you hear. You are basically
saying "I have to see it for myself". Now you are talking about the
acquisition of wisdom, and moreover you are saying you do not trust those
who have that experience. I have offered information that I think is adequate
to support my claim. Any number of people on this group have confirmed that
I am not babbling. It is time for you to consider the possibility that you
are simply either not hearing or not doing your homework because there is
just no use repeating this over and over and over.
I left the Dylan group at Harlequin because they did this dialog to me every
damned time I offered any suggestion. They would say "why". I would say
"there are many reasons, but to explain them to the depth of my understanding
will take too long. there are too many decisions to be made in too short a
time and you effectively undo the value of experience if you never trust
experience". Yes, I can explain this. Yes, I can explain the next thing.
But in making me do that explaining, you transfer the cost of learning from
the learner to the teacher. That is not the way of the world. The whole
point of experience, and it is sometimes lost in the cost-free world of
the internet where you don't have to pay for the time you are consuming, is
that it's cheaper for the student to stay up all night thinking about how to
learn something than it is for the teacher to stay up all night trying to
think about how to teach it to one last student when most of the students
are getting it.
One thing that I have learned about "power" in my time on the net is that
the true power (like that of being a sysadmin of a computer, or a wizard on
a moo) is not a free pass to use the power. If anything, people with less
power can use their power more freely. The president of the united states
has the power to wage war, but the frustration is that he can't use that power.
Oddly, or maybe not, the less power you have, the less responsibility you
have not to use it. The same is true of secrets; a secret is in the power of
any holder to tell, but the proper exercise of the power is usually to not
use the power--only a few people are capable of that--anyone would be capable
of doing the "tell the secret" part...
I think this rule must apply as well to "egalitarian power" of being able to
ask a question on a newsgroup. The fact that you can post your question over
and over again does not mean you should. I honestly think you need more
experience writing programs of sufficient magnitude and then trying to link
them to say. If you don't have that experience, then the burden is on you
to either believe those of us who have done this, or to at least put in some
energy to read more carefully and construct some experiments of your own.
People confuse "I can ask this question" with "I should ask this question".
I personally think you are substantially into the "I should not be asking
this question" area and I'm not the only person to have observed it.
It's really time to stop and think, to build experiments (even ones that
take years to set up) or else to start learning to trust.
I would never engage an astrophysicist in this way to have him prove something
to me. I might ask him to peel back a few layers for the fun of conversation,
but at the end of the day, if it was an area I was not trained or experienced
in, I would go away certain in the knowledge that they had knowledge I did
not; I would not go away thinking they had done badly for not giving me
complete knowledge.
I'm not accusing you of being a bad programmer. But it does appear that you
think you've written the kinds of programs that would have turned this kind
of issue up, and I don't think that could really be. The fact that you
assert you've not seen a problem I and others have seen is not a disproof
of that problem.
> Symbols considered as data independent of their
> bindings are immutable. How can sharing them cause problems?
Because symbols' are aggressively sharable and other data is not. If you
start aggressively sharing other objects the denotation of which is not
common, you'll have trouble.
For example, the lisp machine does eqifying of pathnames, but pathnames have
a shared understanding in denotation and have no side-effecting operations,
so this works harmlessly. Some implementations eqify integers or characters
even though EQ doesn't require it (EQL creates the illusion for those who
need it). But one cannot casually do
(defvar *cons-table* (make-hash-table :test 'equal))
(defun my:cons (x y)
(let* ((key nil))
(unwind-protect (progn
(setq key (resourced-cons x y))
(multiple-value-bind (cons consp)
(gethash key *cons-table*)
(if consp
cons
(setf (gethash key *cons-table*)
(cons x y)))))
(if key (return-resourced-cons key)))))
and then just substitute my:cons for cons. There have been Lisps that had
ucons [unique cons] and it has some interesting properties, but it's a much
more complicated game you don't want to get into accidentally because people
use conses for all manner of things. Aggressive substitution of
identity-folded objects for separated objects is not a good thing. You might
write a small application that uses my:cons in certain ways without problem
and so might someone else, but if you put those two together, you may find
problems because you may find now that even though application A thought
it had done a universal quantification of all its uses of a shared cons and
thought it had never stored it into a certain table, the silent annexation
of another class of operations from application B, where they _have_ stored
data into the same table, can cause there to be a property asserted about
application A's data that is not true of application B's data because
application A and application B do not agree on the "meaning" of similarly
shaped conses. Application A might think (A B C) means the disjunction of
situations A, B, and C, while application B thinks (A B C) means the
conjunction of them, and application C might think that (A B C) means to
assume some operation A is applied to B and C. So to assert
(IMPLIES (A B C) D) in application A might mean something _very_ different
than (IMPLIES (A B C) D) in application B. Here, it could be that the
symbols A, B, C, D, and IMPLIES all mean the same thing and that it's the
cons which should not have been uniquified. Again, it's an identity issue.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> > What's
> > happening in this case is that a third application, C, is trying to use
> > facilities from A and B and combine them in a way that the designers of A
> > and B never intended.
>
> Nonsense. Did you see documentation that they never intended it?
I take the fact that they have a name conflict as prima facie evidence
that the designers of A and B never intended A and B to work together in
this way. If they had, they would have talked to each other and worked
out the interface between A and B so that when they were put together in
this way they would work.
Now, I suppose one of the tenets of object oriented programming is that
you should be able to multiply-inherit from two arbitrary classes written
independently and expect the result to Just Work. This claim is the
subject of much controversy among men more learned than myself, and it's
not what I thought we were talking about. I thought we were talking about
something called "symbolic programming" which is a capability that is more
or less unique to Lisp an absent from, say, C++. But this exact same
problem arises in C++ (where they introduced name spaces to solve it).
> > It's not clear that this would "work" even if
> > packages save you from naming conflicts.
>
> Give an example.
In general multiply-inherited classes could conflict through contention
for any global resource, not just identifier names. Here's an example off
the top of my head:
Let's suppose I'm writing a video game, and I have objects representing
entities in the game. I want to do two things with those entities: draw
them on the screen, and render their state to non-volatile storage. So I
inherit from "drawable" and "storable", and discover that suddenly my game
slows down to a glacial pace. Why? Because it turns out that "storable"
does some bookkeeping every time you call (setf slot-value) on a storable
instance, so moving a "drawable, storable" entity around is suddenly much
more expensive than just moving a "drawable" one. In this case the global
resource through which these two classes interact is CPU cycles.
If you want a more dramatic example cast the same scenario into a
real-time control domain, where being too slow can be fatal rather than
just annoying.
> This is a case where copious examples have been offered that show the
> theoretical possibility of this yet you are failing to acknowledge that
> this is a general effect. I really think you need to just trust people more.
The problem is: who to trust? If I trusted other people more and my own
intuitions less, I'd be a C++ programmer.
Actually, the only reason we're even having this long, drawn out
conversation is that I *do* trust you. Your experience and general
mindset are such that I take very seriously anything you say, even when it
conflicts strongly with my own experience and the views of other people
that I also respect.
> We LIVED the world you are talking about for more than a decade before
> INVENTING packages to solve the problem that was commonplace before
> inventing it.
Yes. I know. That's why I take you seriously.
> It is not likely to be a coincidence that packages first arose on the
> Lisp Machine where every "job"/"fork"/"process" (whatever you'd like
> to call it) ran in the same address space instead of, as usually the
> case in operating systems, in multiple address spaces. So when you
> loaded large numbers of AI applications on top of lots of system
> facilities like mail and message browsers, file and data editors,
> network access programs, etc. you QUICKLY noticed symbol clashes of all
> kinds.
Yes, but were those really *symbol* clashes, or were they *binding*
clashes? When the symbol binding is part of the symbol these are the same
thing. When the symbol binding is part of a separate environment object
they are not.
One of the things that puzzles me most about this is that T came after the
Lisp machine. If one of the lessons from the Lisp machine was that
packages are so important, why did T not have them? I always thought that
it was because it had environments instead.
> One other example that comes to mind was that in MACLISP
> if you store properties on commonly named symbols, it's pretty easy to
> bash other programs' data.
Yes, I understand that. But that's got nothing to do with *symbols*, it
has to do with sharing a mutable data structure (the symbol's plist).
You'd have the same problem sharing *any* mutable data structure between
two applications, not just a symbol's plist. You can have exactly the
same problem sharing an array of integers.
[Much condescention snipped]
> The fact that you can post your question over
> and over again does not mean you should.
I keep repeating the question because people appear to answering a
different question from the one I'm asking. It could be I'm not
understanding your answers, but I think it's not inconceivable that some
people aren't understanding the question.
> I'm not accusing you of being a bad programmer.
It's OK if you did. I don't think of myself as a programmer. I sometimes
write programs, but that doesn't make me a programmer.
> But it does appear that you
> think you've written the kinds of programs that would have turned this kind
> of issue up, and I don't think that could really be. The fact that you
> assert you've not seen a problem I and others have seen is not a disproof
> of that problem.
I *have* seen the problems you seem to be describing. They seem to me to
be the result of sharing mutable data structures, not the use of shared
symbols. The fact that in CL symbols have mutable data structures
attached to them directly confuses this issue tremendously.
> > Symbols considered as data independent of their
> > bindings are immutable. How can sharing them cause problems?
>
> Because symbols' are aggressively sharable and other data is not.
Numbers aren't "aggressively sharable"?
> If you
> start aggressively sharing other objects the denotation of which is not
> common, you'll have trouble.
With the exception of the issue dealt with at the start of this post, I
have yet to see an example where this is so that did not additionally
involve the use of a shared mutable data structure. To wit:
[snip]
> ... application A thought
> it had done a universal quantification of all its uses of a shared cons and
> thought it had never stored it into a certain table, the silent annexation
> of another class of operations from application B, where they _have_ stored
> data into the same table,
^^^^^^^^^^^^^^^^^^^
Again, the problem seems to me to be ascribable to sharing a mutable data
structure. If you're not storing uconses into shared data structures and
you aren't calling rplaca or rplacd on uconses I don't see how they get
you into trouble. (In fact, isn't whole FP world pretty much based on the
premise that you can't?)
I'm not saying all this to be argumentative. I'm saying this only to
explain to you why your reasoning hasn't made me go "Aha!" yet.
I certainly understand the problems that arise when symbols have mutable
data structures attached to them (like plists) and the symbols (and hence
the mutable data structures attached to them) are shared. I also
understand how problems arise if you store symbols (or anything else) into
a shared data structure that is not connected with a symbol. And I
understand that packages are a good solution if the task you are faced
with is taking code that already does these things and making it work
together. But my question was specifically written to reject those
premises a priori.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > > What's
> > > happening in this case is that a third application, C, is trying to use
> > > facilities from A and B and combine them in a way that the designers of A
> > > and B never intended.
> >
> > Nonsense. Did you see documentation that they never intended it?
>
> I take the fact that they have a name conflict as prima facie evidence
> that the designers of A and B never intended A and B to work together in
> this way. If they had, they would have talked to each other and worked
> out the interface between A and B so that when they were put together in
> this way they would work.
>
> Now, I suppose one of the tenets of object oriented programming is that
> you should be able to multiply-inherit from two arbitrary classes written
> independently and expect the result to Just Work. This claim is the
> subject of much controversy among men more learned than myself, and it's
> not what I thought we were talking about. I thought we were talking about
> something called "symbolic programming" which is a capability that is more
> or less unique to Lisp an absent from, say, C++. But this exact same
> problem arises in C++ (where they introduced name spaces to solve it).
>
> > > It's not clear that this would "work" even if
> > > packages save you from naming conflicts.
> >
> > Give an example.
>
> In general multiply-inherited classes could conflict through contention
> for any global resource, not just identifier names. Here's an example off
> the top of my head:
>
> Let's suppose I'm writing a video game, and I have objects representing
> entities in the game. I want to do two things with those entities: draw
> them on the screen, and render their state to non-volatile storage. So I
> inherit from "drawable" and "storable", and discover that suddenly my game
> slows down to a glacial pace. Why? Because it turns out that "storable"
> does some bookkeeping every time you call (setf slot-value) on a storable
> instance, so moving a "drawable, storable" entity around is suddenly much
> more expensive than just moving a "drawable" one. In this case the global
> resource through which these two classes interact is CPU cycles.
>
> If you want a more dramatic example cast the same scenario into a
> real-time control domain, where being too slow can be fatal rather than
> just annoying.
To see why this is irrelevant to the discussion, substitute a function
object-value for symbol-value and make the only difference be that the key
used to name a slot is a non-symbol instead of a symbol, but still something
compared by pointer identity. Note that your program runs in exactly the
same amount of time. This is, therefore, not a slowness caused by the use
of symbols, it is caused by an orthogonal set of issues not under discussion.
> > This is a case where copious examples have been offered that show
> > the theoretical possibility of this yet you are failing to
> > acknowledge that this is a general effect. I really think you
> > need to just trust people more.
>
> The problem is: who to trust? If I trusted other people more and my own
> intuitions less, I'd be a C++ programmer.
But if you trusted a C++ programmer even to the degree you apparently
trust me, you'd be having the discussion with him not me. I'm sure there
are many more of them, and that given that sample size, some of them are
bound to be less irritable and probably even less long-winded than me.
> Actually, the only reason we're even having this long, drawn out
> conversation is that I *do* trust you. Your experience and general
> mindset are such that I take very seriously anything you say, even when it
> conflicts strongly with my own experience and the views of other people
> that I also respect.
>
> > We LIVED the world you are talking about for more than a decade before
> > INVENTING packages to solve the problem that was commonplace before
> > inventing it.
>
> Yes. I know. That's why I take you seriously.
>
> > It is not likely to be a coincidence that packages first arose on the
> > Lisp Machine where every "job"/"fork"/"process" (whatever you'd like
> > to call it) ran in the same address space instead of, as usually the
> > case in operating systems, in multiple address spaces. So when you
> > loaded large numbers of AI applications on top of lots of system
> > facilities like mail and message browsers, file and data editors,
> > network access programs, etc. you QUICKLY noticed symbol clashes of all
> > kinds.
>
> Yes, but were those really *symbol* clashes, or were they *binding*
> clashes? When the symbol binding is part of the symbol these are the same
> thing. When the symbol binding is part of a separate environment object
> they are not.
>
> One of the things that puzzles me most about this is that T came after the
> Lisp machine. If one of the lessons from the Lisp machine was that
> packages are so important, why did T not have them? I always thought that
> it was because it had environments instead.
First, you should know that every Tuesday, we had a meeting where we
considered over time replacing literally everything in the language
with "something better". It did not take long to conclude that we
might quickly something that no one would recognize. We were willing
to lose the Lisp community, but not the Scheme community. We were
actually hired out of "hardware budget", not "sofwtare budget", for
teaching Scheme. By bringing up a Scheme implementation on some
machine (can't remember what machine it was even), we were able to
save enough money for the CS department that the cost of developing a
usable language for it could be absorbed. This gave us license to do
something fun, but not something so unrecognizable that our funders
wouldn't want to teach it.
Second, packages were new, and though we knew they solved a known
problem, we didn't at that time have an articulated vocabulary and a
set of experience with large programs. I had only used MACLISP by
this time, not the LispM for anything real. I did not start using
Lisp Machines until I returned to MIT in fall of 1981 after a summer
out at Yale helping prototype T.
Third, and probably most relevant, I haven't said anything in this
discussion about having a single package being "not computationally
feasible". I have said that it isn't symbol-centric. We specifically
built our stuff around either non-symbols or symbol+environment,
exactly because we knew well (even if we wouldn't have articulated it
that way) that unpackaged symbols by themselves were going to be a
disaster modularitywise.
We didn't have it as our charter to make a language that emphasized
symbol processing and I on a number of occasions pondered proposing to
get rid of symbols altogether. It was just not our focus.
Somewhere I have record of at least some of the Tuesday meeting agendas
in a box, and I'd love to get them scanned and put back online as part
of the historical record. The written part wouldn't tell the whole story,
but there must be some interesting stuff in there that would amuse the
software archaeologists of the future.
> > One other example that comes to mind was that in MACLISP
> > if you store properties on commonly named symbols, it's pretty easy to
> > bash other programs' data.
>
> Yes, I understand that. But that's got nothing to do with *symbols*, it
> has to do with sharing a mutable data structure (the symbol's plist).
No, it doesn't. You can make that symbol have no plist, and the problem
will still arise if you use the symbol's identity as a key, as we had
planned to in T when we thought about symbol plists, by doing what might
look vaguely like the following [I've forgotten the T name for some things
so this is just a sketch]:
(define (make-plist-function)
(let ((the-property-lists (make-table)))
(object (lambda (symbol-key)
(table-ref the-property-lists name))
((setter symbol-key val)
((setter table-ref) the-property-lists name val))
((property-list-table)
the-property-lists))))
(define plist (make-plist-function))
That is, OBJECT would do the first lambda when funcalled and return
(LAMBDA (SYMBOL-KEY VAL) ((SETTER TABLE-REF) ...)) from (SETTER PLIST).
The reason you did this and not a simple LET around the define is that
each environment would need its own PLIST function because otherwise
one applications properties would trip over another application's.
On the other hand, in CL, I can do:
(application-a:misc-subroutine 'application-b:marker)
and use application-a's GET or GETF to look up the marker on the plist of
some third object. In T, as described above, I'd have had to do:
((reference 'misc-subroutine application-b)
'marker
((reference 'property-list-table 'application-a)))
because what application A and application B mean by "the property list"
is different, and one cannot access another's because GET only takes a
symbol and not a module environment!
> You'd have the same problem sharing *any* mutable data structure between
> two applications, not just a symbol's plist. You can have exactly the
> same problem sharing an array of integers.
Already addressed under separate cover.
> [Much condescention snipped]
>
> > The fact that you can post your question over
> > and over again does not mean you should.
>
> I keep repeating the question because people appear to answering a
> different question from the one I'm asking. It could be I'm not
> understanding your answers, but I think it's not inconceivable that some
> people aren't understanding the question.
>
> > I'm not accusing you of being a bad programmer.
>
> It's OK if you did. I don't think of myself as a programmer. I sometimes
> write programs, but that doesn't make me a programmer.
>
> > But it does appear that you
> > think you've written the kinds of programs that would have turned this kind
> > of issue up, and I don't think that could really be. The fact that you
> > assert you've not seen a problem I and others have seen is not a disproof
> > of that problem.
>
> I *have* seen the problems you seem to be describing. They seem to me to
> be the result of sharing mutable data structures, not the use of shared
> symbols. The fact that in CL symbols have mutable data structures
> attached to them directly confuses this issue tremendously.
>
> > > Symbols considered as data independent of their
> > > bindings are immutable. How can sharing them cause problems?
> >
> > Because symbols' are aggressively sharable and other data is not.
>
> Numbers aren't "aggressively sharable"?
One does not use EQ on numbers.
Nor does one use numbers for identity-related things as often as one uses
symbols. If one did, it would have the same set of issues.
See my earlier post from today for a worked example. The example I alluded
to in that which Drew McDermott used was an unrelated use, but with similar
issues. He needed gensymed integers, too. I think he was using them as
substitutes for a bit-vector datatype, but you can't be rplacd'ing shared
integers, as the FORTRAN programmers found out when they started assigning
call-by-reference parameters that had been supplied as PI from some common
data area. ;) In PL/1, people learned to write (PI) so that it became a
computation and not a variable reference. Heh...
> > If you
> > start aggressively sharing other objects the denotation of which is not
> > common, you'll have trouble.
>
> With the exception of the issue dealt with at the start of this post, I
> have yet to see an example where this is so that did not additionally
> involve the use of a shared mutable data structure. To wit:
>
> [snip]
>
> > ... application A thought
> > it had done a universal quantification of all its uses of a shared cons and
> > thought it had never stored it into a certain table, the silent annexation
> > of another class of operations from application B, where they _have_ stored
> > data into the same table,
> ^^^^^^^^^^^^^^^^^^^
>
> Again, the problem seems to me to be ascribable to sharing a mutable data
> structure. If you're not storing uconses into shared data structures and
> you aren't calling rplaca or rplacd on uconses I don't see how they get
> you into trouble. (In fact, isn't whole FP world pretty much based on the
> premise that you can't?)
>
> I'm not saying all this to be argumentative. I'm saying this only to
> explain to you why your reasoning hasn't made me go "Aha!" yet.
>
> I certainly understand the problems that arise when symbols have mutable
> data structures attached to them (like plists) and the symbols (and hence
> the mutable data structures attached to them) are shared. I also
> understand how problems arise if you store symbols (or anything else) into
> a shared data structure that is not connected with a symbol. And I
> understand that packages are a good solution if the task you are faced
> with is taking code that already does these things and making it work
> together. But my question was specifically written to reject those
> premises a priori.
Again, this is addressed in my other post.
The essence is that all of the cases you raise seem to assume you can tell
by virtue of the incoming dataflow what type something is. That is, that
you wouldn't have called (old-p sym) on something that wasn't participating
in your old-p metaphor. And you dismiss composed, heterogeneous data
structures where TYPEP will be called to substitute for an intentional type.
But that is exactly and only the set of things where you will see the issue,
so it will elude you forever as long as you continue to disregard opaque
data pathways. You are thinking like a Java programmer, that your caller
will always provide the type clues you need. The set of problems you want
to use as data are all C++/Java-compatible, and so you don't get any of the
value that Lisp offers you, and then you wonder why you don't get any of
the problems that come with that power.
If that's all you're using of Lisp, it is little wonder that you have
found other languages you like better than Lisp. This really tells me
a lot about your recent advice that Python is "just as good". It may
well be for certain classes problems, and I don't doubt you are
getting value. But I am forced to conclude that you don't even do the
same things with the language that I do, and so a recommendation of
"just as goodness" comes to me like a recommendation about a romance
novel that is "just as good" as that "mystery book" I'm reading, which
I now understand to be based on the fact that we both liked a mystery
book sometime in the past where there was a romance going on....
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> This really tells me
> a lot about your recent advice that Python is "just as good".
I never said that. I said I preferred it for one very narrow class of
application: small-scale Web programming.
E.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> > > > It's not clear that this would "work" even if
> > > > packages save you from naming conflicts.
> > >
> > > Give an example.
> >
> > In general multiply-inherited classes could conflict through contention
> > for any global resource, not just identifier names. Here's an example off
> > the top of my head:
> >
> > Let's suppose I'm writing a video game, and I have objects representing
> > entities in the game. I want to do two things with those entities: draw
> > them on the screen, and render their state to non-volatile storage. So I
> > inherit from "drawable" and "storable", and discover that suddenly my game
> > slows down to a glacial pace. Why? Because it turns out that "storable"
> > does some bookkeeping every time you call (setf slot-value) on a storable
> > instance, so moving a "drawable, storable" entity around is suddenly much
> > more expensive than just moving a "drawable" one. In this case the global
> > resource through which these two classes interact is CPU cycles.
> >
> > If you want a more dramatic example cast the same scenario into a
> > real-time control domain, where being too slow can be fatal rather than
> > just annoying.
>
> To see why this is irrelevant to the discussion, substitute a function
> object-value for symbol-value and make the only difference be that the key
> used to name a slot is a non-symbol instead of a symbol, but still something
> compared by pointer identity. Note that your program runs in exactly the
> same amount of time. This is, therefore, not a slowness caused by the use
> of symbols, it is caused by an orthogonal set of issues not under discussion.
Yes, that was in fact exactly the point I was trying to make. Multiple
inheritance can break for many reasons, some related to symbols, some not.
> > The problem is: who to trust? If I trusted other people more and my own
> > intuitions less, I'd be a C++ programmer.
>
> But if you trusted a C++ programmer even to the degree you apparently
> trust me, you'd be having the discussion with him not me.
In point of fact I have had similar discussions with C++ programmers and
learned a lot as a result.
I feel I've already learned a lot as a result of this discussion, and I
think I'm beginning to understand. (The reason I'm asking all these
questions is that I'm working on a little Lisp system written in C++ so I
can write Lisp code but say I'm writing C++ code. I am now seriously
considering adding packages where before I was looking forward to getting
rid of them.)
[Much snippage]
> The essence is that all of the cases you raise seem to assume you can tell
> by virtue of the incoming dataflow what type something is. That is, that
> you wouldn't have called (old-p sym) on something that wasn't participating
> in your old-p metaphor. And you dismiss composed, heterogeneous data
> structures where TYPEP will be called to substitute for an intentional type.
I think you may be confusing me with someone else. That doesn't sound
like anything I can remember saying. (I'm not even sure I understand what
you mean.)
> But that is exactly and only the set of things where you will see the issue,
> so it will elude you forever as long as you continue to disregard opaque
> data pathways. You are thinking like a Java programmer, that your caller
> will always provide the type clues you need. The set of problems you want
> to use as data are all C++/Java-compatible, and so you don't get any of the
> value that Lisp offers you, and then you wonder why you don't get any of
> the problems that come with that power.
That is entirely possible. Despite the fact that I've been happily
programming in Lisp for twenty years, that I have a Ph.D. in computer
science with a specialization in AI, it may be that I have never written
any significant code that did symbolic processing. (And I'm not being
facetious.) I feel I've gotten a lot of value out of the language
nonetheless.
> If that's all you're using of Lisp, it is little wonder that you have
> found other languages you like better than Lisp. This really tells me
> a lot about your recent advice that Python is "just as good".
I never gave any "advice" about Python. I never said it was "just as
good". I did say it was now my language of choice for Web programming,
but that doesn't involve much symbolic computation even by my
understanding of the term.
Geez. The C++ people think I'm a Lisp fanatic. The Lisp people think I'm
a Python fanatic. The python people just think I'm nuts. You can't all
be right!
E.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> By bringing up a Scheme implementation on some
>machine (can't remember what machine it was even), we were able to
>save enough money for the CS department that the cost of developing a
>usable language for it could be absorbed. This gave us license to do
>something fun, but not something so unrecognizable that our funders
>wouldn't want to teach it.
Apollo's, no?
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@darkstar.cartan>, Nils Goesche <···@cartan.de> wrote:
>
> > > So can you cite an example of how two applications can interfere with each
> > > other by using the same symbol purely as a data value?
> >
> > I don't know if it is what you are looking for, but how about this:
>
> [snipped example where a class in one package multiply-inherits from
> classes in two other packages, each of which has an initarg named by a
> symbol with the print name "bingo" or something like that]
>
> So this isn't quite what I was looking for.
Hm, I think it is. I don't know why, but you keep asking for
examples and reject every given example at the same time. I can
understand that you are not willing to accept examples offered by
lowly non-VIPs like myself, but please note then that it was Kent
who mentioned the initarg issue for the first time in this
thread, if this makes you more willing to think about it.
> First, it's an example of things working, not breaking, though
> I infer that your intention was that things *would* break if
> not for packages (which I grant they would).
As these notions are clearly dual, I assumed that I didn't have
to mention this explicitly.
> Second, it feels more like "object oriented programming" than
> "symbolic processing", which is where the problems at issue are
> purported to lie.
Sorry, but this is bogus. The only reason I chose CLOS was to
make the example look more practical. Please try to abstract
from the concrete nature of the problem that is solved by the
package system here, and I think you will see the /real/
issue.
> And third, it's not really an example of things interfering
> with each other; it's an example of things not working
> together, which is not the same thing.
Sorry, I fail to see the difference here.
> What I mean when I say that A and B interfere is that both A
> and B work fine when they are the only things loaded (or
> running) but that one or both breaks when they are both loaded
> (or running).
> What's happening in this case is that a third application, C,
> is trying to use facilities from A and B and combine them in a
> way that the designers of A and B never intended.
Where do you know that? Why did I load both programs in the
first place? I wanted to use them both at the same time, how
could I do that better than deriving a class from both of them?
There is /nothing/ wrong with that, no matter whether the
designers had intended that or not, it should work.
> It's not clear that this would "work" even if packages save you
> from naming conflicts.
It's me who decides whether that could work or not. /I/ know the
interfaces, /I/ know if they could be successfully combined. And
I am grateful if I can do that without name clashes.
Oh well, I don't know. These issues are pretty deep, and maybe
everyone gets something else out of them :-)
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID 0xC66D6E6F
In article <··············@darkstar.cartan>, Nils Goesche <···@cartan.de> wrote:
> Hm, I think it is. I don't know why, but you keep asking for
> examples and reject every given example at the same time. I can
> understand that you are not willing to accept examples offered by
> lowly non-VIPs like myself, but please note then that it was Kent
> who mentioned the initarg issue for the first time in this
> thread, if this makes you more willing to think about it.
It's got nothing to do with who poses the example.
> > It's not clear that this would "work" even if packages save you
> > from naming conflicts.
>
> It's me who decides whether that could work or not. /I/ know the
> interfaces, /I/ know if they could be successfully combined. And
> I am grateful if I can do that without name clashes.
What are we assuming about who wrote A and B? Did you write them? If you
did, then I'd say you just wrote them badly. Were they written by two
different people who didn't communicate? Then I'd say you have no
reasonable expectation that you can combine them. Maybe you can, but it's
a matter of luck.
As I noted in a separate response to Ken's recent post, what comprises
"reasonable expectations" in the face of multiple inheritance of
independently-developed classes is the subject of much debate that I don't
want to get into here. My only point is that name clashes are not the
only way that this can fail to work.
E.
In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
> In article <··············@darkstar.cartan>, Nils Goesche <···@cartan.de> wrote:
>
>> It's me who decides whether that could work or not. /I/ know the
>> interfaces, /I/ know if they could be successfully combined. And
>> I am grateful if I can do that without name clashes.
>
> What are we assuming about who wrote A and B? Did you write them? If you
> did, then I'd say you just wrote them badly.
Sure, if had written A and B, I'd just change them. Or maybe not,
because I don't have to (I might have written A two years ago and B
one year ago).
> Were they written by two
> different people who didn't communicate? Then I'd say you have no
> reasonable expectation that you can combine them. Maybe you can, but it's
> a matter of luck.
This I don't understand. I do that all the time. I take this library
and that library and put them together; nobody has probably done
this before with those two libraries, but so what. Maybe they do
totally different things. This usually works just fine.
> As I noted in a separate response to Ken's recent post, what comprises
> "reasonable expectations" in the face of multiple inheritance of
> independently-developed classes is the subject of much debate that I don't
> want to get into here. My only point is that name clashes are not the
> only way that this can fail to work.
Everything can fail in a million ways. It isn't so much about
inheritance, either. The essential point is that a symbol, not
a symbol's value, is used to trigger some action here. It is
essential that I have two different objects, initarg symbols, I can pass
around to both A and B without confusing them. I couldn't do that if
I had no package system and the symbol FOO would always be the same
object.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
[this is a repost, as the original didn't seem to make it out.]
···@jpl.nasa.gov (Erann Gat) writes:
> So can you cite an example of how two applications can interfere with
> each other by using the same symbol purely as a data value?
Erann,
I'm just as curious as you as to what Rahul (or Erik or Kent) might
say to this question, but I thought that by trying to pose the
situation you ask for above, I might learn something additional about
Lisp from you (or them).
In this case, I believe what matters in the existence of the symbol
and it's identity. When I use the reader, I have it generate the
symbol 'EOF when it reaches the end of the file (rather than
signaling an exception.) Before I process the result of the read, I
check it for identity against the symbol 'EOF. [This is probably an
example of how to write C/Perl code in Lisp, since I'm a
newbie... style pointers from anyone are welcome...]
That's a pretty trivial example of purely symbolic processing, but
what if I had two different packages (one for working with network
streams and one for working with file streams), each of which returned
a function that read from the appropriate type of stream. Further
suppose that my code dispatches to one of the two packages depending
on a structured naming scheme (like URIs). What I get back is a
function that reads from either a socket or a file, but I don't know
which!
Now, I may want to treat the two differently, so it'd be nice to
have them return unique symbols so that if I get 'EOF from a socket I
can attempt to re-initiate the connection, while if I get 'EOF from a
file I can just clean up and go about my business. But unless I have
packages, I have to write my code so that they generate either
'SOCKET-EOF or 'FILE-EOF instead of just plain old 'EOF. Integrating
this code with code from other people could also cause obvious
name space collision problems.
Packages are nice [to me] because I can check for either
'SOCKET::EOF or 'FILE::EOF when I have to, but just get by with 'EOF
otherwise.
Does that make sense? Am I doing something hopelessly naive?
-jon
--
------------------
Jon Allen Boone
········@delamancha.org
Jon Allen Boone <········@delamancha.org> writes:
> In this case, I believe what matters in the existence of the symbol
> and it's identity. When I use the reader, I have it generate the
> symbol 'EOF when it reaches the end of the file (rather than
> signaling an exception.) Before I process the result of the read, I
> check it for identity against the symbol 'EOF. [This is probably an
> example of how to write C/Perl code in Lisp, since I'm a
> newbie... style pointers from anyone are welcome...]
A Lisp solution is one that works well in Lisp. If you're using READ,
then using a symbol for an EOF indicator probably isn't the smartest
thing to do, since that's a valid element of the input (unless maybe
you want to allow the user to explicitly force the EOF). The usual
idiom is to have the stream itself as the eof-value or let the error
be signaled and use the condition system's facilities (which also
allow the error to be handled ``non-locally'').
> That's a pretty trivial example of purely symbolic processing, but
> what if I had two different packages (one for working with network
> streams and one for working with file streams), each of which returned
> a function that read from the appropriate type of stream. Further
> suppose that my code dispatches to one of the two packages depending
> on a structured naming scheme (like URIs). What I get back is a
> function that reads from either a socket or a file, but I don't know
> which!
I would use CLOS and generic-functions here, personally. What would be
more ``symbolic processing'' is having the naming scheme be composed
of some data structure of symbolic identifiers, and then having those
identifiers map to name-manipulation functions, maybe.
> Now, I may want to treat the two differently, so it'd be nice to
> have them return unique symbols so that if I get 'EOF from a socket I
> can attempt to re-initiate the connection, while if I get 'EOF from a
> file I can just clean up and go about my business. But unless I have
> packages, I have to write my code so that they generate either
> 'SOCKET-EOF or 'FILE-EOF instead of just plain old 'EOF. Integrating
> this code with code from other people could also cause obvious
> name space collision problems.
> Packages are nice [to me] because I can check for either
> 'SOCKET::EOF or 'FILE::EOF when I have to, but just get by with 'EOF
> otherwise.
Yes, that's one of the nice features of packages. You can depend on
the default context when it's what you want and specify one explicitly
when interacting among systems.
> Does that make sense? Am I doing something hopelessly naive?
I don't know if I'd implement it that way, since there seems to be too
much room for confusion. Maybe using the condition system and having
separate subclasses of eof-error for each of the situations would be
more flexible. Then you can also do stuff with restarts, handlers,
etc.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
In article <··············@photino.sid.rice.edu>, Rahul Jain wrote:
> A Lisp solution is one that works well in Lisp. If you're using READ,
> then using a symbol for an EOF indicator probably isn't the smartest
> thing to do, since that's a valid element of the input (unless maybe
> you want to allow the user to explicitly force the EOF). The usual
> idiom is to have the stream itself as the eof-value or let the error
> be signaled and use the condition system's facilities (which also
> allow the error to be handled ``non-locally'').
I know an assembler, for ARM Assembler, running on Windows, that
does actually /crash/ (as in ``dump core''), /unless/ you put the
word
END
at the end of the file. IIRC, there is no corresponding BEGIN keyword,
but it needed END just before end of file, or would crash. I couldn't
believe my eyes.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Nils Goesche <······@cartan.de> writes:
> I know an assembler, for ARM Assembler, running on Windows, that
^^^^^^^^^
ITYM "Assembly".
--
vsync
http://quadium.net/
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))
"vsync" <·····@quadium.net> wrote in message
···················@prion.quadium.net...
> Nils Goesche <······@cartan.de> writes:
>
> > I know an assembler, for ARM Assembler, running on Windows, that
> ^^^^^^^^^
>
> ITYM "Assembly".
>
Probably not. See, for example, http://www.heyrick.co.uk/assembler/ .
> --
> vsync
> http://quadium.net/
> (cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
> (cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))
Lisp. No wonder.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> > Packages are nice [to me] because I can check for either
> > 'SOCKET::EOF or 'FILE::EOF when I have to, but just get by with 'EOF
> > otherwise.
>
> Yes, that's one of the nice features of packages. You can depend on
> the default context when it's what you want and specify one explicitly
> when interacting among systems.
For varying values of "depend". I would say you can use this if the data
you are reading is "friendly" (that is, if the ill effects of seing an
eof where there oughtn't be one is taken on by the person who caused the
problem) and you should _not_ use this technique if the data is "hostile"
(that is, the consequences of reading only to this point is that you fail
to notice other stuff piggy-backing in that would cause you, not your
client, some problem). Because the package system allows someone to put
FILE::EOF in the file, you don't want a hostile programmer doing this in
order to fake you out.
Kent M Pitman <······@world.std.com> writes:
> Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
>
> > > Packages are nice [to me] because I can check for either
> > > 'SOCKET::EOF or 'FILE::EOF when I have to, but just get by with 'EOF
> > > otherwise.
> >
> > Yes, that's one of the nice features of packages. You can depend on
> > the default context when it's what you want and specify one explicitly
> > when interacting among systems.
>
> For varying values of "depend". I would say you can use this if the data
> you are reading is "friendly"
Yeah, that's a good point.
I wasn't actually referring to the reading operation returning the
eof-value from the input (I addressed that earlier); I was referring
more to the ability to rely on *package* when you have a simple
situation, and then the ability to use package prefixes to deal with
the more complex ones.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Drew McDermott <··············@yale.edu> writes:
> One would have to be nuts to get involved in this packages
> discussion, so my sanity must be wobblier than I thought.
Once upon a time there was a kingdom where the villagers drank from one
well and the King drank from another. Poison infectd the well and all
the villagers went crazy, but the King did not. The villagers petitioned
the King for a long time to come drink from their well, and finally he
relented, becoming like the rest of them. And the villagers rejoiced that
their King had regained his sanity.
[There turn out to be some technical flaws in this story, but I like
it anyway... and it seemed apropos.]
> ... I have learned to cope with the package system, but there are
> times when it does exactly the wrong thing. Suppose I have written
> two programs, 'wordhack' and 'letterhack'. I encapsulate them in
> packages as recommended, but as it happens I don't plan to use them
> together. ...
Yes, I'm familiar with this scenario. In defense of CL, I can say
only that if you build an application that is not intended to operate
on a private namespace, you should be using the keyword package.
There are important reasons _to_ use the keyword package, not just
important reasons not to, and arguably this is one.
I also think the keyword package needs a better relationship to the
other symbols and I have in my mind arrived at what I think would be a
superior design that I'm sad we didn't come up with: I think we should
have said that keywords were a simpler kind of symbol (with no
function or value, since they are shared and it's a trap to allow the
option). They would be implementationally little more than Java's
"canonical strings". Then every symbol would have as its print name a
keyword (which metaphorically you could think of as a link to an
unpackaged symbol or to a generic name instead of a specialized name).
It would also mean there would never be overhead computationally to go
from symbols to keyword, where now it means conjuring a ton of junk in
another package. I've always thought it a design error that keywords
were the same datatype as symbols, and in fact I got people to agree
orally in the CLTL original design meetings that we would revisit this
on a later pass, but record of that was lost, and the committee
disbanded in favor of ANSI so that plan was lost. Pity.
On the basis of this discussion, I'm thinking harder about providing
better programmer guidelines about when to use keywords and when not.
I'm even thinking I will change my global programming style to not use
:xxx as init args for defclass because I have always known it to be
shortsighted and just asking for trouble, and many of the examples
I've made in this discussion are full of places that will screw up.
> Now several months later I write a third program that uses both
> packages, and I suddenly discover that there is a name conflict
> between 'wh:a' and 'lh:a'. I don't use the property list, value
> cell, or function cell of either symbol, so what I'd really like to
> say is, "Treat these as the same symbol; they will never occur in
> the same context, so there will never be any ambiguity about which
> is meant." Obviously, this example is contrived, but this sort of
> thing has happened to me more than once.
I think you should have written this with keywords to start with. Not
doing that was effectively saying "it's importnat to allow for this case"
and you are fulfilling that reservation, if you get my drift.
> Another example is where package 1 defines a macro that uses various
> symbols as "local syntax" markers (such as 'for', 'in', when',
> etc. in '(loop for thing in things when (get thing 'color) collect
> thing))), and package 2 defines another macro that happens to use
> 'for' and 'collect' as local syntax markers. Now I write a program
> that uses both packages. There seems to be no reason in the world
> to have to write
>
> (loop pkg1:for thing in things
> when (get thing 'color)
> pkg1:collect thing)
>
> and
>
> (wait pkg2:for (event e ...)
> then pkg2:collect e)
>
> but that's what I have to do.
Loop makes the decision that these are compared by name rather than by
identity. In effect, they are symbols acting as string designators.
It might be even clearer if strings were allowed, so we could just say
they are string designators, but something about symbolness makes
people feel more like they are program glue... Not sure if that's
principled or just a queasiness caused by never having seen
counterexamples.
> For these and other reasons, over the years my Common Lisp style has
> evolved away from being "symbol-dependent."
I might say that you have learned when symbols work and when they do not.
I would just say that like any datatype they are not a panacea.
The same truth was learned about lists over time, but no one thinks
we have abandoned lists. We've just learned when to use them and when not.
I use a lot fewer calls to cadr, caddr, etc. in my code, but it doesn't
mean I use lists only lightly... I have formalized my use. And, incidentally,
I follow the rule of never using any C....R functions other than CAAR (because
it is idiomatic in alists) and CAD*R. The functions like CDAR or CDDADR I
do not use. Again, not so much an abandonment of conses as
what I like to think of as a more sophisticated sense of style in using them.
Any time I see D's separated by A's, I know there is likely to be a punning
of two abstractions, and I usually prefer (CDDR (CADR ...)) since usually
I mean "the second tail of the second element".
> Whenever possible, I
> make sure my macros use local syntax markers from the keyword
> package only. I always use tables instead of property lists. I
> often define variant symbol types that print something like symbols,
> and when appropriate read something like symbols, but differ from
> symbols in various ways (such as not being interned until after the
> first time they are printed).
I don't use these rules specifically, but I make rules for myself for the
same reasons as I see you making rules here.
> However, symbols are a wonderful thing.
I expected you to say this but didn't want to put words in your mouth.
I almost replied to the previous letter saying it was time for me to
ask you to write a compensating paper defending my positin, since I
imagined you were of two minds on this and capable of doing both roles.
> Note that the whole reason
> symbols and packages come up as an issue in the Scheme-Lisp world,
> and not in the Haskell-ML world is that the language uses the same
> reader that user code uses. That makes macros possible, but it also
> raises all these complications about binding time. On balance I
> think I would prefer a module system to the package system, but it's
> not a strong preference.
I'd be interested to see a module system. I have never felt that the two
are in conflict, any more than early binding and late binding are in
conflict. I like choice.
> And now apparently I have to tack on some verbiage about how I love
> "symbol-processing languages," and I despise Scheme (which, believe
> it or not, I do, pretty much), and I'm competent to talk about all
> this because I once coauthored a book on Lisp programming.
I think one doesn't have to be a book author to have a competent opinion.
And I know some book authors (I won't say if they are Lisp book authors)
who make me question whether authorship is a credential for having an
opinion. But that's ok. I'm not challenging your credential either
way. I'm always happy when you chime in.
> Really, the tone on this newsgroup often sounds like a meeting of a
> Communist Party cell circa 1935, with the main item on the agenda
> being how to detect the Trotskyites among us.
Heh. Yes, it's being quite a party.
Though I'm surprised you didn't suggest it was ... uh, ... an exercise
in ... dare I say it? ... McCarthyism?
Kent M Pitman <······@world.std.com> writes:
> On the basis of this discussion, I'm thinking harder about providing
> better programmer guidelines about when to use keywords and when not.
> I'm even thinking I will change my global programming style to not use
> :xxx as init args for defclass because I have always known it to be
> shortsighted and just asking for trouble, and many of the examples
> I've made in this discussion are full of places that will screw up.
This exact issue has been bothering me repeatedly as I've been
developing the class heirarchy of DefDoc. Good to see there's someone
who has been thinking the same thing. :)
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
* Drew McDermott
| I don't use the property list, value cell, or function cell of either
| symbol, so what I'd really like to say is, "Treat these as the same
| symbol; they will never occur in the same context, so there will never be
| any ambiguity about which is meant." Obviously, this example is
| contrived, but this sort of thing has happened to me more than once.
So use import.
| There seems to be no reason in the world to have to write
|
| (loop pkg1:for thing in things
| when (get thing 'color)
| pkg1:collect thing)
|
| and
|
| (wait pkg2:for (event e ...)
| then pkg2:collect e)
|
| but that's what I have to do.
I cannot fathom how you can do something that produces a problem and
think that it is somebody else's fault that it does.
Please note that loop does _not_ use symbols for identity, it uses
symbols for names. for, in, when, collect, etc, are compared by
symbol-name, not eq.
| (In the actual example above, 'for' and 'collect' happen to be in the
| "CL" package, so the problem, by happenstance, wouldn't arise; I just
| chose 'loop' so I could use a familiar macro.)
Wrong. for and collect are most definitely _not_ in the common-lisp
package. This is so goddamn easy to check. Why did you just go on your
assumption?
| For these and other reasons, over the years my Common Lisp style has
| evolved away from being "symbol-dependent." Whenever possible, I make
| sure my macros use local syntax markers from the keyword package only. I
| always use tables instead of property lists. I often define variant
| symbol types that print something like symbols, and when appropriate read
| something like symbols, but differ from symbols in various ways (such as
| not being interned until after the first time they are printed).
It appears you have based most of this on a subtle confusion.
It is becoming increasingly clear to me how damaging it is to learn
Scheme first for a (future) Common Lisp programmer. There are so many
subtle differences that are unable to produce strong enough hints to a
Scheme programmer that he continues to believe the Scheme mindset. A
Common Lisp programmer will, on the other hand, get strong enough hints
that Scheme is different that he cannot use his Common Lisp mindset in
Scheme. This leads Scheme people to believe that Common Lisp is just
like Scheme, and Common Lisp people to _know_ that Scheme is a very
different language. Moreover, Scheme people do not understand what the
Common Lisp people are talking about until they have actually experienced
the differences, and most of them write Scheme in Common Lisp, anyway, so
they never do. Trying to write Common Lisp in Scheme fails miserably.
| On balance I think I would prefer a module system to the package system,
| but it's not a strong preference.
But they are orthogonal features! Please try to understand this.
| And now apparently I have to tack on some verbiage about how I love
| "symbol-processing languages," and I despise Scheme (which, believe it or
| not, I do, pretty much), and I'm competent to talk about all this because
| I once coauthored a book on Lisp programming. Really, the tone on this
| newsgroup often sounds like a meeting of a Communist Party cell circa
| 1935, with the main item on the agenda being how to detect the
| Trotskyites among us.
Well, gee, you sure help on the attitude. A newsgroup is what you make
it. If you believe you can be a critical outsider _and_ post to the
newsgroup you criticize without becoming part of it, you are seriously
deluded. Lots of people somehow think that there is a "they" concept of
which they are not a part and that it is useful to distinguish between
"they" and the critic. This is a _fantastically_ ludicrous position to
take. If you post, you are by definition part of the forum, and if you
post another hostile message, you are by definition part of problem.
This _stupid_ attitude that you can somehow walk into a forum and shout
that other people should not shout without actually shouting, yourself,
is such a tremendous barrier to peace and progress. If you have to make
some remark about other people's "tone" in a hostile tone of your own, at
least have the honesty and presence of mind to accept responsibility for
making the situation worse, and by implication _preferring_ the hostile
tone instead of trying to calm it down. As an aside: meta-comments like
that are always hostile because they by their very nature sets up a
distinction between the poster and everybody else, the poster somehow
being in the moral clear while everybody else is at fault. Hypocrisy is
not a feature of civil discussions.
Please realize that your emotional response has led you astray: It is not
a requirement to say that Scheme sucks, it is generally just a whole lot
smarter _not_ to say that Common Lisp sucks. This is not a hate group
for Scheme just because Scheme lovers who also keep denigrating Common
Lisp are asked to leave. That is such a bogus causality chain that there
can be very little credibility in other things you have concluded with
the same intellectual sloppiness. Then again, this is precisely the lack
of observational skills that cause people to believe Common Lisp and
Scheme are so much alike: they stop looking _completely_ when they are
satisfied that they have seen "enough", and then they only talk as if the
world would never have invalidated whatever they were satisfied seeing if
they had continued to look. This is not a good way to cope with a world
in constant flux, and even a world you continously see more of is better
with your eyes open.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > Being one of the central parties making this noise, I'll do something I'm
> > not big on and actually cite my credentials to show that I am not blathering
> > out of ignorance:
>
> I won't follow your example because I don't know if I'm blathering out of
> ignorance or not. (That's what I'm trying to figure out.) But if you
> want to see my credentials my CV is on the Web. Suffice it to say I've
> built a successful career in part by writing Common Lisp code. I feel
> fairly confident that I'm sufficiently non-idiotic that if someone can't
> explain something in this area so that I can understand it there's a good
> chance that it's their fault and not mine.
No. I've also gone through some email exchange with you, and in my
opinion it is mainly your problem and you should really use more time
to understand what others are writing.
Your CV looks impressive, but after having this conversation with you
and reading so much about your problems on c.l.l., I do not believe
anymore that it tells the truth. Maybe some other person on this list
knowing you personally could confirm it?
Nicolas.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@192.168.1.50...
>
> Through the years I have always found the package system to be pretty
> annoying. I often find myself doing the following:
>
> > foo
> ERROR: foo is unbound ; Doh! Forgot that foo is in foo-package
> > (use-package 'foo-package)
> ERROR: symbol FOO-PACKAGE:FOO conflicts with symbol FOO ; Arrggh!!!
>
>
> So I've always considered packages as more of a necessary evil than a
> feature.
Since everyone else is weighing on this I might as well offer my uninformed
opinion.
In the years I have been hacking lisp, I have on many occasions cursed
the package system, mainly for making me restart my lisp to undo whatever
random damage happened when I read something in the wrong package.
On the other hand, I have *never once* had the occasion to say
`Wow, damn glad that package system saved my ass on *this*!'
"Joe Marshall" <·············@attbi.com> writes:
> "Erann Gat" <···@jpl.nasa.gov> wrote in message
> ·························@192.168.1.50...
> >
> > Through the years I have always found the package system to be pretty
> > annoying. I often find myself doing the following:
> >
> > > foo
> > ERROR: foo is unbound ; Doh! Forgot that foo is in foo-package
> > > (use-package 'foo-package)
> > ERROR: symbol FOO-PACKAGE:FOO conflicts with symbol FOO ; Arrggh!!!
> >
> >
> > So I've always considered packages as more of a necessary evil than a
> > feature.
>
> Since everyone else is weighing on this I might as well offer my uninformed
> opinion.
>
> In the years I have been hacking lisp, I have on many occasions cursed
> the package system, mainly for making me restart my lisp to undo whatever
> random damage happened when I read something in the wrong package.
> On the other hand, I have *never once* had the occasion to say
> `Wow, damn glad that package system saved my ass on *this*!'
It is hard to tell if you are serious on this but do you actually
mean that? Are you aware of the fact that it might be a benefit
of the package system that you had no reason so far to complain
when you used different packages from different parties for your
own projects? Or is the above in fact an example of very fine
irony which wanted to say this very thing? In that case I feel
very embarrassed for bothering you...
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID 0xC66D6E6F
"Nils Goesche" <···@cartan.de> wrote in message
···················@darkstar.cartan...
> "Joe Marshall" <·············@attbi.com> writes:
> >
> > In the years I have been hacking lisp, I have on many occasions cursed
> > the package system, mainly for making me restart my lisp to undo
whatever
> > random damage happened when I read something in the wrong package.
> > On the other hand, I have *never once* had the occasion to say
> > `Wow, damn glad that package system saved my ass on *this*!'
>
> It is hard to tell if you are serious on this but do you actually
> mean that?
Yes, in this case I am not being facetious.
> Are you aware of the fact that it might be a benefit
> of the package system that you had no reason so far to complain
> when you used different packages from different parties for your
> own projects?
Obviously there is a need for *some* mechanism to allow people
to develop code independently without them having to worry
about what names other people might want to use in their code.
However, I think the package system is the wrong way to go about
this.
* "Joe Marshall" <·············@attbi.com>
| In the years I have been hacking lisp, I have on many occasions cursed
| the package system, mainly for making me restart my lisp to undo whatever
| random damage happened when I read something in the wrong package. On
| the other hand, I have *never once* had the occasion to say `Wow, damn
| glad that package system saved my ass on *this*!'
How could it? You have obviously never actually set it up so it _could_
have saved your ass.
But what I keep wondering, however, is why "save my ass" is a criterion
for the value of something. I have heard a few people argue that if they
are bumbling fools and resoundingly incompetent, they are "saved" by some
feature or another, and this is somehow valuable. I think the opposite:
I think if people are bumbling fools and resoundingly incompetent, they
should crash and burn, the sooner the better, because saving them does
only one thing: it makes it possible for them to continue to be bumbling
fools and resoundingly incompetent.
Have you ever heard anyone say "Man, I am so glad I have studied
mathematics and acquired a mathematical way of thinking! That has
_really_ saved my ass!"? If not, let us tear down the mathematics
department at every university and burn the math books!
How would you rate a medical doctor who exclaimed "I'm really happy I
know the spleen. That really saved my ass!". I would rate him as
dangerously incompetent, just as I rate your comment.
But you are a Scheme freak, are you not?
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
> * "Joe Marshall" <·············@attbi.com>
> | In the years I have been hacking lisp, I have on many occasions cursed
> | the package system, mainly for making me restart my lisp to undo
whatever
> | random damage happened when I read something in the wrong package. On
> | the other hand, I have *never once* had the occasion to say `Wow, damn
> | glad that package system saved my ass on *this*!'
>
> How could it? You have obviously never actually set it up so it _could_
> have saved your ass.
I don't really know *how* to set it up so that it could save my ass.
This isn't to say that I don't how the package system works, it is that
I think the particular tools that the package system provides are
rather crude, and although they can be used as a servicable namespace
partitioning, they quickly reveal limitations.
> But what I keep wondering, however, is why "save my ass" is a criterion
> for the value of something. I have heard a few people argue that if
they
> are bumbling fools and resoundingly incompetent, they are "saved" by
some
> feature or another, and this is somehow valuable. I think the opposite:
> I think if people are bumbling fools and resoundingly incompetent, they
> should crash and burn, the sooner the better, because saving them does
> only one thing: it makes it possible for them to continue to be bumbling
> fools and resoundingly incompetent.
>
> Have you ever heard anyone say "Man, I am so glad I have studied
> mathematics and acquired a mathematical way of thinking! That has
> _really_ saved my ass!"?
I have occasionally thought that myself.
> If not, let us tear down the mathematics
> department at every university and burn the math books!
I wouldn't suggest an all-or-nothing solution. I happen to dislike the
package system, but that doesn't mean that I'm going to abandon Lisp
and embrace Visual Basic.
> How would you rate a medical doctor who exclaimed "I'm really happy I
> know the spleen. That really saved my ass!". I would rate him as
> dangerously incompetent, just as I rate your comment.
I think I would prefer him over a medical doctor that said
``Oh. What's this organ then?''
But perhaps I should have been less colloquial. What I was implying
is that the package system has caused me an inordinate amount of
difficulty compared to the problem it is designed to solve. `Saving
my ass' should be read as hyperbole, not as criterion.
> But you are a Scheme freak, are you not?
I am tempted to quote scripture: It is you who say that I am.
I like Scheme, and enjoy programming in it. On the other hand, I like
Common Lisp, too, and have written orders of magnitude more code
in Common Lisp than I have in Scheme. I feel comfortable with either
language.
"Joe Marshall" <·············@attbi.com> writes:
> What I was implying is that the package system has caused me an
> inordinate amount of difficulty compared to the problem it is
> designed to solve.
So how would you design a namespacing system for symbols which would
cause less difficulty?
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
"Rahul Jain" <·····@sid-1129.sid.rice.edu> wrote in message
···················@photino.sid.rice.edu...
> "Joe Marshall" <·············@attbi.com> writes:
>
> > What I was implying is that the package system has caused me an
> > inordinate amount of difficulty compared to the problem it is
> > designed to solve.
>
> So how would you design a namespacing system for symbols which would
> cause less difficulty?
I'd start by researching the state of the art vis-a-vis module systems....
But seriously, I think a lot of the issues I have with the package
system could be ameliorated if 1. read didn't cause visible side effects
and 2. symbol resolution was deferred until runtime
"Joe Marshall" <·············@attbi.com> writes:
> "Rahul Jain" <·····@sid-1129.sid.rice.edu> wrote in message
> ···················@photino.sid.rice.edu...
> > So how would you design a namespacing system for symbols which would
> > cause less difficulty?
>
> I'd start by researching the state of the art vis-a-vis module systems....
Module systems (according to any definition I've seen) aren't
namespaces for symbols, but first-class environments, where symbols
have local mappings to values.
> But seriously, I think a lot of the issues I have with the package
> system could be ameliorated if 1. read didn't cause visible side effects
> and 2. symbol resolution was deferred until runtime
That wouldn't make sense. How would I use a symbol if it didn't exist
when I was trying to use it?
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
"Rahul Jain" <·····@sid-1129.sid.rice.edu> wrote in message
···················@photino.sid.rice.edu...
> "Joe Marshall" <·············@attbi.com> writes:
>
> > "Rahul Jain" <·····@sid-1129.sid.rice.edu> wrote in message
> > ···················@photino.sid.rice.edu...
>
> > > So how would you design a namespacing system for symbols which would
> > > cause less difficulty?
> >
> > I'd start by researching the state of the art vis-a-vis module
systems....
>
> Module systems (according to any definition I've seen) aren't
> namespaces for symbols, but first-class environments, where symbols
> have local mappings to values.
>
> > But seriously, I think a lot of the issues I have with the package
> > system could be ameliorated if 1. read didn't cause visible side
effects
> > and 2. symbol resolution was deferred until runtime
>
> That wouldn't make sense. How would I use a symbol if it didn't exist
> when I was trying to use it?
Depends on the use. The vast majority of uses of symbols is as identifiers
in programs. These symbols simply don't need to be interned.
"Joe Marshall" <·············@attbi.com> writes:
> In the years I have been hacking lisp, I have on many occasions cursed
> the package system, mainly for making me restart my lisp to undo whatever
> random damage happened when I read something in the wrong package.
> On the other hand, I have *never once* had the occasion to say
> `Wow, damn glad that package system saved my ass on *this*!'
I have. More times than I can count.
And, in general, I have a meta-rule (as in "rule of thumb", not "rule of law"):
If person X perceives a problem and person Y doesn't perceive a problem,
then unless you have reason to believe person X to be clinically nuts,
if you know no other piece of information about the problem, then person
X is probably right and person Y is probably wrong.
For example:
(a) Mary complains that Joe sexually harrassed her.
Sally says, "gosh, Joe never sexually harrassed me."
Has Sally refuted Mary? No, Sally has said "I wasn't present
and have no information."
(b) If Fred says "The thing I like about Kathy is that she always praises
people for the good work they do." and Joe says "I've never heard
her do this for me." and Fred says "I've heard her praise you."
Is it more likely that (1) Kathy said it and Joe didn't hear or
(2) Fred is a pathological liar and just made this up to irritate
or confuse Joe. Obviously either are possible but I tend to defaultly
assume (1) unless shown strong evidence of (2).
So given the choice between thinking I'm looney for liking packages or
you're oblivious for not understanding the value that packages offer you,
I'm reluctantly pressed into the bad position of suggesting you may be
creating a situation where to continue productively in the conversation,
I have to call you oblivious. It's not my first choice to approach a
discussion by addressing a speaker's personal characteristics since
ordinarily that is an ad hominem, but in this particular case you have
created what I guess I'll call a "passive ad hominem" (in honor of the
notion of "passive aggressive") by observing a personal characteristic
in yourself and then citing it as a reference for a technical point. There
is really no other way of proceeding according to proper rules of procedure
in an evidentiary hearing than to examine the credibility of the witness.
And besides, the package system is _designed_ not to overwhelm you with
the sense that it is there at all, so you're not _supposed_ to notice
when it saves you. Its whole purpose in life is to give you the "I own
the whole universe feel." If we didn't want to do this, we'd have just
made whose actual name was TV:FOO (6 letters) rather than omittable
package names because then sharing would always be explicit. The whole
notion of omitting the package is intended to draw attention away from
notions of sharing, even though those notions of sharing are often
absolutely critical to the correct function of your application. It's
not that you're not supposed to know; it's only that you're not supposed
to focus on that at every instant.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> "Joe Marshall" <·············@attbi.com> writes:
>
> > In the years I have been hacking lisp, I have on many occasions cursed
> > the package system, mainly for making me restart my lisp to undo
whatever
> > random damage happened when I read something in the wrong package.
> > On the other hand, I have *never once* had the occasion to say
> > `Wow, damn glad that package system saved my ass on *this*!'
>
> I have. More times than I can count.
>
> So given the choice between thinking I'm looney for liking packages or
> you're oblivious for not understanding the value that packages offer you,
> I'm reluctantly pressed into the bad position of suggesting you may be
> creating a situation where to continue productively in the conversation,
> I have to call you oblivious. It's not my first choice to approach a
> discussion by addressing a speaker's personal characteristics since
> ordinarily that is an ad hominem, but in this particular case you have
> created what I guess I'll call a "passive ad hominem" (in honor of the
> notion of "passive aggressive") by observing a personal characteristic
> in yourself and then citing it as a reference for a technical point.
There
> is really no other way of proceeding according to proper rules of
procedure
> in an evidentiary hearing than to examine the credibility of the witness.
Oh, I don't mind being called oblivious. Erann Gat solicited opinions
and I gave what I explicitly said was my `uninformed opinion'.
> And besides, the package system is _designed_ not to overwhelm you with
> the sense that it is there at all, so you're not _supposed_ to notice
> when it saves you. Its whole purpose in life is to give you the "I own
> the whole universe feel."
I understand this. However, I have found that the package system does
a poor job of this. If I *never* noticed it, that would be fine, but
I notice it far more frequently than I'd like, and when I *do* notice it,
I find that it can be difficult to get it back to a useful state
without rebooting.
If you would like, I can give you several technical examples where the
package system has gotten in the way.
"Joe Marshall" <·············@attbi.com> writes:
> If you would like, I can give you several technical examples where the
> package system has gotten in the way.
I'm sure there are examples of places where where modern medicine gets in
the way, too. But that isn't a refutation of its many benefits.
Nevertheless, since I'm curious what in the world you're talking about,
yeah, I'd be interested to hear...
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> "Joe Marshall" <·············@attbi.com> writes:
>
> > If you would like, I can give you several technical examples where the
> > package system has gotten in the way.
>
> I'm sure there are examples of places where where modern medicine gets in
> the way, too. But that isn't a refutation of its many benefits.
>
> Nevertheless, since I'm curious what in the world you're talking about,
> yeah, I'd be interested to hear...
READ causes noticable side effects. This can create dependencies
on the order in which things are read. In the `normal' case of
reading a file in order to compile it, (or the analagous case of
interning symbols in a fasl file), there are other dependencies
that also have to be obeyed (like macros being defined before
use). So this isn't so much of a day-to-day problem.
Where it *was* a problem was on the Lisp Machine. When you opened
a file in Zmacs, it would parse the file mode and it would
parse some of the file contents. It would attach properties to
the symbols mentioned in the file.
When you were browsing code, you might open a file that was
in a package that was not yet defined. Well, the package became
defined and a slew of symbols from the file would get interned
in it. Unfortunately, it was unlikely that the package was
correctly set up, so when you went to evaluate any code it
wouldn't work, or when you went to fix the packages, you'd run
into thousands of name conflicts.
Additionally, if you accidentally fasloaded a file before the
packages were set up, you would end up with functions pointing
at the wrong symbols. Patching up the packages by uninterning
the conflicting symbols didn't fix this, it just made the functions
point at UNINTERNED wrong symbols.
Now there is a `standard' mode of operating that avoids most of
this. You make *absolutely sure* that the *very first thing* you
load into any lisp is a set of defpackage forms that set up the
*entire* package structure. You also make sure that this file
is loaded both at compile time *and* at run time. This isn't hard
to do if you put it in your `init' file.
So, on to more obscure problems. You can't use `forward references'
to symbols that don't exist in packages that don't exist (yet).
In your init file, you'd *like* to be able to customize some
parameters before you start building the system. Perhaps you have
some macros that are parameterized, whatever. As an example, I
once worked at a place that had a `verbosity' switch that I wanted
set.
The obvious thing is to write (setq utility::*verbosity* t)
but the utility package isn't loaded yet. Never mind that the
utility package *will* be there when I call this function, it
isn't there when I *read* the code. Instead I write:
(let* ((utl-pkg (find-package :utility))
(verbosity (intern (symbol-name :*verbosity*) utl-pkg)))
(setf (symbol-value verbosity) t))
The same goes for functions that I want to call. I can't
write (progn (load "java-tools.lisp") (java-tools:make-all))
The way around this problem is to write a function that
defers interning until runtime. Then you can write
(progn (load "java-tools.lisp") (funcall-in-package :java-tools :make-all))
The package system allows me to `split' names. I can have
my symbol FOO be different from your symbol FOO. It doesn't
allow me to `join' names. I cannot have my symbol BAR be
the same as your symbol FOO. (Or perhaps more illustrative,
I can't have `JRM:ORIGINAL-MULTIPLE-VALUE-BIND' be the same
as `CL-USER:MULTIPLE-VALUE-BIND'.) On the lisp machine, you
actually *could* do this by forwarding the memory, and it
comes in handy on occasion.
Another example: when writing a tiny language, it is nice to
embed that language in Lisp. You can make a package containing
your language constructs, and use macros to `translate' them
into standard lisp for compilation. However, CL:IF is a special
form `known' to the compiler. FOO:IF is not. The compiler will
not generate a conditional unless you use the symbol in the CL
package. On the other hand, the point of putting the symbols
into your own package was to *not* use the same symbols.
Finally, a really nasty one. The `topology' of the package
structure is a global resource. When we were building a new
Lisp machine, we had a brand new compiler. Obviously, it goes
in the `compiler' package. Well, on the old machine, there
already was a compiler in the compiler package. So we had
to load the compiler into a different package. But the
compiler had to `appear' as if it were in the `compiler'
package in the fasl file. We modified the package inheritance
in the new machine. A number of symbols were moved to
different packages, but were to remain visible. The problem
was that the current machine wouldn't work if you did this.
Our `solution' was a rather hairy thing that twiddled the
guts of the package system on the fly to satisify whatever
compiler happened to want to be using it. It was a nightmare.
Now I realize that name conficts are a problem (look at emacs).
But I don't think the solution is to hack the READER. With
a little careful thought, I'm sure that a better way could be
found that defers identifier->symbol mapping until later in
the game.
"Joe Marshall" <·············@attbi.com> writes:
> Where it *was* a problem was on the Lisp Machine. When you opened
> a file in Zmacs, it would parse the file mode and it would
> parse some of the file contents. It would attach properties to
> the symbols mentioned in the file.
Yes, I think that's a dangerous way to deal with editing source. The
editor should never use INTERN, only FIND-SYMBOL.
> Additionally, if you accidentally fasloaded a file before the
> packages were set up, you would end up with functions pointing
> at the wrong symbols. Patching up the packages by uninterning
> the conflicting symbols didn't fix this, it just made the functions
> point at UNINTERNED wrong symbols.
Wouldn't the IN-PACKAGE form at the top of the file cause an error,
preventing the file from being loaded? (or asking if you would like to
implicitly create it, etc)
> So, on to more obscure problems. You can't use `forward references'
> to symbols that don't exist in packages that don't exist (yet).
Again, this should cause an error to be signalled, at which point, you
should load the definition of the other package or just implicitly
create it.
> In your init file, you'd *like* to be able to customize some
> parameters before you start building the system.
So you load the defpackage form(s) before playing with symbols in
those packages.
> The package system allows me to `split' names. I can have
> my symbol FOO be different from your symbol FOO. It doesn't
> allow me to `join' names.
Yes, a sort of symbol-alias would be nice. I suppose the symbol could
print as its name in its home package without any real loss.
> Another example: when writing a tiny language, it is nice to
> embed that language in Lisp. You can make a package containing
> your language constructs, and use macros to `translate' them
> into standard lisp for compilation. However, CL:IF is a special
> form `known' to the compiler. FOO:IF is not. The compiler will
> not generate a conditional unless you use the symbol in the CL
> package. On the other hand, the point of putting the symbols
> into your own package was to *not* use the same symbols.
Right, so either define FOO:IF as a macro that expands to CL:IF or
import CL:IF. The package system doesn't help you when you don't tell
it to do what you want it to do.
> Finally, a really nasty one. The `topology' of the package
> structure is a global resource.
Yes, having unnamed packages and dynamic name->package bindings might
be a useful addition, but it's so uncommonly needed that I doubt
people have really thought about how to do it so that the resulting
packages are actually useful. I guess these would be called
"first-class packages".
Hmm, actually, that might be simple to add to my generic-reader.
Simply have the token-interpretation-fn be a closure around some
name->package EQUAL hashtable. Or have a *packages* hashtable that can
be dynamically shadowed. Probably providing both options would be a
good idea.
> Now I realize that name conficts are a problem (look at emacs).
> But I don't think the solution is to hack the READER. With
> a little careful thought, I'm sure that a better way could be
> found that defers identifier->symbol mapping until later in
> the game.
Identifiers in Lisp are symbols. Symbol->value mapping is what occurs
later. Use the right abstraction at the right time. It's just a matter
of learning when each of these conversions take place and choosing the
conversion that matches your desired semantics.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
"Rahul Jain" <·····@sid-1129.sid.rice.edu> wrote in message
···················@photino.sid.rice.edu...
> "Joe Marshall" <·············@attbi.com> writes:
>
> > Additionally, if you accidentally fasloaded a file before the
> > packages were set up, you would end up with functions pointing
> > at the wrong symbols. Patching up the packages by uninterning
> > the conflicting symbols didn't fix this, it just made the functions
> > point at UNINTERNED wrong symbols.
>
> Wouldn't the IN-PACKAGE form at the top of the file cause an error,
> preventing the file from being loaded? (or asking if you would like to
> implicitly create it, etc)
I don't think fasl files have an `in-package' form at the top.
> > So, on to more obscure problems. You can't use `forward references'
> > to symbols that don't exist in packages that don't exist (yet).
>
> Again, this should cause an error to be signalled, at which point, you
> should load the definition of the other package or just implicitly
> create it.
The error is the problem. I want to refer to a symbol that I *know*
will exist a short time in the future. I have no intention of
using or manipulating the symbol until it exists and the package
system is set up, I just want to refer to the name. Even so, I'm
out of luck.
> > In your init file, you'd *like* to be able to customize some
> > parameters before you start building the system.
>
> So you load the defpackage form(s) before playing with symbols in
> those packages.
In general, init files are loaded *before* anything else. It is
hard to get the defpackage forms to load prior to the init forms.
> > Another example: when writing a tiny language, it is nice to
> > embed that language in Lisp. You can make a package containing
> > your language constructs, and use macros to `translate' them
> > into standard lisp for compilation. However, CL:IF is a special
> > form `known' to the compiler. FOO:IF is not. The compiler will
> > not generate a conditional unless you use the symbol in the CL
> > package. On the other hand, the point of putting the symbols
> > into your own package was to *not* use the same symbols.
>
> Right, so either define FOO:IF as a macro that expands to CL:IF or
> import CL:IF. The package system doesn't help you when you don't tell
> it to do what you want it to do.
I can't tell it to do what I want it to do. I *want* to hand forms
to the compiler of the sort '(if (foo) (bar)), but I *don't* want
the symbol IF in my package to be CL:IF (for various reasons, perhaps
I'm mucking around with the function cell). Now I could walk the form
replacing FOO:IF with CL:IF (and so forth for all the special forms),
but this is idiotic. The fact of the matter is that the compiler
is not using the value cell, the function cell, the plist, the package,
or the print name of 'CL:IF. It is only using it as a unique name.
But nonetheless, if I want to use it the same way the compiler uses it,
I have to drag along all the other baggage that comes with it.
> > Finally, a really nasty one. The `topology' of the package
> > structure is a global resource.
>
> Yes, having unnamed packages and dynamic name->package bindings might
> be a useful addition, but it's so uncommonly needed that I doubt
> people have really thought about how to do it so that the resulting
> packages are actually useful. I guess these would be called
> "first-class packages".
>
> Hmm, actually, that might be simple to add to my generic-reader.
> Simply have the token-interpretation-fn be a closure around some
> name->package EQUAL hashtable. Or have a *packages* hashtable that can
> be dynamically shadowed. Probably providing both options would be a
> good idea.
I wouldn't recommend that. The first thing we found when we tried that
was that we needed `package closures', i.e., a way to bind a function
to a particular package topology.
> > Now I realize that name conficts are a problem (look at emacs).
> > But I don't think the solution is to hack the READER. With
> > a little careful thought, I'm sure that a better way could be
> > found that defers identifier->symbol mapping until later in
> > the game.
>
> Identifiers in Lisp are symbols.
Yes, but the vast majority need not be. If I write this:
(defun fact (x) (if (zerop x) 1 (* x (fact (1- x)))))
The identifier X is interned as a symbol, yet the code does not use
the value cell, function cell, print name, package, or plist. Not
only that, but the identity of the identifier need not even last
beyond the compilation! However, were I to enter that function,
and then attempt to import a symbol named X from another package,
I'd get a name conflict. What is conflicting?
> Symbol->value mapping is what occurs later.
Yes. It occurs as late in the process as possible: just before you
need the value for a computation.
But identifier->symbol mapping occurs extremely early in the process,
where it isn't obvious that the symbol will be needed at all.
"Joe Marshall" <·············@attbi.com> writes:
> "Rahul Jain" <·····@sid-1129.sid.rice.edu> wrote in message
> ···················@photino.sid.rice.edu...
> > Wouldn't the IN-PACKAGE form at the top of the file cause an error,
> > preventing the file from being loaded? (or asking if you would like to
> > implicitly create it, etc)
> I don't think fasl files have an `in-package' form at the top.
Hmm, yeah. :)
That's what defsystem is for anyway...
> > > So, on to more obscure problems. You can't use `forward references'
> > > to symbols that don't exist in packages that don't exist (yet).
> > Again, this should cause an error to be signalled, at which point, you
> > should load the definition of the other package or just implicitly
> > create it.
> The error is the problem. I want to refer to a symbol that I *know*
> will exist a short time in the future.
So load the definition that allows the name to exist.
> > So you load the defpackage form(s) before playing with symbols in
> > those packages.
> In general, init files are loaded *before* anything else. It is
> hard to get the defpackage forms to load prior to the init forms.
Couldn't you load it in the init file?
Or do something like (setf (symbol-value (find-symbol ...)) ...)?
> I can't tell it to do what I want it to do. I *want* to hand forms
> to the compiler of the sort '(if (foo) (bar)), but I *don't* want
> the symbol IF in my package to be CL:IF (for various reasons, perhaps
> I'm mucking around with the function cell). Now I could walk the form
> replacing FOO:IF with CL:IF (and so forth for all the special forms),
> but this is idiotic. The fact of the matter is that the compiler
> is not using the value cell, the function cell, the plist, the package,
> or the print name of 'CL:IF. It is only using it as a unique name.
> But nonetheless, if I want to use it the same way the compiler uses it,
> I have to drag along all the other baggage that comes with it.
Right, that's why you should do
(defmacro foo:if (&rest args)
`(cl:if ,@args))
If you don't want the whole symbol, you'll have to define which exact
parts you want to take from the other symbol anyway.
> > Hmm, actually, that might be simple to add to my generic-reader.
> > Simply have the token-interpretation-fn be a closure around some
> > name->package EQUAL hashtable. Or have a *packages* hashtable that can
> > be dynamically shadowed. Probably providing both options would be a
> > good idea.
> I wouldn't recommend that. The first thing we found when we tried that
> was that we needed `package closures', i.e., a way to bind a function
> to a particular package topology.
That sounds like modules to me...
> > Identifiers in Lisp are symbols.
> Yes, but the vast majority need not be.
They need to be because that's how Lisp code is defined.
> The identifier X is interned as a symbol, yet the code does not use
> the value cell, function cell, print name, package, or plist.
But it uses the symbol X in the code to indicate what identifier you
are using. That way the evaluator can compare two symbols and
determine if they are the same identifier or not.
> Not only that, but the identity of the identifier need not even last
> beyond the compilation! However, were I to enter that function, and
> then attempt to import a symbol named X from another package, I'd
> get a name conflict. What is conflicting?
The names you used. If you want to have lexical-extent symbols, I
think I can understand, but I can't think of a practical way of
actually doing it.
> > Symbol->value mapping is what occurs later.
> Yes. It occurs as late in the process as possible: just before you
> need the value for a computation.
> But identifier->symbol mapping occurs extremely early in the process,
> where it isn't obvious that the symbol will be needed at all.
If the symbol is used, it's needed. I don't see how this can be
removed, resulting in a language that can really be called
"Lisp". This distinction of read, compile, eval, macroexpand, load,
etc times is one of the distinctive, important, and useful features of
lisp. If you don't like those features, you'll have to form a
different (possibly overlapping) community, since many of the current
leaders of the Lisp community seem to prefer dealing with the times
the way we do now. I think it just comes down to being comfortable
with the way they are defined and being precise about what times
things occur when you write your code.
Essentially, this distinction is one of the axioms of Lisp, as I see
it.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
"Rahul Jain" <·····@sid-1129.sid.rice.edu> wrote in message
···················@photino.sid.rice.edu...
> "Joe Marshall" <·············@attbi.com> writes:
>
>
> > > > So, on to more obscure problems. You can't use `forward references'
> > > > to symbols that don't exist in packages that don't exist (yet).
>
> > > Again, this should cause an error to be signalled, at which point, you
> > > should load the definition of the other package or just implicitly
> > > create it.
>
> > The error is the problem. I want to refer to a symbol that I *know*
> > will exist a short time in the future.
>
> So load the definition that allows the name to exist.
But then I can't refer to the symbol in the same file as the file
that loads the code that defines it. I am saying `I can't use forward
references', and you are saying `don't use them, then'. That isn't
quite the solution I had in mind.
> > > So you load the defpackage form(s) before playing with symbols in
> > > those packages.
>
> > In general, init files are loaded *before* anything else. It is
> > hard to get the defpackage forms to load prior to the init forms.
>
> Couldn't you load it in the init file?
Nope. Not if there is processing to be done between initialization
and loading of the packages (which there may be).
> Or do something like (setf (symbol-value (find-symbol ...)) ...)?
Yes. But this is the exact problem. Anywhere else in the system
I'd write (setq foo:*bar* 22), but in my init file I have to
kludge up
(setf (symbol-value
(or (find-symbol (symbol-name :*bar*)
(or (find-package :foo)
(error "no package")))
(error "no symbol")))
22)
This seems like an excessive amount of verbosity.
> > > Hmm, actually, that might be simple to add to my generic-reader.
> > > Simply have the token-interpretation-fn be a closure around some
> > > name->package EQUAL hashtable. Or have a *packages* hashtable that can
> > > be dynamically shadowed. Probably providing both options would be a
> > > good idea.
>
> > I wouldn't recommend that. The first thing we found when we tried that
> > was that we needed `package closures', i.e., a way to bind a function
> > to a particular package topology.
>
> That sounds like modules to me...
No, it's ugly. In one `package environment' package FOO would inherit
from packages BAR and BAZ and import CL:IF, in another, package FOO
would inherit from CL and BAZ and shadowing import BAR:IF.
It was the case that the cross-compiler would only work with the
second setup, but the emulator would only work with the first. What
we wanted was automatic switching of the topology when calling a
compiler or emulator function.
> > > Identifiers in Lisp are symbols.
>
> > Yes, but the vast majority need not be.
>
> They need to be because that's how Lisp code is defined.
Yes, I know how it works. It's what I'm complaining about.
> > The identifier X is interned as a symbol, yet the code does not use
> > the value cell, function cell, print name, package, or plist.
>
> But it uses the symbol X in the code to indicate what identifier you
> are using. That way the evaluator can compare two symbols and
> determine if they are the same identifier or not.
>
> > Not only that, but the identity of the identifier need not even last
> > beyond the compilation! However, were I to enter that function, and
> > then attempt to import a symbol named X from another package, I'd
> > get a name conflict. What is conflicting?
>
> The names you used. If you want to have lexical-extent symbols, I
> think I can understand, but I can't think of a practical way of
> actually doing it.
Lexical-extent symbols?!
No, I want referential transparency. When I import a symbol in a package,
it ought not depend on whether I used a lexical variable of the same name in
an unrelated function in that package.
> > > Symbol->value mapping is what occurs later.
>
> > Yes. It occurs as late in the process as possible: just before you
> > need the value for a computation.
>
> > But identifier->symbol mapping occurs extremely early in the process,
> > where it isn't obvious that the symbol will be needed at all.
>
> If the symbol is used, it's needed.
Not necessarily. If you compile this function:
(defun fact (x) (if (zerop x) 1 (* x (fact (1- x)))))
and look at the fasl file, you will not see symbol X *anywhere*.
You don't need it.
> I don't see how this can be
> removed, resulting in a language that can really be called
> "Lisp". This distinction of read, compile, eval, macroexpand, load,
> etc times is one of the distinctive, important, and useful features of
> lisp. If you don't like those features, you'll have to form a
> different (possibly overlapping) community, since many of the current
> leaders of the Lisp community seem to prefer dealing with the times
> the way we do now.
Who said I didn't like these? And I doubt that the leaders of the
CL community really enjoy dealing with symbol conflicts. My impression
is that they tolerate them because life without some kind of namespace
mechanism would be impossible.
> I think it just comes down to being comfortable
> with the way they are defined and being precise about what times
> things occur when you write your code.
I don't think it is a good idea to just become comfortable with
`the way things are'. Having to be precise about the timing of READ
is annoying. I don't have to be precise about the order of definitions
in (or across) files, I don't have to be precise about what is or
is not defined when I run the program (I run partially written code
all the time), but suddenly I *do* have to be precise when I type
a symbol name?
> Essentially, this distinction is one of the axioms of Lisp, as I see
> it.
I think I could do without errors being raised by the package system
as an axiom.
"Joe Marshall" <·············@attbi.com> writes:
> "Rahul Jain" <·····@sid-1129.sid.rice.edu> wrote in message
> ···················@photino.sid.rice.edu...
> > "Joe Marshall" <·············@attbi.com> writes:
> >
> > > Additionally, if you accidentally fasloaded a file before the
> > > packages were set up, you would end up with functions pointing
> > > at the wrong symbols. Patching up the packages by uninterning
> > > the conflicting symbols didn't fix this, it just made the functions
> > > point at UNINTERNED wrong symbols.
> >
> > Wouldn't the IN-PACKAGE form at the top of the file cause an error,
> > preventing the file from being loaded? (or asking if you would like to
> > implicitly create it, etc)
>
> I don't think fasl files have an `in-package' form at the top.
Well, they are required to bind *PACKAGE* around the entire load.
And they have to give that value a binding. They may not do
IN-PACKAGE per se, but it's going to amount to the same.
> > > So, on to more obscure problems. You can't use `forward references'
> > > to symbols that don't exist in packages that don't exist (yet).
> >
> > Again, this should cause an error to be signalled, at which point, you
> > should load the definition of the other package or just implicitly
> > create it.
>
> The error is the problem. I want to refer to a symbol that I *know*
> will exist a short time in the future. I have no intention of
> using or manipulating the symbol until it exists and the package
> system is set up, I just want to refer to the name. Even so, I'm
> out of luck.
Its name is a string. You can certainly refer to its name. ;)
...
> But identifier->symbol mapping occurs extremely early in the process,
> where it isn't obvious that the symbol will be needed at all.
No, you mean where it happens not to be needed in this case.
You want it delayed until load time.
But in normal compilation, the identifier to symbol mapping _is_ done
at compile time, in order to process semantics, so it is not normall
delayed that long. It is typical of interactive and bootstrap code
that this problem comes up, but interactive and bootstrap code is not
typical of real code.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> "Joe Marshall" <·············@attbi.com> writes:
>
> > "Rahul Jain" <·····@sid-1129.sid.rice.edu> wrote in message
> > ···················@photino.sid.rice.edu...
> > > "Joe Marshall" <·············@attbi.com> writes:
> > >
> > > > Additionally, if you accidentally fasloaded a file before the
> > > > packages were set up, you would end up with functions pointing
> > > > at the wrong symbols. Patching up the packages by uninterning
> > > > the conflicting symbols didn't fix this, it just made the functions
> > > > point at UNINTERNED wrong symbols.
> > >
> > > Wouldn't the IN-PACKAGE form at the top of the file cause an error,
> > > preventing the file from being loaded? (or asking if you would like to
> > > implicitly create it, etc)
> >
> > I don't think fasl files have an `in-package' form at the top.
>
> Well, they are required to bind *PACKAGE* around the entire load.
> And they have to give that value a binding. They may not do
> IN-PACKAGE per se, but it's going to amount to the same.
Well, suppose we have this file:
(in-package "FOO")
(defun mystery (x) (eq x 'if))
Now when we compile this, what gets stored in the fasl file?
(Yes, it will depend on whether 'foo:if is eq to 'cl:if or not.
Assume that foo:defun = cl:defun and foo:eq is cl:eq)
"Joe Marshall" <·············@attbi.com> writes:
> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@shell01.TheWorld.com...
> > "Joe Marshall" <·············@attbi.com> writes:
> >
> > > "Rahul Jain" <·····@sid-1129.sid.rice.edu> wrote in message
> > > ···················@photino.sid.rice.edu...
> > > > "Joe Marshall" <·············@attbi.com> writes:
> > > >
> > > > > Additionally, if you accidentally fasloaded a file before the
> > > > > packages were set up, you would end up with functions pointing
> > > > > at the wrong symbols. Patching up the packages by uninterning
> > > > > the conflicting symbols didn't fix this, it just made the functions
> > > > > point at UNINTERNED wrong symbols.
> > > >
> > > > Wouldn't the IN-PACKAGE form at the top of the file cause an error,
> > > > preventing the file from being loaded? (or asking if you would like to
> > > > implicitly create it, etc)
> > >
> > > I don't think fasl files have an `in-package' form at the top.
> >
> > Well, they are required to bind *PACKAGE* around the entire load.
> > And they have to give that value a binding. They may not do
> > IN-PACKAGE per se, but it's going to amount to the same.
>
> Well, suppose we have this file:
> (in-package "FOO")
>
> (defun mystery (x) (eq x 'if))
>
> Now when we compile this, what gets stored in the fasl file?
> (Yes, it will depend on whether 'foo:if is eq to 'cl:if or not.
> Assume that foo:defun = cl:defun and foo:eq is cl:eq)
The langauge is obliged to say that it either stores the symbol by its
package or by its availability in the current package or to record the
need to check that coincidences are checked. The rational thing is to
do the same as what the printer would do, since that's what people will
expect. CL further constrains things by obliging you to make the load
time environment match the compile time environment, such that this doesn't
ever matter in valid code. But this problem is not unique to the compiler;
the same issue occurs in printer and is simpler to discuss.
* "Joe Marshall"
| I want to refer to a symbol that I *know* will exist a short time in the
| future. I have no intention of using or manipulating the symbol until it
| exists and the package system is set up, I just want to refer to the
| name. Even so, I'm out of luck.
I can sympathize with this problem, as you have described it, but I
wonder if you have ever tried to dump a new image with the packages
loaded. That has been how I have done things for the longest time. I
even tend to build my own Emacs that way. It not only saves a lot of
time in the startup phase and avoids loading a lot of files every time,
but building and dumping a new image would of course be done from
scratch, without an init file. The dumped image already has all the
packages loaded so now your init file loads without problems.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
> * "Joe Marshall"
> | I want to refer to a symbol that I *know* will exist a short time in the
> | future. I have no intention of using or manipulating the symbol until
it
> | exists and the package system is set up, I just want to refer to the
> | name. Even so, I'm out of luck.
>
> I can sympathize with this problem, as you have described it, but I
> wonder if you have ever tried to dump a new image with the packages
> loaded. That has been how I have done things for the longest time. I
> even tend to build my own Emacs that way. It not only saves a lot of
> time in the startup phase and avoids loading a lot of files every time,
> but building and dumping a new image would of course be done from
> scratch, without an init file. The dumped image already has all the
> packages loaded so now your init file loads without problems.
Yes, and this helps tremendously.
Unfortunately, at one place I worked the boss was insistent that we
always do a `clean build' before every check-in.
What I ended up doing was installing a hook to be called right after
the packages were loaded. The hook was a symbol in the user package,
and my init file would hang a function on that.
* "Joe Marshall" <·············@attbi.com>
| Unfortunately, at one place I worked the boss was insistent that we
| always do a `clean build' before every check-in.
But this is not a problem with Common Lisp, is it? :)
I think making a clean build of the packages with a good defsystem, then
loading them into a virgin image to dump a clean image should have been a
satisfactory solution to your boss.
If anyone has the kind of problem you have described, I think the proper
answer is to teach them to use the implementation's ability to save the
world and dump a new image, not to futz around with weird hacks.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
"Joe Marshall" <·············@attbi.com> writes:
> "Rahul Jain" <·····@sid-1129.sid.rice.edu> wrote in message ···················@photino.sid.rice.edu...
> > Identifiers in Lisp are symbols.
>
> Yes, but the vast majority need not be. If I write this:
>
> (defun fact (x) (if (zerop x) 1 (* x (fact (1- x)))))
>
> The identifier X is interned as a symbol, yet the code does not use
> the value cell, function cell, print name, package, or plist. Not
> only that, but the identity of the identifier need not even last
> beyond the compilation! However, were I to enter that function,
> and then attempt to import a symbol named X from another package,
> I'd get a name conflict. What is conflicting?
But that's not a language requirement. It would be possible to write
a repl and a file compiler that would keep track of what symbols would
have been compiled away, and would unintern them if they weren't there
before. Actually, that would be a pretty cool feature, come to think
of it ... not cool enough for me to actually go and do it, but I like
the idea :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Joe Marshall" <·············@attbi.com> writes:
> READ causes noticable side effects. This can create dependencies
> on the order in which things are read.
EVAL and/or COMPILE-FILE causes noticeable side-effects too. This
creates dependencies on the order in which Scheme expressions can be
processed.
Moreover, the Scheme environment is among the harshest I've ever seen
for a programming language because it tends to take the attitude that
if your program is in error, all bets are off. The Scheme spec doesn't
waste any time at all trying to tell you that you have any expectation
of hope if your program ever makes a mistake. And certainly among all
of that is that you are expected to have the initial environment set up
perfectly for your initial work. No advice about how to avoid problems.
No operators or paradigms for correction if problems occur.
And it's CL you're complaining about? CL has terminology for talking
about these problem states and correcting some of them, as well as for
inspecting and manipulating the environment to determine whether
you're going to get stung. Hmm.
> Where it *was* a problem was on the Lisp Machine. When you opened
> a file in Zmacs, it would parse the file mode and it would
> parse some of the file contents. It would attach properties to
> the symbols mentioned in the file.
I'm familiar with the problem you're talking about, but you can't
blame this on the package system. I don't think this is a fair
criticism. The Zmacs editor chose to put things on the property list
of symbols prematurely and got in trouble. (Had it put them on the
property list of Scheme-like symbols, the same problems would have been
even worse).
> When you were browsing code, you might open a file that was
> in a package that was not yet defined. Well, the package became
> defined and a slew of symbols from the file would get interned
> in it. Unfortunately, it was unlikely that the package was
> correctly set up, so when you went to evaluate any code it
> wouldn't work, or when you went to fix the packages, you'd run
> into thousands of name conflicts.
Just because someone can design a problem for which symbols ought not
be used and use symbols does not make symbols a bad datastructure.
I likewise had problems with what Zmacs did, but I attribute the
problem very, very differently.
> Additionally, if you accidentally fasloaded a file before the
> packages were set up, you would end up with functions pointing
> at the wrong symbols.
Just as if you accidentally load Scheme code when things are not fully
set up, you can get confusing effects. I don't see your point here.
> Patching up the packages by uninterning
> the conflicting symbols didn't fix this, it just made the functions
> point at UNINTERNED wrong symbols.
Bad defaults? When I get package errors in LispWorks, I usually take
the default correction and I'd say 95% of the time I don't have to do
anything more than press RETURN. Not that I'd think it awful if I had
to think about or intervene more than this.
> Now there is a `standard' mode of operating that avoids most of
> this. You make *absolutely sure* that the *very first thing* you
> load into any lisp is a set of defpackage forms that set up the
> *entire* package structure.
Or you code your editor to not require this. I'm not comfortable
blaming this "requirement" on the design of the package system when
it's very plainly a problem with the Zmacs architecture.
> You also make sure that this file
> is loaded both at compile time *and* at run time. This isn't hard
> to do if you put it in your `init' file.
>
> So, on to more obscure problems. You can't use `forward references'
> to symbols that don't exist in packages that don't exist (yet).
> In your init file, you'd *like* to be able to customize some
> parameters before you start building the system. Perhaps you have
> some macros that are parameterized, whatever. As an example, I
> once worked at a place that had a `verbosity' switch that I wanted
> set.
>
> The obvious thing is to write (setq utility::*verbosity* t)
> but the utility package isn't loaded yet. Never mind that the
> utility package *will* be there when I call this function, it
> isn't there when I *read* the code. Instead I write:
> (let* ((utl-pkg (find-package :utility))
> (verbosity (intern (symbol-name :*verbosity*) utl-pkg)))
> (setf (symbol-value verbosity) t))
>
> The same goes for functions that I want to call. I can't
> write (progn (load "java-tools.lisp") (java-tools:make-all))
>
> The way around this problem is to write a function that
> defers interning until runtime. Then you can write
> (progn (load "java-tools.lisp") (funcall-in-package :java-tools :make-all))
I usually did:
(load "java-tools.lisp")
(java-tools:make-all)
as two different forms. In the few cases where this wasn't possible, I did:
(progn (load "java-tools.lisp")
(eval (read-from-string "(java-tools:make-all)")))
or
(progn (load "java-tools.lisp")
(funcall (or (find-symbol "MAKE-ALL" "JAVA-TOOLS")
(error "JAVA-TOOLS:MAKE-ALL is not defined."))))
Hardly a major problem. And it doesn't require use of any non-standard
operators.
> The package system allows me to `split' names. I can have
> my symbol FOO be different from your symbol FOO. It doesn't
> allow me to `join' names.
Scheme doesn't either, btw.
> I cannot have my symbol BAR be
> the same as your symbol FOO. (Or perhaps more illustrative,
> I can't have `JRM:ORIGINAL-MULTIPLE-VALUE-BIND' be the same
> as `CL-USER:MULTIPLE-VALUE-BIND'.) On the lisp machine, you
> actually *could* do this by forwarding the memory, and it
> comes in handy on occasion.
This is a legitimate gripe. However, I believe CL can rise above it.
I see it as an API problem, not a data structure problem.
> Another example: when writing a tiny language, it is nice to
> embed that language in Lisp. You can make a package containing
> your language constructs, and use macros to `translate' them
> into standard lisp for compilation.
By this I assume you mean:
(defmacro if (test then &rest else)
`(cl:if ,test ,then ,else))
> However, CL:IF is a special
> form `known' to the compiler. FOO:IF is not. The compiler will
> not generate a conditional unless you use the symbol in the CL
> package.
Well, it's supposed to macroexpand your form before reaching
that conclusion.
> On the other hand, the point of putting the symbols
> into your own package was to *not* use the same symbols.
> Finally, a really nasty one. The `topology' of the package
> structure is a global resource. When we were building a new
> Lisp machine, we had a brand new compiler. Obviously, it goes
> in the `compiler' package. Well, on the old machine, there
> already was a compiler in the compiler package. So we had
> to load the compiler into a different package.
I don't see any problem here that adding more power to the package
system wouldn't fix. In particular, original Zetalisp had
hierarchical packages. Symbolics Genera usefully expanded on this by
having "package universes" associated with Syntax. Symbolics Genera
had about 5 to 7 syntaxes (package universes) loaded into the same
core image at the same time, depending on the configuration. I wrote
the code that maintained that separation. I never got complaints from
amyone saying the implementation had major technical problems. Most
people were surprised that Zetalisp and Common Lisp were able to be
co-resident at the same time, given they had needs for packages to be
called different things.
I certainly don't by any stretch think this problem would have been
fixed by removing complexity of packages and using Scheme-style
packages.
> But the compiler had to `appear' as if it were in the `compiler'
> package in the fasl file. We modified the package inheritance in
> the new machine. A number of symbols were moved to different
> packages, but were to remain visible. The problem was that the
> current machine wouldn't work if you did this. Our `solution' was a
> rather hairy thing that twiddled the guts of the package system on
> the fly to satisify whatever compiler happened to want to be using
> it. It was a nightmare.
I'm probably missing something without more details. I think the term
"overconstrained" existed before Lisp, much less its package system.
And I'm not surprised that it's possible to overconstrain problems in
Lisp since it's possible to overconstrian them in life. I'm hard
pressed to say this is a package system problem.
> Now I realize that name conficts are a problem (look at emacs).
> But I don't think the solution is to hack the READER. With
> a little careful thought, I'm sure that a better way could be
> found that defers identifier->symbol mapping until later in
> the game.
Yes, those may be possible workarounds in some of the cases you've
mentioned. I'm not sure they exhaust the space of possible workarounds,
nor that the presence of such a workaround is a proof that what CL does
is bad.
I have not at any time said modules are something people should not use.
I've said that packages are something that people can and do useful use.
What you're relating is very much akin to the issue of early vs late
binding in declarations. Sometimes one adds a declaration because they
know something about data and they want early (compile time) processing
of that information. Sometimes one knows something about a name and
one uses packages to carry this information. Sometimes one doesn't know
what the name-to-package association is, and there are ways of accomodating
that. But often one does know.
In
(defmacro foist (x) `(car ,x))
there is no material change in knowledge between read time and macro
expansion time such that delaying the semantic attachment of CAR's meaning
will do anything other than make it more difficult to figure out what symbol
is what. So most of the problems to do with symbols and macros might as well
be sorted out at read time as at macro expansion time.
In the case you describe, if I follow you correctly, and I kind of
doubt I do totally, you have some weird situation where your compile
time packages and runtime packages are not aligned. (Note that CL
says this is not valid CL, so you are on your own, since every time
Scheme says you are doing something not valid the Scheme folks are
happy to say you're SOL. I don't know why a double standard of how
much help you should expect should apply.) In general, I think the
problem is more that CL does not seek to handle this problem than that
CL would not be capable of handling this problem with available data
structures if it chose to provide you the necessary operators. I don't
see a data structure problem here; perhaps an API weakness. But new APIs
can be written without changing the language spec.
Kent M Pitman <······@world.std.com> writes:
> Moreover, the Scheme environment is among the harshest I've ever seen
> for a programming language because it tends to take the attitude that
> if your program is in error, all bets are off.
This is pretty much normal, I think. Nearly every modern language
specification says that an undefined behavior is, well, undefined.
This is especially true for errors which are not required to be
caught, and it seems to me that Scheme is conservative about requiring
compilers to catch runtime errors in order to enable them to produce
maximally efficient code.
I think this is, in effect, the same for Common Lisp; if you do
something undefined, the result is undefined.
> I have not at any time said modules are something people should not use.
> I've said that packages are something that people can and do useful use.
Hrm. If I have a good module system, and symbols are "lightweight",
that is, they don't have plists or dynamic values, then what
advantages would be gained by adding packages? Maybe I've missed it,
but all the advantages seem to depend on either plists or dynamic
values (which are, it seems to me, really examples of the same
thing). I fully grant that if you have either of those, then packages
become an absolute necessity. But if you don't then what would
packages give you that a module system doesn't?
Thomas
·········@becket.net (Thomas Bushnell, BSG) writes:
> I fully grant that if you have either of those [plists or dynamic
> values], then packages become an absolute necessity. But if you
> don't then what would packages give you that a module system
> doesn't?
Is this a trap? I could just imagine the response I'd get from you if
I actually answered this question yet again.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> ·········@becket.net (Thomas Bushnell, BSG) writes:
>
>
> > I fully grant that if you have either of those [plists or dynamic
> > values], then packages become an absolute necessity. But if you
> > don't then what would packages give you that a module system
> > doesn't?
>
> Is this a trap? I could just imagine the response I'd get from you if
> I actually answered this question yet again.
Your answer is "without plists or dynamic values, you can't do
symbolic programming", but I don't believe that's true.
Thomas
·········@becket.net (Thomas Bushnell, BSG) writes:
> Your answer is "without plists or dynamic values, you can't do
> symbolic programming", but I don't believe that's true.
*scratches head*
Heh. Oh well. I guess it's not worth trying to convince someone of
something they didn't bother to listen to in the first place.
I suppose I'm done with this thread now.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> ·········@becket.net (Thomas Bushnell, BSG) writes:
>
> > Your answer is "without plists or dynamic values, you can't do
> > symbolic programming", but I don't believe that's true.
>
> *scratches head*
>
> Heh. Oh well. I guess it's not worth trying to convince someone of
> something they didn't bother to listen to in the first place.
You missed my point.
I'm asking not why plists and dynamic values are important. I take it
you think they are essential to symbolic programming, and I don't, but
that's not the point I'm asking about.
My question is: in a language (like Scheme) which lacks plists and
dynamic values, and given a decent module system, how, exactly, are
adding packages to the mix an asset. Kent's examples almost all
revolve around using GET (and thus are only relevant if you have
plists); other people have mentioned SYMBOL-VALUE (and thus only
relevant if you have dynamic values).
Now, if you think that even in a language like Scheme, with modules
but without plists and dynamic values packages are of importance (for
symbolic programming or anything else), I'm very interested in
concrete examples... If you have something concrete to suggest, I'm
all ears! But just saying "it's essential for symbolic computation"
is really not a very concrete answer.
Thomas
·········@becket.net (Thomas Bushnell, BSG) writes:
> Hrm. If I have a good module system, and symbols are "lightweight",
> that is, they don't have plists or dynamic values, then what
> advantages would be gained by adding packages?
In none of my arguments have I meant to suggest that either plists or
dynamic values are in any way important to me. You should understand
that _all_ of my arguments are about OBJECT IDENTITY only.
> Maybe I've missed it,
> but all the advantages seem to depend on either plists or dynamic
> values (which are, it seems to me, really examples of the same
> thing).
No, these facilities have been used only incidentally as exemplars of
the general notion of object identity in data.
Even if symbols had no plists and you had only hash tables, there is
still a difference in the operation of
(defun get-color (x)
(gethash x *color-table*))
when x is a symbol from one package or x is a symbol from another package
and x has no intrinsic slots at all.
> I fully grant that if you have either of those, then packages
> become an absolute necessity. But if you don't then what would
> packages give you that a module system doesn't?
Separation of data from one application to another.
Modules are about program separation, not data separation.
Data is about identity, nothing more.
This notion of slots is utterly and completely orthogonal to the problem.
Kent M Pitman <······@world.std.com> writes:
> Even if symbols had no plists and you had only hash tables, there is
> still a difference in the operation of
> (defun get-color (x)
> (gethash x *color-table*))
> when x is a symbol from one package or x is a symbol from another package
> and x has no intrinsic slots at all.
Sure, but then I wonder:
When do you actually want to have two different packages, with no
antecedent connections between them, contributing to the same hash
table?
If they *do* have an antecedent connection, then what is the nature of
the connection?
In other words, it seems really clear to me how to do all this kind of
data manipulation; one simply needs to represent data by more than
plain symbols--but it's still pretty darn easy.
Thomas
·········@becket.net (Thomas Bushnell, BSG) writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Even if symbols had no plists and you had only hash tables, there is
> > still a difference in the operation of
> > (defun get-color (x)
> > (gethash x *color-table*))
> > when x is a symbol from one package or x is a symbol from another package
> > and x has no intrinsic slots at all.
>
> Sure, but then I wonder:
>
> When do you actually want to have two different packages, with no
> antecedent connections between them, contributing to the same hash
> table?
When you use symbols as all-purpose data containers.
The very simplest of these would be:
(in-package "PERSON")
(defun person-named (name)
(find-symbol name "PERSON"))
(defun person? (thing)
(and (symbolp thing)
(eq (find-symbol (symbol-name thing) "PERSON")
thing)))
(defun count-people (list) (count-if #'person? list))
(in-package "FLOWER")
(defun person-named (name)
(find-symbol name "FLOWER"))
(defun flower? (thing)
(and (symbolp thing)
(eq (find-symbol (symbol-name thing) "FLOWER")
thing)))
(defun count-flowers (list) (count-if #'flower? list))
(in-package "OTHER")
(count-flower (list (make-flower "ROSE") (make-person "ROSE")))
=> 1
> If they *do* have an antecedent connection, then what is the nature of
> the connection?
As with all dentity issues, one shares predicates and constructors and
annotators and mutators and whatever with others who have a similar object.
For example, a CLIM window and an X Window may not be the same kind of
thing because the people who conceptualized them gave them different kinds
of attributes. I start with an initial hypothesis of separation, but my
eyes are always open to the option of sharing. So if I notice someone else
has a person representation, and I'm operating on people, I might ask
"can I share that" or should I start over.
None of the answers to these questions would be different if you were talking
about instances of non-symbols.
The usefulness of symbols, however, is that you get automatic bookkeeping of
identity and a simple way of referring to things. Talking about JOE is easier
than talking about #<PERSON SSN=555-55-5555 32434>. As noted in much earlier
AI work, symbols are visually evocative, they are a natural way people want
to express themselves, they accomodate circularity, they take a natural bias
for sharing of identity among same-named things into account, etc. Also as
has come up in practice, sometimes two people use the same symbol for
incompatible purposes, and good data separation among such worlds is critical
to not having to rewrite lots of code when those two worlds are co-loaded.
> In other words, it seems really clear to me how to do all this kind of
> data manipulation; one simply needs to represent data by more than
> plain symbols--but it's still pretty darn easy.
I don't know what "more than plain symbols" is, but if it means
#<PERSON SSN=555-55-5555 32434> or #S(PERSON :SSN "555-55-5555")
and if referring to a list containing this person twice means writing
(#1=#S(PERSON :SSN "555-55-5555") #1#) instead of (JOE JOE), then I
think it suffers something in the translation.
If instead you mean that packaged symbols are more than plain symbols,
then the nice thing is that in isolation, packaged symbols look like plain
symbols, and the visual strangeness of even the pkg: prefix comes up exactly
and only in a place where the simple model of symbols would break down.
Rather than (X:FRED Y:FRED) one cannot write simply (FRED FRED) unless one
invents some additional datum that rides along side saying (X Y), or unless
one makes the list contain ((X FRED) (Y FRED)) and each of these have grave
problems.
I'm a little tired at this point of offering worked examples and having people
take potshots. I want someone to take some of the worked examples of what
I've written and show me how some of those examples would both be simpler in
a single namespace language and still also involve the use of symbols as the
core means of representing. I'm not asserting other objects can't be used,
I'm just saying that if symbols get used, they need to be this complex in
nature. And so far, I've not seen anyone taking the time to offer
any rebuttal in code, only in vagueries of words.
Kent M Pitman <······@world.std.com> writes:
> Talking about JOE is easier than talking about #<PERSON
> SSN=555-55-5555 32434>.
But I don't get JOE, of course, I get something like PERSON:JOE and
FLOWER:ROSE.
Why is this radically better than (person . joe) and (flower . rose)?
Oops, Scheme people will get made at me for my habit of using improper
lists. :) (person joe) and (flower rose) then.
In other words, it seems to me that if I had an application where I
needed this, I could simply make a hash table, uniquify such pairs,
and proceed.
> > In other words, it seems really clear to me how to do all this kind of
> > data manipulation; one simply needs to represent data by more than
> > plain symbols--but it's still pretty darn easy.
>
> I don't know what "more than plain symbols" is, but if it means
> #<PERSON SSN=555-55-5555 32434> or #S(PERSON :SSN "555-55-5555")
> and if referring to a list containing this person twice means writing
> (#1=#S(PERSON :SSN "555-55-5555") #1#) instead of (JOE JOE), then I
> think it suffers something in the translation.
No, it means referring to things by, say, the sorts of lists I used
above.
> If instead you mean that packaged symbols are more than plain symbols,
> then the nice thing is that in isolation, packaged symbols look like plain
> symbols, and the visual strangeness of even the pkg: prefix comes up exactly
> and only in a place where the simple model of symbols would break down.
> Rather than (X:FRED Y:FRED) one cannot write simply (FRED FRED) unless one
> invents some additional datum that rides along side saying (X Y), or unless
> one makes the list contain ((X FRED) (Y FRED)) and each of these have grave
> problems.
So that's clearly what my solution is supposind I would do. Please
entertain me; what is the "grave problem" with using (X FRED) instead
of X:FRED? I have to work out a uniquification rule, and so forth (or
just use equal instead of eq), and it Just Works.... doesn't it?
> I'm a little tired at this point of offering worked examples and
> having people take potshots.
I'm really not trying to take potshots; I'm trying to understand what
exactly is being gained through the package mechanism that can't be
gained through a module system. I want to "push back" at your
assertions, because they don't jive with my experience and intuitions,
but not because I want to win some debate. If you like, I want to make
you give the strongest case possible. :)
> I want someone to take some of the worked examples of what I've
> written and show me how some of those examples would both be simpler
> in a single namespace language and still also involve the use of
> symbols as the core means of representing. I'm not asserting other
> objects can't be used, I'm just saying that if symbols get used,
> they need to be this complex in nature. And so far, I've not seen
> anyone taking the time to offer any rebuttal in code, only in
> vagueries of words.
Oh, I agree completely that this kind of complexity is inherent in
doing certain kinds of symbolic computation. But that complexity is a
matter of writing about four teeny little hash table functions; why
not just do that when you want it? I don't have any objection to
having them in a library either. If that's what a "package system"
is, then Scheme can have one in about five minutes anytime it's
wanted.
But the CL package system is more than just these kinds of relativized
hash tables and such. It includes a certain style of interaction with
the reader, and the complex rules for shadowing and such. This is
very important in CL, and it's this stuff that I don't see the
inherent value for.
It's also not clear to me is why the print syntax is *so* important;
why using 2-element lists instead of package/symbolname pairs is such
a lose; and why one can't do "symbolic computation" without such
"symbols" entirely--even structs actually work, and if you want the
print syntax to be prettier, that's a teeny job.
Thomas
·········@becket.net (Thomas Bushnell, BSG) writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Talking about JOE is easier than talking about #<PERSON
> > SSN=555-55-5555 32434>.
>
> But I don't get JOE, of course, I get something like PERSON:JOE and
> FLOWER:ROSE.
That is not true. Most of the time, you can just talk about JOE, and
have it automagically mean the right thing, i.e. either PERSON:ROSE
or FLOWER:ROSE, depending on context. That is the very nice thing
about packages: It allows people to write their code most of the time
as if they owned the universe, indeed, they don't even have to know
about the package system at all, and yet I can use that package system
to keep their system from clashing with other systems.
For example, someone writes the following into a file:
;; The use of the symbols plist is only accidental here, any kind of
;; globally shared place will do...
(defun name-person (symbol name)
(setf (get symbol 'name) name))
I've also got another file that uses "the" name property of symbols
for something else entirely.
In order to prevent clashes, I can easily wrap the loading and/or
compilation of said file in the following way:
(defpackage "PERSON-STUFF"
(:use :CL)
(:export
;; Whatever you want exported, possibly next to nothing
))
(let ((*package* (find-package "PERSON-STUFF")))
;; Works similarly for
(load "person-stuff.lisp"))
Now all the code in person-stuff.lisp that talks about NAME will
transparently refer to the symbol PERSON-STUFF::NAME, instead of some
other symbol with the symbol-name NAME, which I might want to prevent
from happening.
OTOH I can also take the view that I want to share the symbol with the
code in person-stuff.lisp, and set up my package structure in order
for PKG2::NAME and PERSON-STUFF::NAME to refer to the same symbol.
And in reality, I don't normally have to resort to the "bind package
from the outside" hack/solution, since people usually just stick
(defpackage "PERSON-STUFF"
(:use :CL)
(:export
;; Whatever you want exported, possibly next to nothing
))
(in-package "PERSON-STUFF")
forms into their files, all by themselves. But again, that isn't
necessary. One of the important points about the package system is
that it is non-invasive, i.e. it doesn't require much in the way of
cooperation and changes from user's code, either my own, or, more
importantly other people's code, whose existance I might not even be
aware of.
> Why is this radically better than (person . joe) and (flower . rose)?
> Oops, Scheme people will get made at me for my habit of using improper
> lists. :) (person joe) and (flower rose) then.
>
> In other words, it seems to me that if I had an application where I
> needed this, I could simply make a hash table, uniquify such pairs,
> and proceed.
a) Your "solution" requires that all participants in such a scheme
agree beforehand that they are going to use your it. It is hard
to change non-cooperative code to cooperative code after the fact.
b) It is again not trivial to have (person joe) and (employee joe)
be considered the same joe afterall. I.e. you get complete
isolation, but at the cost of making it very expensive to break
that isolation. This point is not about after-the-fact merging of
symbols, BTW. Making (person joe) and (employee joe) refer to the
same joe, i.e. to be considered equivalent, requires special-casing
in the equality predicate, since uniquification can't make the two
lists eq.
In order to make that slightly more palatable -- you want to allow
eq to be used to test for the equality of "symbols", which also
allows references to symbols be cheap pointers and not expensive
consed data -- you could of course map your lists to some other
uniquified data structure (possibly gensymed symbols, and/or
freshly consed lists, whatever). Of course now you are well on
your way to reinventing packages, but badly, since you are not
using specially optimized data-structures, nor do you have reader
support for ease of entry.
c) Of course you can encode any kind of datastructure using just lists
and symbols (in fact, if you are really bent on it, you can encode
anything using just lists).
And this can even make sense for something you seldomly use, or are
just prototyping, or there are other overriding reasons why you
want the thing to be encoded with lists.
But just as modern Lisps have come to the conclusion that encoding
strings as lists of symbols is not adequate, and that a specialized
data-structure is in order, for both characters and strings, Lisp
users have also seen that symbols are important enough, and their
usage frequent enough, to warrant their own specialized system.
Any kind of argument that goes "but you can just encode that using
lists and symbols" is just missing the point. It's not about can,
which like turing equivalence is a given, it is about _adequacy_,
which includes such things as effort, performance, readability,
safety, low cohesion, etc.
> No, it means referring to things by, say, the sorts of lists I used
> above.
Again, you'll have to either use the (#1=(PERSON JOE) #1#) reader
syntax, or you'll have to explicitly pass the two lists through your
uniquification function. Otherwise eq doesn't work anymore, with all
the implications that has.
> So that's clearly what my solution is supposind I would do. Please
> entertain me; what is the "grave problem" with using (X FRED) instead
> of X:FRED? I have to work out a uniquification rule, and so forth (or
> just use equal instead of eq), and it Just Works.... doesn't it?
Using equal instead of eq means
a) eq doesn't give me object identity anymore, which among other
things means that all code that ever gets passed my "fake symbols"
must be aware of that, and use equal for all operations, whereas it
could get away with using eq(l) before.
b) all my references to X:FRED, which were just a pointer in CL, now
cost me two cons cells with 3 pointers now,
c) "Identity" on such objects now costs me quite a number of memory
accesses, type- and pointer tests, instead of a simple pointer
compare.
This might be justifiable for a one-off thing, it isn't justifiable
for something that is going to be used all of the time.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@becket.becket.net>, Thomas Bushnell, BSG wrote:
> Kent M Pitman <······@world.std.com> writes:
>> If instead you mean that packaged symbols are more than plain symbols,
>> then the nice thing is that in isolation, packaged symbols look like plain
>> symbols, and the visual strangeness of even the pkg: prefix comes up exactly
>> and only in a place where the simple model of symbols would break down.
>> Rather than (X:FRED Y:FRED) one cannot write simply (FRED FRED) unless one
>> invents some additional datum that rides along side saying (X Y), or unless
>> one makes the list contain ((X FRED) (Y FRED)) and each of these have grave
>> problems.
>
> So that's clearly what my solution is supposind I would do. Please
> entertain me; what is the "grave problem" with using (X FRED) instead
> of X:FRED? I have to work out a uniquification rule, and so forth (or
> just use equal instead of eq), and it Just Works.... doesn't it?
But that's not the same thing: in (LIST 'X:FRED 'X:FRED) the list
contains the same object twice, (LIST (LIST 'X 'FRED) (LIST 'X 'FRED))
doesn't. Sure, you can find workarounds for just about anything,
even in C. But that doesn't mean C supports everything other
languages do, although C programmers often believe that.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
·········@becket.net (Thomas Bushnell, BSG) writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Talking about JOE is easier than talking about #<PERSON
> > SSN=555-55-5555 32434>.
>
> But I don't get JOE, of course, I get something like PERSON:JOE and
> FLOWER:ROSE.
JOE and PERSON:JOE are the same. It is an artifact of the printer that
you can make it print either way. In the FLOWER package, you will see
ROSE and PERSON:JOE. In the PERSON package you will see JOE and FLOWER:ROSE.
> Why is this radically better than (person . joe) and (flower . rose)?
Those are not symbols. This is critical to a representation that says
that conses are containers and symbols are terminals. If terminals are
conses that contain symbols, then it becomes painful programmatically
(not to mention much slower) to detect leafness on recursive descent.
> Oops, Scheme people will get made at me for my habit of using improper
> lists. :) (person joe) and (flower rose) then.
Waste of extra conses, too, then.
> In other words, it seems to me that if I had an application where I
> needed this, I could simply make a hash table, uniquify such pairs,
> and proceed.
You are utterly missing the point here. The data structure design is done
at the time you have no mix of applications. MACSYMA was designed for 20
years before it was ever mixed with any other application in the same address
space. The use of symbols was integrated through 100,000 lines of code
internally to itself, not to mention published papers on its internals, and
researchers world-wide who were familiar with its data structures.
At the point where it was finally dumped into an address space with other
programs, there was no practical hope of saying "oh, look, I have an
application that needs me to redesign its data structures". It's too late.
So either what you are suggesting is that every application MUST do this
whether needed or not (since later redesign is out of the question) or your
proposed solution doesn't work. The package system, by contrast, hides the
packageness utterly out of view as long as you don't mix packages, and only
introduces complexity at the time that you need complexity--when two
applications are joined.
> > > In other words, it seems really clear to me how to do all this kind of
> > > data manipulation; one simply needs to represent data by more than
> > > plain symbols--but it's still pretty darn easy.
> >
> > I don't know what "more than plain symbols" is, but if it means
> > #<PERSON SSN=555-55-5555 32434> or #S(PERSON :SSN "555-55-5555")
> > and if referring to a list containing this person twice means writing
> > (#1=#S(PERSON :SSN "555-55-5555") #1#) instead of (JOE JOE), then I
> > think it suffers something in the translation.
>
> No, it means referring to things by, say, the sorts of lists I used
> above.
Lists are not symbols. You're basically suggesting that an integration
program in a calculus program should change its design from:
(INTEGRATE (SIN X) X 0 3)
to
((CALCULUS INTEGRATE) ((CL SIN) (USER X)) 0 3)
I don't know about you, but I can't even _read_ that simple example clearly,
not just because of nesting but because the nesting is for different purposes.
In the thing Lispers are trained to do, such as:
(+ F (G X) Y)
or [Scheme only]
((F G) (H (M X) 3))
all of the parens mean "functional enclosure". If I have a need for the
stuff you're suggesting, parens sometimes mean "functional enclosure" and
sometimes "namespacing", so I get:
(((FRED F) (FRED G)) ((FRED H) ((FRED M) (FRED X)) 3))
and (a) it looks visually like FRED is an operator, (b) wastes visual space
on something I don't need all the time, and (c) means I need a kind of LEAFP
predicate that can tell on recursive descent that (FRED F) is a terminal
where atoms used to be terminals. I'd at minimum want bracketing to be able
to read this easier, so let's say [...] instead of parens.
(([FRED F] [FRED G]) ([FRED H] ([FRED M] [FRED X]) 3))
Maybe also if [FRED x] were the default, we could suppress FRED showing up
to make it easier to read. So let's say it looks like
(([F] [G]) ([H] ([M] [X]) 3))
Great. So now you've taken a system in which I had used lists and symbols
in a certain way and you have turned it into something where I used lists and
a new thing called a leaf in a certain way, which is effectively the same
except the leafp test is slower than the atom test was. And you've taken a
thing where symbols print as their name and turned it into something where
symbols print as something with no more semantic info than their name but just
take more characters to do it. To me, that is not entirely an improvement.
It doesn't change the shape of anything.
[This use of "shape" may be obscure. I don't mean structural shape, I
mean conceptual shape. It may or may not clarify it for me to refer
to my training in the late Bill Martin's computational lingistics
class at MIT long ago, we used to work in a representation language
called XLMS which used list-like recursive structures and heavy use
of anaphoric interconnection (like #n= and #n# on steroids) to
represent human knowledge. There were symbolic identifiers in these
networks created to name things, and to "ground" them with reality,
but I remember Martin speculating that perhaps it didn't actually
matter what the names were because to really understand something, it
had to be so connected with the universe that there may only have
been one possible set of interconnections, and really all that was
needed was shape. I guess the reason I have to mention this side
trip is to motivate my use of the word "shape" in the following
statement, since probably it's an otherwise obscure use.]
> > If instead you mean that packaged symbols are more than plain
> > symbols, then the nice thing is that in isolation, packaged
> > symbols look like plain symbols, and the visual strangeness of
> > even the pkg: prefix comes up exactly and only in a place where
> > the simple model of symbols would break down. Rather than (X:FRED
> > Y:FRED) one cannot write simply (FRED FRED) unless one invents
> > some additional datum that rides along side saying (X Y), or
> > unless one makes the list contain ((X FRED) (Y FRED)) and each of
> > these have grave problems.
>
> So that's clearly what my solution is supposind I would do. Please
> entertain me; what is the "grave problem" with using (X FRED) instead
> of X:FRED?
Timing.
You have to always do it. The point of symbol design is not to
write systems that now interface to something else that might ultimately,
without redesign, accomodate interface to something else.
Your remarks seem to take a notion that we used to take 20 years ago that
there were "applications to be joined with others" and "applications that
won't". Over time, I have come to the conclusion that the proper names for
these sets are "applications that it is not worth wasting time on ever
in your life" and "things that will succeed and become useful to someone".
Because when things that become successful do, statistically, get connected
to other things in ways they don't anticipate. It is the job of the language
designer to think about this exactly because programmers often do not.
Because otherwise, people complain that the language boxed them into a
corner. (They do anyway, but one should reduce their need for this where
anticipatable, and this is such a case.)
> I have to work out a uniquification rule, and so forth (or
> just use equal instead of eq), and it Just Works.... doesn't it?
"Just" using EQUAL instead of EQ is no small change.
EQ is often compiled open as a single instruction. EQUAL, being
recursive, is rarely compiled open and is usually a minimum of an
order of magnitude slower. It may not have to recurse long if the
object to be compared is not EQUAL, but it can take quite a while.
> > I'm a little tired at this point of offering worked examples and
> > having people take potshots.
>
> I'm really not trying to take potshots; I'm trying to understand what
> exactly is being gained through the package mechanism that can't be
> gained through a module system. I want to "push back" at your
> assertions, because they don't jive with my experience and intuitions,
> but not because I want to win some debate. If you like, I want to make
> you give the strongest case possible. :)
But if you offered a simple example, I could tell you in concrete terms
where the bug would occur.
I don't enjoy being "made" to make arguments.
Moreover, I need something from this discussion, too. I need to understand
what you think you want. It may be that I am wrong, and this will not be
elicited by your simply pushing me harder and harder.
Conversation is give and take, and you are not giving. Moreover, you
have self-identified as trying to manipulate me, and I do not appreciate
that whatsoever. This will hamper my desire to respond further to you
in conversation.
Because mine is not the only opinion here and much though I have a desire
to offer my arguments, I have no desire to offer them against a vacuum.
I can't even tell if you are hearing me unless I see you do a more elaborate
example than you do because I can't tell if (a) you are not reading what
I wrote, (b) not thinking hard about it, (c) thinking hard about it but not
articulating a perfectly sound alternate theory. I am not bold enough to
assume "not (c)" on the basis of no information, and while it may seem that
I am headstrong enough to believe there is no other information, that is
simply not true.
I feel a lot like a monkey in a box being prodded right now. "Oh, let's
see if we can make him make a new sound." I do NOT like it.
[Rest of message not responded to because I did not choose to read farther.]
> > I want someone to take some of the worked examples of what I've
> > written and show me how some of those examples would both be simpler
> > in a single namespace language and still also involve the use of
> > symbols as the core means of representing. I'm not asserting other
> > objects can't be used, I'm just saying that if symbols get used,
> > they need to be this complex in nature. And so far, I've not seen
> > anyone taking the time to offer any rebuttal in code, only in
> > vagueries of words.
>
> Oh, I agree completely that this kind of complexity is inherent in
> doing certain kinds of symbolic computation. But that complexity is a
> matter of writing about four teeny little hash table functions; why
> not just do that when you want it? I don't have any objection to
> having them in a library either. If that's what a "package system"
> is, then Scheme can have one in about five minutes anytime it's
> wanted.
>
> But the CL package system is more than just these kinds of relativized
> hash tables and such. It includes a certain style of interaction with
> the reader, and the complex rules for shadowing and such. This is
> very important in CL, and it's this stuff that I don't see the
> inherent value for.
>
> It's also not clear to me is why the print syntax is *so* important;
> why using 2-element lists instead of package/symbolname pairs is such
> a lose; and why one can't do "symbolic computation" without such
> "symbols" entirely--even structs actually work, and if you want the
> print syntax to be prettier, that's a teeny job.
Kent M Pitman <······@world.std.com> writes:
> Those are not symbols. This is critical to a representation that says
> that conses are containers and symbols are terminals. If terminals are
> conses that contain symbols, then it becomes painful programmatically
> (not to mention much slower) to detect leafness on recursive descent.
So I *did* say that uniquification was a part of the solution. I
do grant that this is an increased cost (perhaps a very high one,
depending on the context).
However, thanks for your reply; I think I now understand what you were
getting at better than I did before.
Kent M Pitman <······@world.std.com> writes:
> Those are not symbols. This is critical to a representation that says
> that conses are containers and symbols are terminals. If terminals are
> conses that contain symbols, then it becomes painful programmatically
> (not to mention much slower) to detect leafness on recursive descent.
So I did mention the need for a uniqueness step (just like one gets
for "free" with symbols--that is, not free, but built in).
However, that doesn't take care of everything, and I thank you for
your comments; they have brought out several issues I had not thought
about in that way before.
Kent M Pitman <······@world.std.com> writes:
> Conversation is give and take, and you are not giving. Moreover, you
> have self-identified as trying to manipulate me, and I do not appreciate
> that whatsoever. This will hamper my desire to respond further to you
> in conversation.
Eek, you've totally misconstrued my point.
It's that I had thought pretty seriously about the topic, and
concluded that packages don't add much if you already have modules and
other relevant facilities. I was asking you to give some of your
examples and reasoning that conclude the following.
When I criticized particular examples, it was not to take a "pot
shot", but rather because I thought those examples did not quite prove
your point, and my goal is to see if that point is really true or
not. (I'm still not sure, but now I see more of the depth of the
issue than I did at first.)
When I said "I want to provoke you to make the strongest possible
argument", that's not a desire to manipulate! I'm sorry if that was
an unhelpful way for me to express my desire. I was just saying what
what seem to be pot-shots are not pot-shots, but actually cases where
it seemed to me that your argument was weak in a relevant way.
> Because mine is not the only opinion here and much though I have a desire
> to offer my arguments, I have no desire to offer them against a vacuum.
> I can't even tell if you are hearing me unless I see you do a more elaborate
> example than you do because I can't tell if (a) you are not reading what
> I wrote, (b) not thinking hard about it, (c) thinking hard about it but not
> articulating a perfectly sound alternate theory.
I'm certainly doing A and B; I'm a little too modest to do C.
> I feel a lot like a monkey in a box being prodded right now. "Oh, let's
> see if we can make him make a new sound." I do NOT like it.
Eek, that was *not* my intention. I want to understand the subject,
but that takes more than just taking someone's word for it. That's
why I argue back--because I want to test the *argument* (not you), and
to understand.
I'm sorry you abandoned reading just because you misunderstood my
intention.
Thomas
Kent M Pitman <······@world.std.com> writes:
> Because mine is not the only opinion here and much though I have a desire
> to offer my arguments, I have no desire to offer them against a vacuum.
But there isn't a vacuum here. I read this
newsgroup every day with the hope of reading code
or practical examples of CL solutions and I must
say that your last three posts (that I have
bookmarked) have given me a lot of food for
thought.
It's considered bad netiquette to post "me too" or
"I agree" on USENET, so I don't, but maybe this
post makes you feel somewhat better. You helped at
least one newby to better understand CL.
--
Eduardo Mu�oz
"Eduardo Mu�oz" <···@jet.es> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Because mine is not the only opinion here and much though I have a desire
> > to offer my arguments, I have no desire to offer them against a vacuum.
>
> But there isn't a vacuum here. I read this
> newsgroup every day with the hope of reading code
> or practical examples of CL solutions and I must
> say that your last three posts (that I have
> bookmarked) have given me a lot of food for
> thought.
I must say, I've also quite enjoyed some of your posts in this thread,
Kent. I can definitely see why you feel you're talking into a big
void, and I've been wondering when your posting stamina was going to
run out. But you have offered a few gems that have kept me slogging
through an otherwise-tiresome thread (I think that's a good thing :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Maybe you get the difference, if you think for a moment about a
filesystem that is flat (and has no cwd). In a way, that is no
problem: instead of files /a/b/c/file1 and /u/v/z/file1 you would
write a.b.c.file1 and u.v.z.file1. So there is certainly a way to work
around that hindrance, but it is inconvenient, abd it would certainly
influence the way you work and think about nameing files.
Andreas
--
Wherever I lay my .emacs, there�s my $HOME.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> "Joe Marshall" <·············@attbi.com> writes:
>
> > READ causes noticable side effects. This can create dependencies
> > on the order in which things are read.
>
> EVAL and/or COMPILE-FILE causes noticeable side-effects too. This
> creates dependencies on the order in which Scheme expressions can be
> processed.
Woah!!! Who said anything about Scheme?
I'm just pointing out the problems I have with the Common Lisp
package system, not proselytizing.
So, back to the discussion... I sort of expect EVAL to have
side effects. It would be *nice* if COMPILE-FILE did *not* have
side effects unless there are the appropriate `eval-when' forms
in it (modulo macros, etc.)
> > Where it *was* a problem was on the Lisp Machine. When you opened
> > a file in Zmacs, it would parse the file mode and it would
> > parse some of the file contents. It would attach properties to
> > the symbols mentioned in the file.
>
> I'm familiar with the problem you're talking about, but you can't
> blame this on the package system. I don't think this is a fair
> criticism. The Zmacs editor chose to put things on the property list
> of symbols prematurely and got in trouble.
I think I'll still blame this on the package system. If Common Lisp
did not have a package system (let's imagine that namespace conflicts
don't occur and we can intern everything in one package), then Zmacs
would have no problem at all attaching properties to symbols.
Putting properties on symbols isn't a problem. It's interning
the symbols for the sole purpose of putting properties on them that
is causing the problem. And the interning itself wouldn't be a
problem if the packages were set up correctly beforehand. It all
leads back to the package system. (Admittedly, Zmacs shouldn't be
using READ anyway. I once made a file with -*- #.(si:%halt) -*-
in the header....)
> > When you were browsing code, you might open a file that was
> > in a package that was not yet defined. Well, the package became
> > defined and a slew of symbols from the file would get interned
> > in it. Unfortunately, it was unlikely that the package was
> > correctly set up, so when you went to evaluate any code it
> > wouldn't work, or when you went to fix the packages, you'd run
> > into thousands of name conflicts.
>
> Just because someone can design a problem for which symbols ought not
> be used and use symbols does not make symbols a bad datastructure.
>
> I likewise had problems with what Zmacs did, but I attribute the
> problem very, very differently.
I see where you are coming from, but I disagree. Zmacs wanted to
associate properties with names, i.e. establish a mapping between
a sequence of characters and a value. The sequence of characters
has the syntax of a symbol (by definition!), so it seems that symbols
would be the right thing to use.
Manipulating a structure full of symbols and lists (a lisp source file)
seems to me to be the epitome of symbolic processing, yet I can't use
symbols?
> > So, on to more obscure problems. You can't use `forward references'
> > to symbols that don't exist in packages that don't exist (yet).
> > In your init file, you'd *like* to be able to customize some
> > parameters before you start building the system. Perhaps you have
> > some macros that are parameterized, whatever. As an example, I
> > once worked at a place that had a `verbosity' switch that I wanted
> > set.
> >
> > The obvious thing is to write (setq utility::*verbosity* t)
> > but the utility package isn't loaded yet. Never mind that the
> > utility package *will* be there when I call this function, it
> > isn't there when I *read* the code. Instead I write:
> > (let* ((utl-pkg (find-package :utility))
> > (verbosity (intern (symbol-name :*verbosity*) utl-pkg)))
> > (setf (symbol-value verbosity) t))
> >
> > The same goes for functions that I want to call. I can't
> > write (progn (load "java-tools.lisp") (java-tools:make-all))
> >
> > The way around this problem is to write a function that
> > defers interning until runtime. Then you can write
> > (progn (load "java-tools.lisp") (funcall-in-package :java-tools
:make-all))
>
> I usually did:
>
> (load "java-tools.lisp")
> (java-tools:make-all)
This is obviously not quite kosher in a file.
> as two different forms. In the few cases where this wasn't possible, I
did:
>
> (progn (load "java-tools.lisp")
> (eval (read-from-string "(java-tools:make-all)")))
>
> or
>
> (progn (load "java-tools.lisp")
> (funcall (or (find-symbol "MAKE-ALL" "JAVA-TOOLS")
> (error "JAVA-TOOLS:MAKE-ALL is not defined."))))
>
> Hardly a major problem. And it doesn't require use of any non-standard
> operators.
No, it isn't a `major problem', and as I pointed out you can write
a `funcall-in-package' form that allows you to
(funcall-in-package :java-tools :make-all), but it *is* a nuisance.
> > The package system allows me to `split' names. I can have
> > my symbol FOO be different from your symbol FOO. It doesn't
> > allow me to `join' names.
>
> > I cannot have my symbol BAR be
> > the same as your symbol FOO. (Or perhaps more illustrative,
> > I can't have `JRM:ORIGINAL-MULTIPLE-VALUE-BIND' be the same
> > as `CL-USER:MULTIPLE-VALUE-BIND'.) On the lisp machine, you
> > actually *could* do this by forwarding the memory, and it
> > comes in handy on occasion.
>
> This is a legitimate gripe. However, I believe CL can rise above it.
> I see it as an API problem, not a data structure problem.
I'm not sure that it makes a difference what the nature of the problem
is. And I'd love to see CL rise above it. Whether by `fixing',
`adding functionality', or `replacing' the package system is somewhat
immaterial. If we can keep existing code from breaking *and* eliminate
some (all?) of the `misfeatures' of the current package system, I'd
be happy.
> > Finally, a really nasty one. The `topology' of the package
> > structure is a global resource. When we were building a new
> > Lisp machine, we had a brand new compiler. Obviously, it goes
> > in the `compiler' package. Well, on the old machine, there
> > already was a compiler in the compiler package. So we had
> > to load the compiler into a different package.
>
> I don't see any problem here that adding more power to the package
> system wouldn't fix. In particular, original Zetalisp had
> hierarchical packages. Symbolics Genera usefully expanded on this by
> having "package universes" associated with Syntax. Symbolics Genera
> had about 5 to 7 syntaxes (package universes) loaded into the same
> core image at the same time, depending on the configuration. I wrote
> the code that maintained that separation. I never got complaints from
> amyone saying the implementation had major technical problems. Most
> people were surprised that Zetalisp and Common Lisp were able to be
> co-resident at the same time, given they had needs for packages to be
> called different things.
I solved this by adding `package-environments' (with triple colons to
name them!). It could get pretty hairy. In one package-environment,
interning the name "FOO" in package "BAR" would yield 'FOO::BAR, yet
in another interning the name "FOO" in package "BAR" would yield
'SYS:BAR. There were degenerate cases where you could end up with
a symbol associated with a `non-existant' package.
It *did* solve the problem, though. But only at the expense of
causing a serious amount of complexity. The intent was to abandon
this `solution' as soon as we had bootstrapped the new environment.
> > Now I realize that name conficts are a problem (look at emacs).
> > But I don't think the solution is to hack the READER. With
> > a little careful thought, I'm sure that a better way could be
> > found that defers identifier->symbol mapping until later in
> > the game.
>
> Yes, those may be possible workarounds in some of the cases you've
> mentioned. I'm not sure they exhaust the space of possible workarounds,
> nor that the presence of such a workaround is a proof that what CL does
> is bad.
The fact that you call them `workarounds' indicates that there is something
to be `worked around'. But this isn't meant to criticize CL. On the
contrary, the existance of the API to the package system makes it
possible. (Consider trying to fix an analagous problem in C++)
> I have not at any time said modules are something people should not use.
> I've said that packages are something that people can and do useful use.
Agreed. I use them myself. I just wish there were something better.
> What you're relating is very much akin to the issue of early vs late
> binding in declarations. Sometimes one adds a declaration because they
> know something about data and they want early (compile time) processing
> of that information. Sometimes one knows something about a name and
> one uses packages to carry this information. Sometimes one doesn't know
> what the name-to-package association is, and there are ways of
accomodating
> that. But often one does know.
>
> In
> (defmacro foist (x) `(car ,x))
> there is no material change in knowledge between read time and macro
> expansion time such that delaying the semantic attachment of CAR's meaning
> will do anything other than make it more difficult to figure out what
symbol
> is what. So most of the problems to do with symbols and macros might as
well
> be sorted out at read time as at macro expansion time.
I'd assert the opposite: most of the problems to do with symbols and macros
might as well be sorted out at macro expansion time (or even later).
You hit the nail right on the head when you drew an analogy between
this and the issue of `early' vs. `late' binding. I'd like to see
symbols be `late bound' as well.
> In the case you describe, if I follow you correctly, and I kind of
> doubt I do totally, you have some weird situation where your compile
> time packages and runtime packages are not aligned. (Note that CL
> says this is not valid CL, so you are on your own.)
Exactly! The package system cannot accomodate differences between
run-time and compile-time package hierarchies. I think that rather
than `outlawing' this case, it would be preferable to remove the
requirement.
> In general, I think the
> problem is more that CL does not seek to handle this problem than that
> CL would not be capable of handling this problem with available data
> structures if it chose to provide you the necessary operators. I don't
> see a data structure problem here; perhaps an API weakness. But new APIs
> can be written without changing the language spec.
Well, I'm not suggesting a change to the language spec. I just want
to not see spurious `name conflict' errors.
"Joe Marshall" <·············@attbi.com> writes:
> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@shell01.TheWorld.com...
> > "Joe Marshall" <·············@attbi.com> writes:
> >
> > > READ causes noticable side effects. This can create dependencies
> > > on the order in which things are read.
> >
> > EVAL and/or COMPILE-FILE causes noticeable side-effects too. This
> > creates dependencies on the order in which Scheme expressions can be
> > processed.
>
> Woah!!! Who said anything about Scheme?
This whole discussion of packages came from a discussion of modules vs
packages which came from a discussion of what symbol processing is which
came from a discussion of what is criterial to a lisp which came from a
discussion of whether Scheme is a Lisp... or so I thought. Wasn't it
obvious. ;)
Ok, sorry for misjudging your sense of context. My reply was probably
out of frame if you weren't in the same frame of reference...
> I'm just pointing out the problems I have with the Common Lisp
> package system, not proselytizing.
>
> So, back to the discussion...
Heh.. Ok, we'll resynch as best we can.
> I sort of expect EVAL to have
> side effects. It would be *nice* if COMPILE-FILE did *not* have
> side effects unless there are the appropriate `eval-when' forms
> in it (modulo macros, etc.)
If I had it to do over again, I would vote against any statement that
COMPILE-FILE has no side-effects. Reader effects are the least of it.
EVAL-WHEN is the major issue, and we maintain the fiction that the compile
time environment is somehow detached from the runtime environment, but that
isn't true in most lisps. The practical effect is that most people who do
very reasonable things at compile time with the compile time environment
have to worry they are cheating in various subtle ways.
I agree that the package issue is complex, but so is any conversation
that allows indirection. The battle against complexity is not lost
merely because you have to engage complex lingo to accomodate it; it
is lost when you insist that the problem will go away if you fail to
evolve complex lingo.
> > > Where it *was* a problem was on the Lisp Machine. When you opened
> > > a file in Zmacs, it would parse the file mode and it would
> > > parse some of the file contents. It would attach properties to
> > > the symbols mentioned in the file.
> >
> > I'm familiar with the problem you're talking about, but you can't
> > blame this on the package system. I don't think this is a fair
> > criticism. The Zmacs editor chose to put things on the property list
> > of symbols prematurely and got in trouble.
>
> I think I'll still blame this on the package system. If Common Lisp
> did not have a package system (let's imagine that namespace conflicts
> don't occur and we can intern everything in one package), then Zmacs
> would have no problem at all attaching properties to symbols.
As nearly as I can tell, this argument comes down to what in legal terms
would be called an "attractive nuisance". That is, by virtue of having the
data structure available, it seems to invite use in some cases.
The reason I think the editor is "special" is that code to be edited
is not code in core. It stands at the brink and is really just a huge
large string in stringquotes. I regard your bug the same as if
someone had written some tool that scans files and was interning
symbols it found in stringquotes or comments. There are very
dangerous things that one finds quoted and there is a reason that
evaluation is suppressed. Programs which have only a superficial
understanding have no business doing what you are suggesting oughtt to
be the right answer in a universe with packages but ought not be the
right solution in a universe without packages.
The fact is that the Zmacs solution fell down on several other points which
include:
(a) File contains (defun #+FOO a #-FOO b ...)
because not only might I still need to edit that definition, it has
multiple names. It would be a design error even to assume you can
do (MEMBER :FOO *FEATURES*) because you don't know whether I will do
(let ((*features* (adjoin :foo *features*))) (load "thefile.lisp"))
and so you don't know that the "edit time" environment is the
environment of choice for processing the file. This will affect more
than just packages and so is a pervasive feature of the language not
corrected by replacing packages with modules.
(b) myfile.lisp.7 and myfile.lisp.8 contain incompatible versions of
definitions, or even the definition is missing in one or the other.
Really good editing tools (not sure if such exist) will model these
issues; but my point is that it should not be surprising when an editor
does stupid things if it doesn't use a representation adequate to
understanding the real situation. It violates Pitman's 2-bit rule,
that says when you have two bits of information, you should use at least
two bits to represent it.
(c) It doesn't address even acl-foo.lisp vs lw-foo.lisp when I go to
edit foo. It would think there are two defintiions and would not know
that only one will get loaded in the dynamic flow of code.
(d) It doesn't address the possibility that I am editing code for Scheme
or some other language that merely looks like Common Lisp (such as
Maclisp) that doesn't treat : specially.
You know, I had a similar problem with Zmail a few years back when I revived
my old mail files (from the mid 1980's) from backups and it tried to parse
and intern all the domain names. You may or may not be aware (heh) that
the host names have changed since then. I got a lot of failed parses for
missing hosts like MIT-MC.ARPA or even PLANTAIN.SCRC.Symbolics.COM and it
was a mess. Does this mean the domain name system is wrong? Or does it mean
that some editing programs that are not actually trying to talk to the net
yet shouldn't be prematurely doing host lookup just based on the fact that
they saw some plausible looking text go by? Because I think the latter.
> Putting properties on symbols isn't a problem.
When the thing to be represented _is_ a symbol.
I claim that FOO:X in text in an editor buffer is _not_ a symbol. It's a
piece of text that if parsed at a particular point in time would be a symbol.
This very discussion contains references to some package FOO with symbol
X that an editor would be in error to put properties on because it's a
hypothetical symbol not related to anything that someone doing Meta-.
(find function definition) should be expecting to find.
> It's interning
> the symbols for the sole purpose of putting properties on them that
> is causing the problem.
I won't expound in detail upon the philosophical issues here of what
"them" are and whether you've made a definite reference. I'll just
say that FOO is used in a lot of conversations, and putting properties
on FOO in a Scheme-like package-free system will definitely lose.
Putting properties on a CL package will mostly work but _only_ if you
do thw work (which no one does, that I know of) to dispense proper
hypothetical names (almost like gensyms, but really just a more
complicated bookkeeping system) to deal with versioning, multiple
sources, etc. Then again, there are still "morning star/evening star"
situations that could come up, where packages thought to be distinct
have to be merged later. And that's messy. But the mess is something
that philosophers have discussed for ages, long before there was Lisp,
and the philosophically sticky problem will not be fixed by a clever
choice of syntax or data layout on our part.
[Mathemeticians reason by reducing a difficult problem to a specific set
of problems with known computational complexity. So they say a problem
is a "traveling salesman" problem even when it has nothing to do with that.
This effectively avoids spinning one's wheels uselessly.
I have, as a career philosopher engaged regularly in this kind of thing,
sought to reduce philosophical problems to problems of known difficulty
in the philosophy domain, and when I find one that is an unresolved paradox,
I do not descend further into it conversationally for the same reasons.
I think philosophers routinely do this, though I don't think they have good
terminology for talking about the fact that they do or the thing it solves.]
> And the interning itself wouldn't be a
> problem if the packages were set up correctly beforehand. It all
> leads back to the package system. (Admittedly, Zmacs shouldn't be
> using READ anyway. I once made a file with -*- #.(si:%halt) -*-
> in the header....)
Ick.
But this makes an interesting point related to this: you'd think when
you saw a symbol like CL-USER or a list like (FOO :USE CL-USER) that READ
would be the obvious parsing function, but it doesn't follow that it's
the correct computational choice. Your arguments about packages are
really analogous to this. No real problem using symbols for what it does,
but assuming that the packages referred to in the file are correctly
seen as the packages in the runtime environment is a stretch...
> > > When you were browsing code, you might open a file that was
> > > in a package that was not yet defined. Well, the package became
> > > defined and a slew of symbols from the file would get interned
> > > in it. Unfortunately, it was unlikely that the package was
> > > correctly set up, so when you went to evaluate any code it
> > > wouldn't work, or when you went to fix the packages, you'd run
> > > into thousands of name conflicts.
> >
> > Just because someone can design a problem for which symbols ought not
> > be used and use symbols does not make symbols a bad datastructure.
> >
> > I likewise had problems with what Zmacs did, but I attribute the
> > problem very, very differently.
>
> I see where you are coming from, but I disagree. Zmacs wanted to
> associate properties with names, i.e. establish a mapping between
"a relationship". The relationship need not be utterly simplistic.
For example, Meta-. doesn't take you directly to a symbol. It first looks
to see if the symbol exists in the current package. If it doesn't, it
applies "package dwim" to find a lookalike to go to. It can also multiple
definitions in varying ways. The relationships have to be explainable
but they don't have to be simple, and the most usable UI behavior does
not come from an overly simple mapping.
> a sequence of characters and a value. The sequence of characters
> has the syntax of a symbol (by definition!), so it seems that symbols
> would be the right thing to use.
"seems like it should work this way" is not a very useful term of art
in programming design. ;) What mankind really learns from programming is
how much more complex the world of the mind is than most people think it is.
> Manipulating a structure full of symbols and lists (a lisp source file)
> seems to me to be the epitome of symbolic processing, yet I can't use
> symbols?
To me, symbolic processing is what you do when you've read that file.
For example, we do macros that way. That's how we got here conversationally.
But prior to loading, we are in text-land. And text land is more complex
for a reason. It is quoted. In text-land the symbol FOO:X and BAR:X may
be importantly, intentionally, different (for some reason of compatibility
with another system or future system) and cannot be merged even though the
environment may know them to be the same. Query Replace (some call it
"Find and Replace") should not assume that replacing FOO:X for Y should
disturb BAR:X just because something is known about the environment unless
you want to say the editor is only good for editing code related to the
environment that is loaded now, and the editor is of no value for editing
future versions of itself or programs written in another language or for
another platform.
> > > So, on to more obscure problems. You can't use `forward references'
> > > to symbols that don't exist in packages that don't exist (yet).
> > > In your init file, you'd *like* to be able to customize some
> > > parameters before you start building the system. Perhaps you have
> > > some macros that are parameterized, whatever. As an example, I
> > > once worked at a place that had a `verbosity' switch that I wanted
> > > set.
> > >
> > > The obvious thing is to write (setq utility::*verbosity* t)
> > > but the utility package isn't loaded yet. Never mind that the
> > > utility package *will* be there when I call this function, it
> > > isn't there when I *read* the code. Instead I write:
> > > (let* ((utl-pkg (find-package :utility))
> > > (verbosity (intern (symbol-name :*verbosity*) utl-pkg)))
> > > (setf (symbol-value verbosity) t))
> > >
> > > The same goes for functions that I want to call. I can't
> > > write (progn (load "java-tools.lisp") (java-tools:make-all))
> > >
> > > The way around this problem is to write a function that
> > > defers interning until runtime. Then you can write
> > > (progn (load "java-tools.lisp") (funcall-in-package :java-tools
> :make-all))
> >
> > I usually did:
> >
> > (load "java-tools.lisp")
> > (java-tools:make-all)
>
> This is obviously not quite kosher in a file.
Sure it is. I don't know what you're talking about. I have files that
say just exactly that. (Well, different function and package names.)
If you mean I can't put "(defun" ... ")" around it, yes, that's so. But
I can put it in a file of its own and just load the file. The file itself
will act like parens.
> > as two different forms. In the few cases where this wasn't possible, I
> did:
> >
> > (progn (load "java-tools.lisp")
> > (eval (read-from-string "(java-tools:make-all)")))
> >
> > or
> >
> > (progn (load "java-tools.lisp")
> > (funcall (or (find-symbol "MAKE-ALL" "JAVA-TOOLS")
> > (error "JAVA-TOOLS:MAKE-ALL is not defined."))))
> >
> > Hardly a major problem. And it doesn't require use of any non-standard
> > operators.
>
> No, it isn't a `major problem', and as I pointed out you can write
> a `funcall-in-package' form that allows you to
> (funcall-in-package :java-tools :make-all), but it *is* a nuisance.
Having seen how smoothly some very, very large systems ported from old
dialects of Lisp to Zetalisp (which was mostly Maclisp compatible) and were
able to interoperate with each other, I disagree.
I was also able to load in Macsyma, rename the Macsyma package, and load in
a later version and use the package system to help me compare results of
old and new systems. But it's worth noting again that even though the package
system let me do this, other parts of the system were not designed for this,
so the system herald kept saying only the more recent version of the system
was loaded. In this regard, I would say the package system was better
engineered to accomodate change in symbol data than most other parts of the
system which were not package-based were designed to accomodate object
identity and renaming...
> > > The package system allows me to `split' names. I can have
> > > my symbol FOO be different from your symbol FOO. It doesn't
> > > allow me to `join' names.
> >
> > > I cannot have my symbol BAR be
> > > the same as your symbol FOO. (Or perhaps more illustrative,
> > > I can't have `JRM:ORIGINAL-MULTIPLE-VALUE-BIND' be the same
> > > as `CL-USER:MULTIPLE-VALUE-BIND'.) On the lisp machine, you
> > > actually *could* do this by forwarding the memory, and it
> > > comes in handy on occasion.
> >
> > This is a legitimate gripe. However, I believe CL can rise above it.
> > I see it as an API problem, not a data structure problem.
>
> I'm not sure that it makes a difference what the nature of the problem
> is. And I'd love to see CL rise above it. Whether by `fixing',
> `adding functionality', or `replacing' the package system is somewhat
> immaterial. If we can keep existing code from breaking *and* eliminate
> some (all?) of the `misfeatures' of the current package system, I'd
> be happy.
You've raised a lot of problems but you haven't said what featurism you
expect. As long as your only complaint is that it can be used wrong, it's
hard to respond to. If you are looking for it to keep you from doing a
certain thing or allow you to do a certain thing, it would be easier to
respond to. As detailed as you've been, I still can't generalize from
your specific examples to anything other than "this isn't good for me"
and so I can't do much to help. Even a guess at what would be better would
again make the discussion concrete for me.
> > > Finally, a really nasty one. The `topology' of the package
> > > structure is a global resource. When we were building a new
> > > Lisp machine, we had a brand new compiler. Obviously, it goes
> > > in the `compiler' package. Well, on the old machine, there
> > > already was a compiler in the compiler package. So we had
> > > to load the compiler into a different package.
> >
> > I don't see any problem here that adding more power to the package
> > system wouldn't fix. In particular, original Zetalisp had
> > hierarchical packages. Symbolics Genera usefully expanded on this by
> > having "package universes" associated with Syntax. Symbolics Genera
> > had about 5 to 7 syntaxes (package universes) loaded into the same
> > core image at the same time, depending on the configuration. I wrote
> > the code that maintained that separation. I never got complaints from
> > amyone saying the implementation had major technical problems. Most
> > people were surprised that Zetalisp and Common Lisp were able to be
> > co-resident at the same time, given they had needs for packages to be
> > called different things.
>
> I solved this by adding `package-environments' (with triple colons to
> name them!).
The Symbolics Genera solution with "syntaxes" having "package universes"
was likewise. CL:::USER:X was what ZL called CL-USER:X and ZL:::USER:X
was ZL-USER:X to ZL.
> It could get pretty hairy. In one package-environment,
We call these syntaxes and simply had a command to move you among them.
Using Set Lisp Syntax ANSI-Common-Lisp would put you in the same mode as
if you had prefixed all symbols with ANSI-CL::: and using ANSI-CL:::CL-USER::X
gets you what ZL calls FUTURE-COMMON-LISP-USER::X.
> interning the name "FOO" in package "BAR" would yield 'FOO::BAR, yet
> in another interning the name "FOO" in package "BAR" would yield
> 'SYS:BAR. There were degenerate cases where you could end up with
> a symbol associated with a `non-existant' package.
You mean with package not found errors, like in any package universe that
was absent a package, no?
> It *did* solve the problem, though. But only at the expense of
> causing a serious amount of complexity. The intent was to abandon
> this `solution' as soon as we had bootstrapped the new environment.
I think in the Symbolics rendition, people hardly even noticed. They only
noticed if they tried to cross-call, which worked, you just had to learn
some detail. We had a good set of operations like FIND-PACKAGE-FOR-SYNTAX,
and stuff like that which were underneath the FIND-PACKAGE for each dialect,
so that most people who stayed inside a package universe never knew there
were all those other incompatible co-resident dialects.
> > > Now I realize that name conficts are a problem (look at emacs).
> > > But I don't think the solution is to hack the READER. With
> > > a little careful thought, I'm sure that a better way could be
> > > found that defers identifier->symbol mapping until later in
> > > the game.
> >
> > Yes, those may be possible workarounds in some of the cases you've
> > mentioned. I'm not sure they exhaust the space of possible workarounds,
> > nor that the presence of such a workaround is a proof that what CL does
> > is bad.
>
> The fact that you call them `workarounds' indicates that there is something
> to be `worked around'. But this isn't meant to criticize CL. On the
> contrary, the existance of the API to the package system makes it
> possible. (Consider trying to fix an analagous problem in C++)
I don't believe people should use a data structure just because it
"looks right". They should use it because it has the right properties,
in fact.
What you are talking about, as nearly as I can tell, is choosing a wrong
operator just because it's cheap and easy and is conceptually on par with
calling read to parse a token even though the token is not offered by its
creator as "a token in lisp syntax". So if the guy types 003 and you get 3,
you have lost information because the reader was not meant to carry this
difference, but it's wrong to blame READ. It's your choice to use READ
that seems wrong.
> > I have not at any time said modules are something people should not use.
> > I've said that packages are something that people can and do useful use.
>
> Agreed. I use them myself. I just wish there were something better.
>
> > What you're relating is very much akin to the issue of early vs late
> > binding in declarations. Sometimes one adds a declaration because they
> > know something about data and they want early (compile time) processing
> > of that information. Sometimes one knows something about a name and
> > one uses packages to carry this information. Sometimes one doesn't know
> > what the name-to-package association is, and there are ways of
> accomodating
> > that. But often one does know.
> >
> > In
> > (defmacro foist (x) `(car ,x))
> > there is no material change in knowledge between read time and macro
> > expansion time such that delaying the semantic attachment of CAR's meaning
> > will do anything other than make it more difficult to figure out what
> symbol
> > is what. So most of the problems to do with symbols and macros might as
> well
> > be sorted out at read time as at macro expansion time.
>
> I'd assert the opposite: most of the problems to do with symbols and macros
> might as well be sorted out at macro expansion time (or even later).
> You hit the nail right on the head when you drew an analogy between
> this and the issue of `early' vs. `late' binding. I'd like to see
> symbols be `late bound' as well.
The problem with this is that while I believe in the concept of late binding,
I want to bind at the earliest time that I as the programmer know the meaning
I intend to apply. And when I write
(defmacro foist (x) `(car ,x))
I know at program design time that the CAR I mean is a particular one.
Waiting to do it later is like saying that all programs should do
(FUNCALL (SYMBOL-VALUE '+) (EVAL '3) (EVAL '4))
because maybe the meanings of + and 3 and so on will change later. I
don't expect they will, so I want to bind earlier. Indeed, and nontrivially,
I might want to write
(FUNCALL #'FUNCALL (SYMBOL-VALUE '+) (EVAL '3) (EVAL '4))
because maybe I want to defer the meaning of funcall until runtime, but
then how will I call funcall. I have to add a FUNCALL. And maybe I should
defer its meaning as well. At some ponit you have to say that I really know
what I mean. And I think the issue is not late binding is good or early
binding is good but "binding at the time we know" is good. There are ways
in CL to delay information; that's what quoting is for. You are repeatedly
remarking that you don't like quoting, but that is to say you don't want to
address the notation that is there for you to use to cause the effect you
want. I can't help you there. Yes, you can make a notation in which
everything is deferred (that's what Scheme does) but then you find that
you have to solve other problems (like that macros have to worry that
symbols they mix and match have no meaning, and you have to resort to
painting them so you don't get them confused).
> > In the case you describe, if I follow you correctly, and I kind of
> > doubt I do totally, you have some weird situation where your compile
> > time packages and runtime packages are not aligned. (Note that CL
> > says this is not valid CL, so you are on your own.)
>
> Exactly! The package system cannot accomodate differences between
> run-time and compile-time package hierarchies. I think that rather
> than `outlawing' this case, it would be preferable to remove the
> requirement.
I think honestly that you were wrong when you said you aren't arguing for
Scheme. Scheme has a solution (with its incumbant problems--they are not
being inconsistent per se, they are just trading one problem for another).
I don't like the problems created by their solution. But you sound like
you would.
> > In general, I think the
> > problem is more that CL does not seek to handle this problem than that
> > CL would not be capable of handling this problem with available data
> > structures if it chose to provide you the necessary operators. I don't
> > see a data structure problem here; perhaps an API weakness. But new APIs
> > can be written without changing the language spec.
>
> Well, I'm not suggesting a change to the language spec. I just want
> to not see spurious `name conflict' errors.
The errors are not spurious. They happen for a reason. I'm sure you
realize this, but I'm not sure you see the significance of realizing this.
Kent M Pitman <······@world.std.com> writes:
> [Mathemeticians reason by reducing a difficult problem to a specific set
> of problems with known computational complexity. So they say a problem
> is a "traveling salesman" problem even when it has nothing to do with that.
> This effectively avoids spinning one's wheels uselessly.
> I have, as a career philosopher engaged regularly in this kind of thing,
> sought to reduce philosophical problems to problems of known difficulty
> in the philosophy domain, and when I find one that is an unresolved paradox,
> I do not descend further into it conversationally for the same reasons.
> I think philosophers routinely do this, though I don't think they have good
> terminology for talking about the fact that they do or the thing it solves.]
As an actual career philosopher here:
Suppose one wants to talk about P, but it looks like one's opinions
about P are going to depend on (say) how one deals with the
other-minds problem. And the other-minds problem is a famous rats
nest.
So one thing to do is called "bracketing". You bracket the
other-minds problem, which means to leave it unexplored for the
moment, and see how far you can get in talking about P without
worrying about the deeper harder problem. This is close to the
operation you describe above.
However, thinking about the other-minds problem is part of the bread
and butter of philosophy--that is, bracketing is a strategy for making
progress in talking about P, but it's not a satisfactory strategy full
stop--because we don't mark areas "off limits" and say "you can't talk
about this one any more". Another way to put it is that there isn't
such a thing as an unresolvable paradox, really, only paradoxes that
haven't yet been resolved.
A lighter weight version of bracketing is noting that something is
controversial. I might say "ah, P is true, because the right solution
to the other-minds problem is XXX." But the person I'm talking with
will say "oh, but the other-minds problem is very controversial".
That's a signal that the conversation has two turns. One, I need to
prove XXX--and then we will probably never get back to P. Or, I can
try to demonstrate P without presuming the solution XXX to the
other-minds problem. If the other person does not *want* a discussion
of XXX, rather than leaving both options, they will say "let's bracket
XXX for a moment" (read, "forever").
For example, I think that the solution to the other minds problem is
nicely given by taking Turing's test seriously; I'm a
Turing-test-believer. If I'm talking to someone else who shares that
opinion, then we can assume it in talking about P--no need for
bracketing.
Thomas
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> "Joe Marshall" <·············@attbi.com> writes:
>
> > "Kent M Pitman" <······@world.std.com> wrote in message
> > ····················@shell01.TheWorld.com...
> > > "Joe Marshall" <·············@attbi.com> writes:
> > >
> > > > READ causes noticable side effects. This can create dependencies
> > > > on the order in which things are read.
> > >
> > > EVAL and/or COMPILE-FILE causes noticeable side-effects too. This
> > > creates dependencies on the order in which Scheme expressions can be
> > > processed.
> >
> > Woah!!! Who said anything about Scheme?
>
> This whole discussion of packages came from a discussion of modules vs
> packages which came from a discussion of what symbol processing is which
> came from a discussion of what is criterial to a lisp which came from a
> discussion of whether Scheme is a Lisp... or so I thought. Wasn't it
> obvious. ;)
>
> Ok, sorry for misjudging your sense of context. My reply was probably
> out of frame if you weren't in the same frame of reference...
The discussion has been all over the map. I've been trying to limit
my comments to *only* those things about the package system that have
bothered me. In Erann Gat's original post, he says
``So I've always considered packages as more of a necessary evil than a
feature. I was told that this view was common in the CL world.''
That is pretty much my opinion, and that's what I said initially.
> You've raised a lot of problems but you haven't said what featurism you
> expect. As long as your only complaint is that it can be used wrong, it's
> hard to respond to. If you are looking for it to keep you from doing a
> certain thing or allow you to do a certain thing, it would be easier to
> respond to. As detailed as you've been, I still can't generalize from
> your specific examples to anything other than "this isn't good for me"
> and so I can't do much to help. Even a guess at what would be better
would
> again make the discussion concrete for me.
Well, I cited a number of anecdotes that have made me say `damn this
@#$%! package system!' What I'd prefer is for the package system to
do what it is doing now, but without the annoyances. Yes, it's a
subjective problem, and yes, the solution is hard.
> I think honestly that you were wrong when you said you aren't arguing for
> Scheme. Scheme has a solution (with its incumbant problems--they are not
> being inconsistent per se, they are just trading one problem for another).
> I don't like the problems created by their solution. But you sound like
> you would.
Is there a post where I said `Scheme solves the problem'?
And what is the Scheme solution? Scheme48 has a module system.
MzScheme has a different one. MIT-Scheme has yet another.
> > > In general, I think the
> > > problem is more that CL does not seek to handle this problem than that
> > > CL would not be capable of handling this problem with available data
> > > structures if it chose to provide you the necessary operators. I
don't
> > > see a data structure problem here; perhaps an API weakness. But new
APIs
> > > can be written without changing the language spec.
> >
> > Well, I'm not suggesting a change to the language spec. I just want
> > to not see spurious `name conflict' errors.
>
> The errors are not spurious. They happen for a reason. I'm sure you
> realize this, but I'm not sure you see the significance of realizing this.
Well, when I type
=> foo
Unbound variable `foo'
=> (use-package "FOO")
Error: symbol 'foo' already exists
This, to me, is a spurious error. I made a single typo, but I have
to make two trips through the error handler?
"Joe Marshall" <·············@attbi.com> writes:
> > > Well, I'm not suggesting a change to the language spec. I just want
> > > to not see spurious `name conflict' errors.
> >
> > The errors are not spurious. They happen for a reason. I'm sure you
> > realize this, but I'm not sure you see the significance of realizing this.
>
> Well, when I type
> => foo
> Unbound variable `foo'
>
> => (use-package "FOO")
> Error: symbol 'foo' already exists
>
> This, to me, is a spurious error. I made a single typo, but I have
> to make two trips through the error handler?
But there _is_ a reason for this. When you do
(defun bar (x) (foo x))
(defun foo (x) (+ x 3))
(bar 4)
you get a useful result. That is, when you forward-reference a symbol,
it creates it. It preserves the illusion that all symbols always exist
by demand-creating any symbol upon mention.
I dunno if you use any speech recognition software but it's often
incumbent upon you that you correct it when it gets something wrong
because if you don't you're going to get it thinking it has
confirmation it did the right thing. Same deal here.
You said FOO and you didn't immediately do (UNINTERN 'FOO). That means
CL took it as a given that there should be a symbol FOO there. From
the tiny window that INTERN is looking through, there is no difference
between that use of FOO and the use of FOO in the DEFUN of BAR above.
Late, when you (USE-PACKAGE "FOO") you are not just saying "get a package
FOO" [which I assume from your context has a symbol FOO in it that is
defined as a variable]. You are saying consolidate my uses with the FOO
package's uses. At the level of the package system, FOO has been used, but
the reason for the use is not recorded. It can't tell that you haven't typed
the three forms that I offered above, and it can't tell that FOO is not
important for its identity. So it doesn't want to discard the problem.
In my papers on error handling, such as
http://world.std.com/~pitman/Papers/Exceptional-Situations-1990.html
I make the point that an error is a situation where there are multiple
pending continuations (to use Schemish terminology) and you can't from
available program data select the right one. Advice is required and the
second error break seeks advice. The call to USE-PACKAGE does not know
how substantial your prior use of FOO is and must ask rather than do
the wrong thing some statistical number of times. People might not report
that quiet problem I mention because people tend to report problems that
enter debuggers and not report things that don't enter the debugger, but all
the more reason to enter the debugger.
You might think it could do (AND (NOT (BOUNDP X)) (NOT (FBOUNDP X)) ...)
to tell. But this assumes there are a finite number of such tests.
If you believe me when I say that BOUNDP and SYMBOL-VALUE are just accesses
to hash tables provided by the system, but that there are an unlimited
number of things the user might have used this as a key for, then you know
only a full GC could possibly keep you from losing. (And that GC would
probably fail within 3 command lines from the failure since +, ++, +++,
*, **, or *** probably refer to the FOO symbol so it wouldn't get quickly
GC'd without your help.)
Curiously, _sometimes_ the reason you do not do (UNINTERN 'FOO) immediately
after typing the stray FOO is you may not be sure that FOO is something
you want to unintern. Maybe someone _does_ have a pointer and maybe your
doing the unintern will break things. So if you are wary about calling
UNINTERN randomly, why would you want a simple program like USE-PACKAGE
with far less brainpower and visual scope than you have to do it?
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> "Joe Marshall" <·············@attbi.com> writes:
>
>
> > > > Well, I'm not suggesting a change to the language spec. I just want
> > > > to not see spurious `name conflict' errors.
> > >
> > > The errors are not spurious. They happen for a reason. I'm sure you
> > > realize this, but I'm not sure you see the significance of realizing
this.
> >
> > Well, when I type
> > => foo
> > Unbound variable `foo'
> >
> > => (use-package "FOO")
> > Error: symbol 'foo' already exists
> >
> > This, to me, is a spurious error. I made a single typo, but I have
> > to make two trips through the error handler?
>
> But there _is_ a reason for this. When you do
>
> (defun bar (x) (foo x))
> (defun foo (x) (+ x 3))
> (bar 4)
>
> you get a useful result. That is, when you forward-reference a symbol,
> it creates it.
I understand this. What the package-system doesn't understand is that
when I mentioned `foo' the first time (and got the unbound variable)
was that I *didn't* want that symbol. (Yeah, I know it cannot read
my mind.)
> It preserves the illusion that all symbols always exist
> by demand-creating any symbol upon mention.
The illusion is imperfect. When I (use-package ..) I can tell if
a symbol had been created on demand or not: I get errors for those
that were.
>
> You said FOO and you didn't immediately do (UNINTERN 'FOO). That means
> CL took it as a given that there should be a symbol FOO there. From
> the tiny window that INTERN is looking through, there is no difference
> between that use of FOO and the use of FOO in the DEFUN of BAR above.
From the tiny window *I* am looking through, I can't tell if my typo
interned a new symbol or found an existing one. I can't just (UNINTERN
'foo)
without knowing this.
> Curiously, _sometimes_ the reason you do not do (UNINTERN 'FOO)
immediately
> after typing the stray FOO is you may not be sure that FOO is something
> you want to unintern. Maybe someone _does_ have a pointer and maybe your
> doing the unintern will break things. So if you are wary about calling
> UNINTERN randomly, why would you want a simple program like USE-PACKAGE
> with far less brainpower and visual scope than you have to do it?
No, I don't want a DWIM. What I do want is something that is a bit
more clever. Consider this behavior: when I make a typo and get an
unbound variable error, why not have the system unintern the symbol
just created if and *only if* it was created by the typo itself.
Or this: When loading a fasl file (with appropriate switches)
the following error appears:
The symbols 'frob', 'tweak', 'twiddle', and 'transmogrify' are
not currently visible in package FOO, but package UTILITY exports
symbols of these names.
1: IMPORT just those symbols from UTILITY
2: USE-PACKAGE utility.
3: Create new symbols in package FOO.
These two behaviors (and note that I'd like that latter to be a user
controlled switch so no one *has* to monitor the load process
looking for these things) would greatly improve my relationship with the
package system.
"Joe Marshall" <·············@attbi.com> writes:
> No, I don't want a DWIM. What I do want is something that is a bit
> more clever. Consider this behavior: when I make a typo and get an
> unbound variable error, why not have the system unintern the symbol
> just created if and *only if* it was created by the typo itself.
>
> Or this: When loading a fasl file (with appropriate switches)
> the following error appears:
>
> The symbols 'frob', 'tweak', 'twiddle', and 'transmogrify' are
> not currently visible in package FOO, but package UTILITY exports
> symbols of these names.
> 1: IMPORT just those symbols from UTILITY
> 2: USE-PACKAGE utility.
> 3: Create new symbols in package FOO.
>
> These two behaviors (and note that I'd like that latter to be a user
> controlled switch so no one *has* to monitor the load process
> looking for these things) would greatly improve my relationship with the
> package system.
It sounds like you just want a kinder, gentler repl. I don't see why
you couldn't have that with the existing package system.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
* Joe Marshall
| I understand this. What the package-system doesn't understand is that
| when I mentioned `foo' the first time (and got the unbound variable) was
| that I *didn't* want that symbol. (Yeah, I know it cannot read my mind.)
But if you typed it into the REPL, you must have been in the wrong
package to begin with. Why is that? My guess is that you were in the
common-lisp-user package and called use-package instead of changing the
current package to a well-defined package that uses the packages you have
defined. I think you should be using in-package instead of use-package.
In my opinion, you are using the package-system counter to its design
when you randomly call use-package, regardless of whether it is because
of this "error". I tend to think it is just plain wrong to use the
package operations interactively unless you are working to piece together
a package in order to dump it to file prior to defining anything that
depends on it having properly been set up. In other words, you have a
broken package definition to begin with when you need to call use-package
to "fix" it. And this is most likely the wrong "fix", too.
You have probably thought that use-package is something very different
than it is and are now frustrated that it is not what you think it is,
but what you think and what it is are probably close enough not to give
you a strong enough hint that you need to revise your concept of what it
is. May I suggest that you do a refresh read of the package concepts in
the standard to see that your assumptions are actually valid?
I tried to remember when I ran into problems like you describe, but it is
quite hazy to me. I must have changed the way I use Allegro CL compared
to how I used CMUCL. In particular, if I try to evaluate an unbound
variable in ACL, I get these restarts:
(52) cl-user
foo
Error: Attempt to take the value of the unbound variable `foo'.
[condition type: unbound-variable]
Restart actions (select using :continue):
0: Try evaluating foo again.
1: Use :foo instead.
2: Set the symbol-value of foo and use its value.
3: Use a value without setting foo.
4: Return to Top Level (an "abort" restart).
5: Abort entirely from this process.
CMUCL is quite deficient in the restart department:
* foo
Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER: the variable FOO is unbound.
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(EVAL FOO)
Source:
; File: target:code/eval.lisp
; File has been modified since compilation:
; target:code/eval.lisp
; Using form offset instead of character position.
(SYMBOL-VALUE EXP)
I had to go through a manual apropos call to get the equivalent of
restart 1 in ACL above. That would be annoying, but this is a quality of
implementation issue with CMUCL, not a design issue with packages.
CMUCL does not by default print the package name, and there is no
convenient way to change the package, so it seems to me that your having
adopted this abuse of use-package may well be an history artifact and
that you should now use in-package, instead.
* Kent Pitman
> It preserves the illusion that all symbols always exist
> by demand-creating any symbol upon mention.
| The illusion is imperfect. When I (use-package ..) I can tell if a
| symbol had been created on demand or not: I get errors for those that
| were.
Really? This would only be true of all symbol names were always distinct
regardless of the package system. Since this is obviously false and a
use-package therefore can signal an error caused by two well-defined
symbols in both packages, there is something wrong with your premises.
I think your _premise_ is that the package system is broken and now you
are only trying to find ways to "prove" it by doing things that would
break _any_ working system. I consider this prejudicial.
| No, I don't want a DWIM. What I do want is something that is a bit more
| clever. Consider this behavior: when I make a typo and get an unbound
| variable error, why not have the system unintern the symbol just created
| if and *only if* it was created by the typo itself.
Would you want the reader to record the second value of intern for each
symbol it has interned and make them available to the evaluator so it can
safely unintern a symbol that causes a symbol and search all packages for
a symbol with the same name and suggest them to you in case the user is
unable to set up the package-system so it produces user-correct results?
This sounds like a really bad solution to the wrong problem.
| These two behaviors (and note that I'd like that latter to be a user
| controlled switch so no one *has* to monitor the load process
| looking for these things) would greatly improve my relationship with the
| package system.
The user-controlled switch exists and is called defpackage. If you do
not use an in-package form in your compiled source files, I think you
deserve to lose, and if your package definitions are out of sync with
respect to their actual interdepencies, even more so.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Erik Naggum <····@naggum.net> writes:
> In my opinion, you are using the package-system counter to its design
> when you randomly call use-package, regardless of whether it is because
> of this "error". I tend to think it is just plain wrong to use the
> package operations interactively unless you are working to piece together
> a package in order to dump it to file prior to defining anything that
> depends on it having properly been set up.
I completely agree with this.
Though the design was initially bad having only those stupid package
operations (which should always have been only subprimitive to DEFPACKAGE
and its ilk, to error correction, etc.) so I don't know if counter to its
design is quite how I'd say it. I'd say "counter to what has become
good practice" ;)
> In other words, you have a
> broken package definition to begin with when you need to call use-package
> to "fix" it. And this is most likely the wrong "fix", too.
Right.
> You have probably thought that use-package is something very different
> than it is and are now frustrated that it is not what you think it is,
> but what you think and what it is are probably close enough not to give
> you a strong enough hint that you need to revise your concept of what it
> is. May I suggest that you do a refresh read of the package concepts in
> the standard to see that your assumptions are actually valid?
Or better yet, never ever use these things and only ever use DEFPACKAGE and
IN-PACKAGE.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> "Joe Marshall" <·············@attbi.com> writes:
>
> > "Kent M Pitman" <······@world.std.com> wrote in message
> > ····················@shell01.TheWorld.com...
> > > "Joe Marshall" <·············@attbi.com> writes:
> > >
> > > > Where it *was* a problem was on the Lisp Machine. When you opened
> > > > a file in Zmacs, it would parse the file mode and it would
> > > > parse some of the file contents. It would attach properties to
> > > > the symbols mentioned in the file.
> > >
> > > I'm familiar with the problem you're talking about, but you can't
> > > blame this on the package system. I don't think this is a fair
> > > criticism. The Zmacs editor chose to put things on the property list
> > > of symbols prematurely and got in trouble.
> >
> > I think I'll still blame this on the package system. If Common Lisp
> > did not have a package system (let's imagine that namespace conflicts
> > don't occur and we can intern everything in one package), then Zmacs
> > would have no problem at all attaching properties to symbols.
>
> As nearly as I can tell, this argument comes down to what in legal terms
> would be called an "attractive nuisance". That is, by virtue of having
the
> data structure available, it seems to invite use in some cases.
>
> The reason I think the editor is "special" is that code to be edited
> is not code in core. It stands at the brink and is really just a huge
> large string in stringquotes. I regard your bug the same as if
> someone had written some tool that scans files and was interning
> symbols it found in stringquotes or comments. There are very
> dangerous things that one finds quoted and there is a reason that
> evaluation is suppressed. Programs which have only a superficial
> understanding have no business doing what you are suggesting oughtt to
> be the right answer in a universe with packages but ought not be the
> right solution in a universe without packages.
I think that finding things that look like syntactic tokens
in a file and making notes about them is a fine thing for an editor
to do. In the cases where the code you were editing *was* already
read into the system, the interning of symbols caused no problems and
enabled some really fancy features.
>
> You know, I had a similar problem with Zmail a few years back when I
revived
> my old mail files (from the mid 1980's) from backups and it tried to parse
> and intern all the domain names. You may or may not be aware (heh) that
> the host names have changed since then. I got a lot of failed parses for
> missing hosts like MIT-MC.ARPA or even PLANTAIN.SCRC.Symbolics.COM and it
> was a mess. Does this mean the domain name system is wrong? Or does it
mean
> that some editing programs that are not actually trying to talk to the net
> yet shouldn't be prematurely doing host lookup just based on the fact that
> they saw some plausible looking text go by? Because I think the latter.
The latter, obviously. But to draw a symbol analogy, suppose that by
attempting to resolve `PLANTAIN.SCRC.SYMBOLICS.COM' it *created* the domain
rather than generating an error if it was not found. Would you still
say the problem is with premature lookup?
[Lots of Zmacs stuff elided]
Well, mumble. We both agree that Zmacs did things wrong if it
tried to intern symbols in packages that were not set up.
> > > > So, on to more obscure problems. You can't use `forward references'
> > > > to symbols that don't exist in packages that don't exist (yet).
> > > > In your init file, you'd *like* to be able to customize some
> > > > parameters before you start building the system. Perhaps you have
> > > > some macros that are parameterized, whatever. As an example, I
> > > > once worked at a place that had a `verbosity' switch that I wanted
> > > > set.
> > > >
> > > > The obvious thing is to write (setq utility::*verbosity* t)
> > > > but the utility package isn't loaded yet. Never mind that the
> > > > utility package *will* be there when I call this function, it
> > > > isn't there when I *read* the code. Instead I write:
> > > > (let* ((utl-pkg (find-package :utility))
> > > > (verbosity (intern (symbol-name :*verbosity*) utl-pkg)))
> > > > (setf (symbol-value verbosity) t))
> > > >
> > > > The same goes for functions that I want to call. I can't
> > > > write (progn (load "java-tools.lisp") (java-tools:make-all))
> > > >
> > > > The way around this problem is to write a function that
> > > > defers interning until runtime. Then you can write
> > > > (progn (load "java-tools.lisp") (funcall-in-package :java-tools
> > :make-all))
> > >
> > > I usually did:
> > >
> > > (load "java-tools.lisp")
> > > (java-tools:make-all)
> >
> > This is obviously not quite kosher in a file.
>
> Sure it is. I don't know what you're talking about. I have files that
> say just exactly that. (Well, different function and package names.)
But when you load the init file, the reader ought to fail because
there is no package named `java-tools' at the time the reader reads
the init file. Never mind that java-tools:make-all *will* be a
fine thing to invoke *after* we load "java-tools.lsp". (I have verified
this on ACL and Corman.)
> > interning the name "FOO" in package "BAR" would yield 'FOO::BAR, yet
> > in another interning the name "FOO" in package "BAR" would yield
> > 'SYS:BAR. There were degenerate cases where you could end up with
> > a symbol associated with a `non-existant' package.
>
> You mean with package not found errors, like in any package universe that
> was absent a package, no?
Not exactly. Conventionally, if you evaluate this:
(find-package (symbol-package 'foo)) => (some package)
but you could end up with interned symbols with valid packages whose
names could not be found.
"Joe Marshall" <·············@attbi.com> writes:
> > > > I usually did:
> > > >
> > > > (load "java-tools.lisp")
> > > > (java-tools:make-all)
> > >
> > > This is obviously not quite kosher in a file.
> >
> > Sure it is. I don't know what you're talking about. I have files that
> > say just exactly that. (Well, different function and package names.)
>
> But when you load the init file, the reader ought to fail because
> there is no package named `java-tools' at the time the reader reads
> the init file. Never mind that java-tools:make-all *will* be a
> fine thing to invoke *after* we load "java-tools.lsp". (I have verified
> this on ACL and Corman.)
This is IMHO not true. The loader must process the forms one by
one, including the reader. Otherwise forms such as (in-package :foo)
would not work in loaded files.
I don't know what you tested, but with the following two files,
everything works as expected, in all CL implementations I've tested,
including ACL, LispWorks, CMUCL and CLISP:
;;; java-tools.lisp
(defpackage :java-tools (:use :CL) (:export #:make-all))
(in-package :java-tools)
(defun make-all ()
(print 42))
;;; init.lisp
(load "java-tools.lisp")
(java-tools:make-all)
If you want to compile init.lisp without manually loading
java-tools.lisp beforehand, you'd have to wrap the load form with an
appropriate eval-when form, and then even that will work just fine,
including loading a compiled init file into a fresh core, IMHO, though
CMU CL seems to exhibit a bug there.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@pmsf.de> wrote in message
···················@orion.bln.pmsf.de...
> "Joe Marshall" <·············@attbi.com> writes:
>
> > > > > I usually did:
> > > > >
> > > > > (load "java-tools.lisp")
> > > > > (java-tools:make-all)
> > > >
> > > > This is obviously not quite kosher in a file.
> > >
> > > Sure it is. I don't know what you're talking about. I have files
that
> > > say just exactly that. (Well, different function and package names.)
> >
> > But when you load the init file, the reader ought to fail because
> > there is no package named `java-tools' at the time the reader reads
> > the init file. Never mind that java-tools:make-all *will* be a
> > fine thing to invoke *after* we load "java-tools.lsp". (I have verified
> > this on ACL and Corman.)
>
> This is IMHO not true. The loader must process the forms one by
> one, including the reader. Otherwise forms such as (in-package :foo)
> would not work in loaded files.
I excerpted too much. The init file had this in it:
(defun build-java ()
(load "java-tools.lisp")
(java-tools:make-all))
Which *does* fail.
"Joe Marshall" <·············@attbi.com> writes:
> "Pierre R. Mai" <····@pmsf.de> wrote in message
> ···················@orion.bln.pmsf.de...
> > "Joe Marshall" <·············@attbi.com> writes:
> >
> > > > > > I usually did:
> > > > > >
> > > > > > (load "java-tools.lisp")
> > > > > > (java-tools:make-all)
> > > > >
> > > > > This is obviously not quite kosher in a file.
> > > >
> > > > Sure it is. I don't know what you're talking about. I have files
> that
> > > > say just exactly that. (Well, different function and package names.)
[...]
> I excerpted too much. The init file had this in it:
>
> (defun build-java ()
> (load "java-tools.lisp")
> (java-tools:make-all))
>
> Which *does* fail.
You didn't excerpt, it was Kent that said that _he_ prefered to use
the two form version, which does work, instead of the ugly hack you
had proposed, in order to use one form. And it was Kent's version
which you claimed was not quite kosher. Please take more care in
reading what you are arguing against, otherwise it gets very hard to
separate valid arguments from FUD.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
> And if you were, what is it that
> makes you prefer packages?
Good things come in small packages.
When I broke up a monolithic wadge of code into reasonable packages (for
no particular reason other than it seemed The Right Thing), to get clean
compiles I had to refactor -- not too much, but enough to realize the
code was being improved in each case by the exercise.
Note that this was not about name conflicts, just classic stuff like a
utility package calling functions from a higher level package it should
not have known about. less so the higher-level package going after
unexported implementation stuff.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Well, I've wrestled with reality for thirty-five years, Doctor, and
I'm happy to state I finally won out over it." Elwood P. Dowd
[ Apologies if this gets posted twice, or if a garbled version of it got posted
first... ]
···@jpl.nasa.gov (Erann Gat) writes:
> A mentor of mine at the time (1988 or so) once expounded on the virtues of
> environments and the evils of packages. He made an offhand comment that I
> still remember to this day: "Common Lisp" he said "really has a flat
> namespace." What he meant was that there was little effective difference
> between packages as they exist in CL, and a Lisp with only one package and
> a reader hack that attached the prefix "package:" (where "package" is
> replaced with the value of the global variable *package*) to all symbol
> names that didn't already have colons in them before interning them. Now,
> this isn't quite right, of course, because of import, export, and
> use-package, but his fundamental point has stuck with me through the
> years, that discriminating between multiple interpretations of a symbol
> name at read time rather than at eval time was the Wrong Thing. (This is
> not to say that I necessarily agree with this point of view, just that I
> remember it.)
Erann,
your mentor had it right, basically. Let me explain why.
First, we should say what a "symbol" really is: A symbol is a little
data structure, a record if you will. (The data structure contains a
number of slots. One slot, for example, could hold the symbol's
package (if it is interned), another its name within that package,
another its global value, another its function binding, another its
property list. I do not claim completeness here.) What a symbol
really is is not important for the purpose of this discussion -- only
that it exists and has an identity that is independent of the name
that refers to it.
Second, what is a package? A package is a structure that (at least)
consists of a finite map mapping names (strings of characters) to
existing (interned) symbols (where by "symbol" I mean those little
data structures introduced above).
For the time being, let's say that a package *is* its map from names to symbols.
(Of course, this is not the whole picture as far as CL is concerned. But it
will illustrate the idea without getting bogged down in unimportand but tedious
technicalities.)
If we call the domain of names "name", the domain of symbols "symbol",
and the domain of packages "package", then we can write the domain equation:
package = name |--> symbol
Now, packages themselves also have names, which means that there is a
global finite map PACK (that is also mutable, but, we postpone this issue)
that maps strings to packages. So, in a fashion analogous to the
above, we say that if m is the name of an existing package p, then
PACK(m) = p
or
PACK : name |--> package
or
PACK : name |--> (name |--> symbol)
In other words, to look up a symbol given the name m of its package and
the name n of the symbol within the package named by m, we simply do
PACK(m)(n)
(I am sure you recognize PACK: it is CL's "find-package", only grossly simplified
for the purpose of this discussion.)
--------
At this point, let's step back for a moment and look at total maps.
For every total map f that maps A's to total maps from B's to C's:
f : A --> (B --> C)
there is a total map, let's call it "uncurry(f)" from pairs (x, y) \in A * B
to C:
uncurry(f) : A * B --> C
Moreover, for every g : A * B --> C there is a curry(g) : A --> B -->
C. Finally, both "curry o uncurry" and "uncurry o curry" are
identities, so "uncurry" (like "curry") is an isomorphism. (And, not
unimportantly, computability is also preserved by "curry" and
"uncurry".)
Some minor but annoying technical difficulties arise once we try to
apply the same reasoning to partial (in particular: finite) maps
because the domains
A |--> B |--> C and A * B |--> C
are not isomorphic. The problem is that in the curried case an
application can fail at either of the two stages while in the
uncurried case these two failure modes are collapsed into one.
Translated to the PACK case this would mean that one couldn't
distinguish between looking up a non-existing symbol in an existing
package and looking up anything in a non-existing package.
But notice that these issues *can* be finessed, e.g., by "lifting" the
domains (supplying an explicit failure result -- nil in the case of
find-package) and lifting the second stage lookup function
accordingly. On the uncurried side this leads to the need for an
auxiliary map from package names to booleans (i.e., effectively a set
of package names) to keep track which packages exist and which ones
don't.
The point is: There /is/ an isomorphism, and where there is an
isomorphism between two explanations (here: curried and uncurried
lookup), one can say that one can be /viewed in terms of the other/.
Of course, one has to be careful: Once you decide which view to take,
you have to be consistent. Curried and uncurried functions are not
the same, they are merely related by an isomorphism. If one gets
mixed up between the different views, arbitrary nonsense occurs.
---------
Anyway, coming back to your mentor's "offhand comment":
- The members of the cross-product of two string domains could be
represented as the concatenation of the original strings -- provided there
is some way of recognizing the boundary so that the original two strings
can be recovered. (In CL there is such a way.)
- Thus, an uncurried lookup function (which is the essence of a "flat" domain)
could, indeed, take the symbol name with the package name prefixed.
- This is a plausible way of viewing how things work. Of course, it
does not mean that things actually /do/ work that way in terms of how
they are implemented. They probably are not (although I would claim --
with enough finesse they could be, no matter how pointless that would probably
be).
- I do not see how "import", "export", or "use-package" pose insurmountable
difficulties with the flat model.
---------
Finally, how to deal with the mutability? Well, it is actually not that
hard. Essentially the same kind of isomorphism like the one above can
be constructed, only the details are a bit messier. That's why I leave the
construction to the interested reader.... :-)
Matthias