I'm trying to learn Lisp because I'm becoming fascinated with several
of the ideas it embodies. I'm not referring to Common Lisp or Scheme
per se, much less any specific implementation, but to the ideas that
they seem to share (to the limited extent I understand them so far.)
I don't expect that a knowledge of Lisp will improve my career
prospects, but it may make my life more interesting. In fact, I'm
already observing that it is, so I'll keep at it to the extent I can.
And I'm not entirely ruling out the possibility of career enhancement,
so I'm wondering....
What's happening in the Lisp world today?
Are there any new Lisp-family languages being created? I don't mean,
are any languages retrofitting a few Lisp-like features (most are),
but are there any "new and improved Lisp" languages being created?
I've only heard of Paul Graham's Arc, but it appears from the Arc
website that he abandoned it after "three weeks" (or put it on a back
burner? went underground? anybody know?) and went off to battle spam.
Are there any other "new Lisps" in the making?
Is there another Common Lisp standard in the works? Another Scheme
standard?
Are there any new implementations being *actively* worked on? Yes,
I've seen the exhaustive lists of links to implementations, but such
lists studiously avoid making value judgments that might lead me to an
understanding of what's really going on (or isn't anymore). Something
that was very promising twenty years ago and is now on life support is
going to look the same to me as something that is very promising
*today*, so I'd be very interested in well-informed, opinionated,
judgmental comments about implementations.
So what is being energetically worked on now? I'm particularly
interested in open source projects, but not exclusively so.
Any sign that Guy Steele is going to persuade Sun to come out with a
new Lisp + Java runtime upgrade combination optimized for each other?
How about an L# from Microsoft to match the F# (ML for .Net) they have
announced?
And are there any market segments (finance, robotics, etc.) or fields
where the use of Lisp is increasing significantly? Not the standard
"Viaweb and Orbitz" examples, but domains in which Lisp is growing.
Anything else that is a significant area of activity in the Lisp world
today?
Thanks.
On 26 Aug 2003 13:24:34 -0700, ········@hotmail.com (Tuang) wrote:
> I've only heard of Paul Graham's Arc, but it appears from the Arc
> website that he abandoned it after "three weeks" (or put it on a
> back burner? went underground? anybody know?) and went off to battle
> spam.
Were do you get that information from? Seems like he's going to speak
about Arc at the ILC in two months:
<http://www.international-lisp-conference.org/Speakers/ILC03-speakers.html>
I wouldn't call that "going underground." I also didn't expect him to
finish a new language in a few weeks, at least not if it's worth
looking at. Did you?
> Are there any other "new Lisps" in the making?
>
> Is there another Common Lisp standard in the works? Another Scheme
> standard?
Why do you want the latest and greatest? Why don't you try to learn a
language that is there and well supported first?
> Are there any new implementations being *actively* worked on?
There are at least five commercial and six open source Common Lisp
implementations which are actively worked on. (Maybe more, I'm not
good at counting.) All of them had significant releases this year, all
of them have active mailing lists. Just google around.
Edi.
Edi Weitz <···@agharta.de> wrote in message news:<··············@bird.agharta.de>...
> On 26 Aug 2003 13:24:34 -0700, ········@hotmail.com (Tuang) wrote:
>
> > I've only heard of Paul Graham's Arc, but it appears from the Arc
> > website that he abandoned it after "three weeks" (or put it on a
> > back burner? went underground? anybody know?) and went off to battle
> > spam.
>
> Were do you get that information from?
His Arc website.
> Seems like he's going to speak
> about Arc at the ILC in two months:
>
> <http://www.international-lisp-conference.org/Speakers/ILC03-speakers.html>
>
> I wouldn't call that "going underground."
His organisational affiliation is "ARC". A little hard to tell what
that means, but yes, maybe he's going to talk about Arc. I don't know
what he plans to talk about, but it seems likely that he'll at least
answer questions about Arc's status. I wish I could attend, but I
can't afford it.
> I also didn't expect him to
> finish a new language in a few weeks, at least not if it's worth
> looking at. Did you?
Odd question. I noticed that he posted several Arc-related updates,
one every few weeks or so, for a period of a few weeks (or months).
Then the updates stopped, and as far as I can tell, he hasn't changed
a single word on his Arc site for about two years, despite having
continued to update other areas of his site regularly. So I wondered
whether the initial brief flurry of progress reports followed by two
years of total silence meant that there was no longer any progress to
report, progress but a change of heart about publicly reporting it, or
some other possibility.
Thinking someone here might know, I asked. I find it odd that you
would confuse a curiosity about the disappearance of status reports
long ago with an expectation that "a new language would be finished in
a few weeks".
>
> > Are there any other "new Lisps" in the making?
> >
> > Is there another Common Lisp standard in the works? Another Scheme
> > standard?
>
> Why do you want the latest and greatest?
I'd be interested in the greatest, almost by definition. If the latest
isn't yet the greatest but will be in the future, then I'm interested
because I plan to spend all of my time in the future.
Of course if there's nothing coming that's worth my attention - and
everything of significance in the Lisp world is already here - then
I'd like to know that, too.
> Why don't you try to learn a
> language that is there and well supported first?
I've already begun, and I like both CL and Scheme so much that I'm
curious to know more about what's going on in the Lisp world today. I
pay attention to new developments and trends in other languages I work
with, and now that I'm finding Lisp so interesting, I'm just doing the
same with Lisp. It's a much smaller community than the big, popular
languages (Java, C++, etc.) and more fragmented than most of the small
languages (Python, Ruby, etc., presumably because of Lisp's age), so
it makes it a little harder to find some types of info.
>
> > Are there any new implementations being *actively* worked on?
>
> There are at least five commercial and six open source Common Lisp
> implementations which are actively worked on. (Maybe more, I'm not
> good at counting.) All of them had significant releases this year, all
> of them have active mailing lists. Just google around.
All of them had *significant* releases this year? That's great news. I
have found some of the mailing lists, but the discussion is not a
bird's eye view of where the major activity is in the Lisp world
overall, it's a worm's eye view of specific implementation details.
I also don't think an implementation-specific mailing list is a good
place to ask for an overview of what's going on in the Lisp familiy
overall. I don't want to imply that their specific implementation
isn't the ultimate, after all. Even comp.lang.lisp seems like a dodgy
place to express interest in any Lisp other than Common Lisp (or
apparently in the future of Lisp beyond the current CL standard), but
I'm not sure where better to ask. I'm just trying to get an overview
of what's happening in an area of computing that I'm finding
increasingly interesting.
On 27 Aug 2003 02:21:59 -0700, ········@hotmail.com (Tuang) wrote:
> > <http://www.international-lisp-conference.org/Speakers/ILC03-speakers.html>
>
> His organisational affiliation is "ARC". A little hard to tell what
> that means, but yes, maybe he's going to talk about Arc.
There are two columns. The first one seems to be the affiliation, the
second one seems to be the theme of the keynote. They're both called
"ARC".
> > There are at least five commercial and six open source Common Lisp
> > implementations which are actively worked on. (Maybe more, I'm not
> > good at counting.) All of them had significant releases this year,
> > all of them have active mailing lists. Just google around.
>
> All of them had *significant* releases this year?
- SBCL added native threads for x86 and a lot of other things.
- CMUCL got a completely re-worked CLOS, the ability to deliver
stand-alone apps on some platforms and more.
- LispWorks released 4.3 with Mac OS X support, bivalent streams, weak
hash tables, plus more stuff. See their press release.
- Digitool released their native OS X version this year.
- I think Allegro CL 6.2 is from last year but they've added much
layered stuff this year like "WebActions" and a SOAP client API.
- IIRC, Scieneer just announced support for AMD64.
- I'm not actively tracking CLISP, ECL, GCL, and OpenMCL but I know
there has been much progress there, too. Maybe someone else wants to
chime in.
You decide if you think this is "significant" or not but your original
question was if there was any active work. Yes, there is.
Edi.
Edi Weitz <···@agharta.de> wrote
>
> - SBCL added native threads for x86 and a lot of other things.
>
> - CMUCL got a completely re-worked CLOS, the ability to deliver
> stand-alone apps on some platforms and more.
>
> - LispWorks released 4.3 with Mac OS X support, bivalent streams, weak
> hash tables, plus more stuff. See their press release.
>
> - Digitool released their native OS X version this year.
>
> - I think Allegro CL 6.2 is from last year but they've added much
> layered stuff this year like "WebActions" and a SOAP client API.
>
> - IIRC, Scieneer just announced support for AMD64.
>
> - I'm not actively tracking CLISP, ECL, GCL, and OpenMCL but I know
> there has been much progress there, too. Maybe someone else wants to
> chime in.
>
> You decide if you think this is "significant" or not but your original
> question was if there was any active work. Yes, there is.
Thanks. Great info. A lot more *current* development than I realized.
········@hotmail.com (Tuang) writes:
> Thanks. Great info. A lot more *current* development than I realized.
So on the basis that one good turn deserves another, now you can tell
us: where did you look for information?
This isn't a flame, this is a genuine request: we need to know who
to send Da Boys round to see next.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
········@hotmail.com (Tuang) writes:
> > I also didn't expect him to
> > finish a new language in a few weeks, at least not if it's worth
> > looking at. Did you?
>
> Odd question. I noticed that he posted several Arc-related updates,
> one every few weeks or so, for a period of a few weeks (or months).
> Then the updates stopped, and as far as I can tell, he hasn't changed
> a single word on his Arc site for about two years, despite having
> continued to update other areas of his site regularly. So I wondered
> whether the initial brief flurry of progress reports followed by two
> years of total silence meant that there was no longer any progress to
> report, progress but a change of heart about publicly reporting it, or
> some other possibility.
Hm... Sounds like it really tanked.
> Thinking someone here might know, I asked. I find it odd that you
> would confuse a curiosity about the disappearance of status reports
> long ago with an expectation that "a new language would be finished in
> a few weeks".
People here are a bit defensive. Don't be surprised, we have been
taking the "something serious being done in lisp" troll for ages,
which (rightly) pisses some people off like nobody's business. You
don't look too much like such a troll to me, but hey.
> > > Are there any other "new Lisps" in the making?
> > >
> > > Is there another Common Lisp standard in the works? Another Scheme
> > > standard?
> >
> > Why do you want the latest and greatest?
>
> I'd be interested in the greatest, almost by definition. If the latest
> isn't yet the greatest but will be in the future, then I'm interested
> because I plan to spend all of my time in the future.
Lisp is old. By IT standards it is as old as the oceans, and the
Common Lisp ANSI standard is also at least 10 years old. There are a
few rough edges, but people are generally happy with it as it is. This
a scandal from the viewpoint of other languages, where a standard
emerges almost every year and there is serious discussion about
changing this and that. But the vast majority of people here consider
the standard as done, and no new one has been spotted in the
wild. That may explain why you came through as superficial.
Substandarization efforts are under way in a few areas, like a POSIX
interface, threading, (these things can be done more or less portably
already), interfacing to C (see UFFI) etc.
> Of course if there's nothing coming that's worth my attention - and
> everything of significance in the Lisp world is already here - then
> I'd like to know that, too.
Oh, no, it is not all done. But I think the things left to do are in
the libraries area (and there's quite a bit to do), and less in the
language features area.
> > Why don't you try to learn a
> > language that is there and well supported first?
>
> I've already begun, and I like both CL and Scheme so much that I'm
> curious to know more about what's going on in the Lisp world today. I
> pay attention to new developments and trends in other languages I work
> with, and now that I'm finding Lisp so interesting, I'm just doing the
> same with Lisp. It's a much smaller community than the big, popular
> languages (Java, C++, etc.) and more fragmented than most of the small
> languages (Python, Ruby, etc., presumably because of Lisp's age), so
> it makes it a little harder to find some types of info.
If you observe carefully, it is not as fragmented as you may think. It
is not as loud as other communities, but certainly not fragmented.
> > > Are there any new implementations being *actively* worked on?
> >
> > There are at least five commercial and six open source Common Lisp
> > implementations which are actively worked on. (Maybe more, I'm not
> > good at counting.) All of them had significant releases this year, all
> > of them have active mailing lists. Just google around.
>
> All of them had *significant* releases this year? That's great news.
Very much so. I follow CMUCL, SBCL, and GCL, and they've had
significant releases this year.
> I'm not sure where better to ask. I'm just trying to get an overview
> of what's happening in an area of computing that I'm finding
> increasingly interesting.
Maybe if you tell us what you plan to do with this information it is
easier to help you.
From: Douglas Philips
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F4CCD77.8030809@mac.com>
Mario S. Mommer wrote:
[Referring to ARC]
> Hm... Sounds like it really tanked.
Yeah, but I suspect not, I suspect Graham is just busy. I'd've hardly
expected him to write about ViaWeb while it was still his (The Other
Road Ahead, etc. see his website: http://www.paulgraham.com/).
I wish the ILC conference web site had the speakers on the schedule (I
can only make it for one day, so the question of which day depends on
who is speaking when...) But I digress.
> Lisp is old. By IT standards it is as old as the oceans, and the
> Common Lisp ANSI standard is also at least 10 years old. There are a
> few rough edges, but people are generally happy with it as it is. This
> a scandal from the viewpoint of other languages, where a standard
> emerges almost every year and there is serious discussion about
> changing this and that. But the vast majority of people here consider
> the standard as done, and no new one has been spotted in the
> wild. That may explain why you came through as superficial.
>
> Substandarization efforts are under way in a few areas, like a POSIX
> interface, threading, (these things can be done more or less portably
> already), interfacing to C (see UFFI) etc.
Its too bad the cruft can't be removed: LOOP and FORMAT spring instantly
to mind. From all accounts that I've read (mostly Pitman and Gabriel),
the standard happened in a weird moment in history when custom and stock
hardware were both vying for "the way" and there were many more dialects
and sub-sub-sub-dialects to be reconciled than there are now (assuming
we "know better" than to try to unify with Scheme by now). Hopefully
with a decade of ANSI CL experience...
I'd guess the thing to do is come up with, advocate, and play with for
several years, some replacements/alternatives, and after 5 years or so
of proven history, deprecate the old stuff (but keep it around) and try
to have the new stuff added.
But given that LOOP and FORMAT have ossified, that folks are on to
solving more interesting problems, such an effort would likely be
Sisyphean. Its just easier to work-around/work-with/ignore-altogether
than bother with any other way... ;-) (they are nasty annoyances for
newbies, but that is about it).
Just my buck-two-fitty,
<D\'gou
Douglas Philips wrote:
> Its too bad the cruft can't be removed: LOOP and FORMAT spring instantly
> to mind.
They need to be enlarged, not removed. In particular, there needs to be
a standardized way to extend LOOP.
Paul
From: Douglas Philips
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F4DFB7E.9040308@mac.com>
Espen Vestre wrote:
> Douglas Philips <····@mac.com> writes:
>>Its too bad the cruft can't be removed: LOOP and FORMAT spring
>>instantly to mind.
>
> I get upset by suggestions like this one. I assume I _could_ do without
> loop, I would probably be a less happy CL programmer, but I would
> survive.
You seemed to have missed the part where I said that shouldn't happen
until (implying "unless" too, but I could have made that more explicit)
something better is available. And even then LOOP should be deprecated.
> But anyone who tries to remove format, deserves a long, long stay
> in Microsoft VBScript Hell.
I know that I/O is a pain. Its really ironic that in the "Lisp can do
anything" (to paraphrase Steele: "Give someone Fortran and they have
Fortran, give someone Lisp and they have any language they want") world,
some abomination like FORMAT had to come into being. Oh, the great and
mightly LISP, able to map{,c,car,can,...} over tall buildings in a
single bound, can't even give me a way to print truncated floating point
or even control the rounding in fixed-format floating point output.
Grrr. But nooooo, there aren't enough primitives for control flow
already, even the mighty LOOP pales... we MUST have control constructs
embedded into FORMAT control __strings___. ARG!
1/2 ;-)
C'mon, do you really sing for Lisp because of LOOP and FORMAT?
"Hey Dude, use Lisp, you can put your whole program into a output
formating specification string!" (I'd rather use perl or awk than that).
Yes, they are powerful constructs. But they don't "fit" with the rest of
Lisp.
Yes, there were non-technical reasons that they ended up that way. I'm
not saying, or intending to imply, anything bad about the people who had
to wrestle with the political situation or the realities in place during
the standards process.
Surely there has to be something better?
No, I'm not asking or demanding that anyone do anything about it, except
perhaps not get bent that CL isn't perfect and part of its blemishs are
LOOP and FORMAT -- I wonder how much implementation PAIN is spent over
those two and how much better off we'd be if that effort had gone into
GC research or GUI/IDE or ....
BTW: Nothing here was written or intended as personal to anyone past,
present, or future, who worked on the standard or any lisp system. Given
the other messages on this group, I figured a disclaimer might not hurt. ;-)
<D\'gou
Douglas Philips <····@mac.com> writes:
> You seemed to have missed the part where I said that shouldn't happen
> until (implying "unless" too, but I could have made that more
> explicit) something better is available. And even then LOOP should be
> deprecated.
Ok, that's better, but until then it's NOT cruft, it's only "possible
future cruft" ;-)
> blemishs are LOOP and FORMAT -- I wonder how much implementation PAIN
> is spent over those two and how much better off we'd be if that effort
> had gone into GC research or GUI/IDE or ....
...but you are still encouraging possible implementors to put even
more effort into replacing loop and format...
--
(espen)
From: Douglas Philips
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F4E098B.7040908@mac.com>
Espen Vestre wrote:
>>blemishs are LOOP and FORMAT -- I wonder how much implementation PAIN
>>is spent over those two and how much better off we'd be if that effort
>>had gone into GC research or GUI/IDE or ....
>
>
> ...but you are still encouraging possible implementors to put even
> more effort into replacing loop and format...
Actually that would be a waste. Best of all worlds would be to come up
with a way to implement them on top of nicer primitives. Second best
would be to leave the existing implementations alone, present but
deprecated, and provide cleaner mechanisms for going forward. And yes,
that would be more effort. And (IMHO) it would only be worth that effort
if the primitives were clean, and easy to test. There is no way to
reclaim the time spent on LOOP and FORMAT (and the tests). Nor the time
spent in committees wrangling over those things. All we can effect is
time not yet spent. Time yawning out ahead of us on yet another thread
about the subtle and tricky interactions of all the LOOP keywords and
why yet another newbie has fallen into that tarpit.
But frankly I don't really see it changing. Those with the technical
abilities have adjusted to the status quo, the quirks are internalized,
and interest is elsewhere.
In any event, LOOP is "just a macro" and those of us who would rather
get work done than pour over the spec trying to tease apart the stuff
that the experts know might just as well write our own macros more to
the point of what we're trying to do. 1/2 ;-) I'd really rather not to
have "reinvent the wheel" but I find the LOOP wheel easier to avoid. Its
way too big a hammer. Similarly with FORMAT, I use it because it gives
me some control over formatting, but when I want "interesting" output, I
don't use control constructs inside FORMATs control strings.
Yeah, I could, but it just feels "wrong". But not in the good way that
first learning LISP did. Just in a grungy hacked up way that makes we
want to find a different way to solve my problem (this happens to me
personally more with iteration/recursion/LOOP than with FORMAT).
<D\'gou
Douglas Philips <····@mac.com> writes:
> Yeah, I could, but it just feels "wrong".
Unfortunately, computer scientists and programmers are often obsessed
with almost religious questions ("Thou shalt not use format! It's not
pure lisp!").
Working efficiently with Common Lisp is _not_ about religion, it's about
creating great programs with the best tools available.
So forget the religion and start hacking :-)
--
(espen)
From: Douglas Philips
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F4E0FD2.5080302@mac.com>
Espen Vestre wrote:
> Unfortunately, computer scientists and programmers are often obsessed
> with almost religious questions ("Thou shalt not use format! It's not
> pure lisp!").
He.
> Working efficiently with Common Lisp is _not_ about religion, it's about
> creating great programs with the best tools available.
I don't argue that point at all. I do feel it rather interesting that
given all the confusion and "looseness" in the LOOP spec, that all the
time spent trying to explain how to use it is just, well, counter to:
> So forget the religion and start hacking :-)
Quite!
<D\'gou
Douglas Philips <····@mac.com> writes:
> primitives for control flow already, even the mighty LOOP pales... we
> MUST have control constructs embedded into FORMAT control
> __strings___. ARG!
I don't see what's wrong with this. Common operations get textually
compressed so that they can be written more easily - just like regular
expressions or mathematical formulae.
(format nil "~{~A~^, ~}" my-list)
How _would_ you redesign things to make this look less like line
noise, without in the process either (a) expanding it into three lines
of code, or (b) introducing another new function that people will
probably never find (how many cl programmers can remember all of the
sequence functions without looking them up?) or have to remember an
arbitrary name for
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Douglas Philips
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F4E4492.9040900@mac.com>
Daniel Barlow wrote:
> I don't see what's wrong with this. Common operations get textually
> compressed so that they can be written more easily - just like regular
> expressions or mathematical formulae.
>
> (format nil "~{~A~^, ~}" my-list)
>
> How _would_ you redesign things to make this look less like line
> noise
My issue with it isn't the line-noise-y-ness, but that its bundled up in
a string where I can't use code making/tweaking/hacking code to
maniuplate it, i.e. macros. I'd have to parse the string if I wanted to
change the separator substring ", " or make other manipulations (·@?
seems to be yet another tilde operator for dealing with that exception).
(this particular example is simple enough that there aren't likely to
many such things, but in more interesting cases there could be).
, without in the process either (a) expanding it into three lines
> of code, or (b) introducing another new function that people will
> probably never find (how many cl programmers can remember all of the
> sequence functions without looking them up?) or have to remember an
> arbitrary name for
I agree, name space clutter is a problem. I would assert that you
already have that problem here, but you're hiding it as "special syntax
inside FORMAT strings", but the issue is the same, you have special
names that are even more aribitrary _and_ obscure (i.e. their meaning is
_not_ obvious from their names). I just went to review 22.3.9.2` Tilde
Circumflex: Escape Upward -- what a mess!
~^ if in a ~? string behaves differently than if it had been at the
same place where the ~? inclusion happened. Sheesh, this is like Lisp's
version of FizzBin! "But what if its night on Tuesday?"
And you're telling me its better than three lines of code? That's the
very kind of "clarity" that Perl is constantly slammed for. Yuck. Don't
get me wrong, FORMAT's phalanx of ~ soldiers is impressive and powerful.
But (in)comprehensible at level way above the three lines of code you
were worried about (and which could have a much more euphonious name and
be part of a system of names a much more memorizable than the shotgun
blast of ~ directives).
I can't really answer your question in isolation, because it would beg
the question of an answer to what would you replace all of FORMAT with?
How would this fit into to that, etc. etc. etc.
Those question I don't have an ready flippant answer for. Like everyone
else, I choose to cope with FORMAT. Like some others, I choose to
cope by avoiding it as much as possible. By way of not answering your
question, I would replace that FORMAT call with a function, probably
something like:
(defun format-list-with-separator (stream list separator) ...)
and have it do the right thing (including accepting t and nil for
stream). Whether not I would use that exact name, I can't say as I write
this. Picking good names is a known hard problem. FORMAT's solution is
to quash them into line noise (and what is with ~( for changing case and
~{ for list processing? Oh, right, LISP syntax uses parens for grouping,
so lets use something different for FORMAT? talk about arbitrary and
=mis-leading= names? (as with all things, once you've mastered and
memorized it, internalize it, it doesn't _seem_ so bad).
I should be careful and point out again that I'm not criticizing the
social and political realities that lead to the standard and the
LOOP/FORMAT parts especialy. But even those who participated admit that
it was far from ideal. "It's always been done that way (since the
standard)" isn't a very compelling technical argument. Again, I would
advocate keeping FORMAT for all its legacy "customers", but I can't see
promoting it for future use. (Well, Kid, we had to carve out our own
cons cells from living rock with our bare hands and carry 'em to and
from the garbage collector on our backs, up hill both ways, blinded by
the blizzards of the AI Winter, so you should too) -- sorry I couldn't
resist ;-) ;-) ;-) ).
<D\'gou
Daniel Barlow <···@telent.net> writes:
> Douglas Philips <····@mac.com> writes:
>
>> primitives for control flow already, even the mighty LOOP pales... we
>> MUST have control constructs embedded into FORMAT control
>> __strings___. ARG!
>
> I don't see what's wrong with this. Common operations get textually
> compressed so that they can be written more easily - just like regular
> expressions or mathematical formulae.
>
> (format nil "~{~A~^, ~}" my-list)
>
> How _would_ you redesign things to make this look less like line
> noise, without in the process either (a) expanding it into three lines
> of code, or (b) introducing another new function that people will
> probably never find (how many cl programmers can remember all of the
> sequence functions without looking them up?) or have to remember an
> arbitrary name for
... what? (the last line seems to have been snipped).
Take a look at the "streams" mechanisms for formatted output
in C++. These are definitely more C++-like than printf & friends, but
they are also vastly more painful to use.
Note that Lisp does not "require" this in the same way that
C++ does.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Raymond Wiker wrote:
> Daniel Barlow <···@telent.net> writes:
> > How _would_ you redesign things to make this look less like line
> > noise, without in the process either (a) expanding it into three lines
> > of code, or (b) introducing another new function that people will
> > probably never find (how many cl programmers can remember all of the
> > sequence functions without looking them up?) or have to remember an
> > arbitrary name for
>
> ... what? (the last line seems to have been snipped).
Maybe he couldn't remember what the arbitrary name was for? :)
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> Raymond Wiker wrote:
>> Daniel Barlow <···@telent.net> writes:
>> > How _would_ you redesign things to make this look less like line
>> > noise, without in the process either (a) expanding it into three lines
>> > of code, or (b) introducing another new function that people will
>> > probably never find (how many cl programmers can remember all of the
>> > sequence functions without looking them up?) or have to remember an
>> > arbitrary name for
>>
>> ... what? (the last line seems to have been snipped).
>
> Maybe he couldn't remember what the arbitrary name was for? :)
"introducing another new function that people will probably never find
(how many cl programmers can remember all of the sequence functions
without looking them up?) or for which they will have to remember an
arbitrary name". OK, not the best sentence I've ever written.
-dan "the prepositions at the end of my sentences are things up with
which you will just have to put"
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Steven E. Harris
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <q67fzjfvvas.fsf@raytheon.com>
Raymond Wiker <·············@fast.no> writes:
> Take a look at the "streams" mechanisms for formatted output in
> C++. These are definitely more C++-like than printf & friends, but
> they are also vastly more painful to use.
How are they more painful? Can you show an illustrative example?
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
In article <···············@raytheon.com>,
Steven E. Harris <········@raytheon.com> wrote:
> Raymond Wiker <·············@fast.no> writes:
> > Take a look at the "streams" mechanisms for formatted output in
> > C++. These are definitely more C++-like than printf & friends, but
> > they are also vastly more painful to use.
> How are they more painful? Can you show an illustrative example?
To get this output for a variable f = 0.00001,
" 0.00001 1.00e-05\n"
in CL:
(format t "~10,5F ~8,2,,0E" f f)
in C:
printf("%10.5f $8.2e\n", f, f);
in C++:
std::cout << std::fixed << std::setw(10) << std::setprecision(5)
<< f << " "
<< std::scientific << std::setw(8) << std::setprecision(2)
<< f << std::endl;
Worse, in C++ the modifiers are global to the stream, so you have
to reset them to what they were after you're done.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Brian Downing <·············@lavos.net> wrote in message news:<·······················@sccrnsc02>...
> In article <···············@raytheon.com>,
> Steven E. Harris <········@raytheon.com> wrote:
> > Raymond Wiker <·············@fast.no> writes:
> > > Take a look at the "streams" mechanisms for formatted output in
> > > C++. These are definitely more C++-like than printf & friends, but
> > > they are also vastly more painful to use.
>
> > How are they more painful? Can you show an illustrative example?
>
> To get this output for a variable f = 0.00001,
>
> " 0.00001 1.00e-05\n"
>
> in CL:
> (format t "~10,5F ~8,2,,0E" f f)
>
> in C:
> printf("%10.5f $8.2e\n", f, f);
>
> in C++:
> std::cout << std::fixed << std::setw(10) << std::setprecision(5)
> << f << " "
> << std::scientific << std::setw(8) << std::setprecision(2)
> << f << std::endl;
>
> Worse, in C++ the modifiers are global to the stream, so you have
> to reset them to what they were after you're done.
>
> -bcd
They are painful but not quite that bad.
std::ostream out(std::cout.rdbuf()); // attach to cout's buffer
out << /* all that jazz */; // modify the temp stream, not
cout
And at least I don't have to reset the stream.
The idea behind all this is that if I am doing the same kind of
formatting repeatedly, I can write
operator<<(std::ostream& dst, Thing a)
which contains all that jazz, and then write
std::cout << Thing(f);
-- Tom Hyer
From: Steven E. Harris
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <q67r82xrf0q.fsf@raytheon.com>
Brian Downing <·············@lavos.net> writes:
> Worse, in C++ the modifiers are global to the stream, so you have to
> reset them to what they were after you're done.
For that, at least we now have the Boost ios_state saver types to help
ameliorate the burden.�
Footnotes:
� http://www.boost.org/libs/io/doc/ios_state.html
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
From: Marco Antoniotti
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F560B3F.6010800@cs.nyu.edu>
Brian Downing wrote:
> In article <···············@raytheon.com>,
> Steven E. Harris <········@raytheon.com> wrote:
>
>>Raymond Wiker <·············@fast.no> writes:
>>
>>>Take a look at the "streams" mechanisms for formatted output in
>>>C++. These are definitely more C++-like than printf & friends, but
>>>they are also vastly more painful to use.
>>
>
>>How are they more painful? Can you show an illustrative example?
>
>
> To get this output for a variable f = 0.00001,
>
> " 0.00001 1.00e-05\n"
>
> in CL:
> (format t "~10,5F ~8,2,,0E" f f)
>
> in C:
> printf("%10.5f $8.2e\n", f, f);
>
> in C++:
> std::cout << std::fixed << std::setw(10) << std::setprecision(5)
> << f << " "
> << std::scientific << std::setw(8) << std::setprecision(2)
> << f << std::endl;
>
> Worse, in C++ the modifiers are global to the stream, so you have
> to reset them to what they were after you're done.
Wow. I knew this things, but never quite thought about it.
Cheers
--
Marco
Brian Downing wrote:
> To get this output for a variable f = 0.00001,
>
> " 0.00001 1.00e-05\n"
>
> in CL:
> (format t "~10,5F ~8,2,,0E" f f)
>
> in C:
> printf("%10.5f $8.2e\n", f, f);
>
> in C++:
> std::cout << std::fixed << std::setw(10) << std::setprecision(5)
> << f << " "
> << std::scientific << std::setw(8) << std::setprecision(2)
> << f << std::endl;
Which should be pondered with care by those who protest
that FORMAT is insufficiently Lispy. It's true that for
multiple reasons[1] a more Lispy analogue of FORMAT would
be less painful than the above more C++y analogue of printf,
but the fact remains that string interpolation with a bit
of formatting control is, for most purposes, a rather good
way of generating formatted output.
[1] Because being Lispy is nicer than being C++y, and
because having real macros lets you wrap up some of
the pain.
--
Gareth McCaughan
.sig under construc
From: Douglas Philips
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F59386D.6010209@mac.com>
Apparently SOBIG.F whacked my ISPs news server, so I missed the
precursor to this, and who knows what else. Google was just too painful
to use.
Gareth McCaughan wrote:
> Which should be pondered with care by those who protest
> that FORMAT is insufficiently Lispy. It's true that for
> multiple reasons[1] a more Lispy analogue of FORMAT would
> be less painful than the above more C++y analogue of printf,
> but the fact remains that string interpolation with a bit
> of formatting control is, for most purposes, a rather good
> way of generating formatted output.
>
> [1] Because being Lispy is nicer than being C++y, and
> because having real macros lets you wrap up some of
> the pain.
How much pain can you wrap up if you want to manipulate those
specifications using string hacking functions? Oh right, hack a spec
from a string into some other structure, then hack it back into a string
so that FORMAT can then hack it apart yet again... Of course, what was I
thinking, that's so SIMPLE. ;-)
Which is better, strings as a shorthand over top of a rich set of
functions Or strings as the only way to "talk to" the formatter?
"All you would need" (famous last words) would be a standard canonincal
S-EXPR form that represents the same information that is the string.
Then the string can be just another way to make it easy for humans to
talk to the formatter, and the S-EXPR form would make it easy for
programs to too. And for programs to manipulate those formatting control
instructions.
<D\'gou
On Thu, 28 Aug 2003 15:53:26 +0100, Daniel Barlow <···@telent.net> wrote:
> Common operations get textually compressed so that they can be
> written more easily - just like regular expressions or mathematical
> formulae.
>
> (format nil "~{~A~^, ~}" my-list)
>
> How _would_ you redesign things to make this look less like line
> noise, without in the process [...] expanding it into three lines of
> code
Well, some people think this is desirable. See point 2 of
<http://ww.telent.net/diary/2003/8/#24.22595>
for an example.
Disclaimer: I _like_ LOOP and FORMAT, I just found this to be a funny
coincidence... :)
Cheers,
Edi.
Edi Weitz <···@agharta.de> writes:
> On Thu, 28 Aug 2003 15:53:26 +0100, Daniel Barlow <···@telent.net> wrote:
>
>> How _would_ you redesign things to make this look less like line
>> noise, without in the process [...] expanding it into three lines of
>> code
>
> Well, some people think this is desirable. See point 2 of
>
> <http://ww.telent.net/diary/2003/8/#24.22595>
>
> for an example.
:-)
Actually, I had regular expressions in mind as I wrote that article.
A regex for "string containing `foo' " or "string with optional
leading `the ', case-insensitive" is easy to write and read as text.
A regex for matching UK postal codes (as an example selected purely at
random) on the other hand, I think would look a lot less friendly as a
string. Perl-style regexes have the same desirable "describe simple
things succintly" attribute as format strings; like format strings
they also tend to become unreadable when they get complicated. But
that doesn't invalid the desirability of a compressed format for the
simple cases. I'd rather read
"content-(type|length):"
than
(:SEQUENCE "content-" (:REGISTER (:ALTERNATION "type" "length")) #\:)
Obviously cl-ppcre is better than format in that it lets me expand the
first form into the second as the problem grows, or if I need to
manipulate it programmatically. It's nice to have this migration
path, but that doesn't mean I want to start with the long form.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Douglas Philips
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F4F5867.7080306@mac.com>
Daniel Barlow wrote:
> Edi Weitz <···@agharta.de> writes:
>>Well, some people think this is desirable. See point 2 of
>> <http://ww.telent.net/diary/2003/8/#24.22595>
>>for an example.
Yes, indeed, that was amusing.
> Actually, I had regular expressions in mind as I wrote that article.
Reminds me of Olin Shivers reg-ex stuff for Scheme. Hmmm, I seem to have
misplaced that link...
> But that doesn't invalid the desirability of a compressed format for the
> simple cases. I'd rather read
>
> "content-(type|length):"
>
> than
>
> (:SEQUENCE "content-" (:REGISTER (:ALTERNATION "type" "length")) #\:)
Since that isn't do any 'non-constant' formatting, why would you?
<D\'gou
Douglas Philips <····@mac.com> writes:
> Daniel Barlow wrote:
>> simple cases. I'd rather read
>> "content-(type|length):"
>> than
>> (:SEQUENCE "content-" (:REGISTER (:ALTERNATION "type" "length")) #\:)
>
> Since that isn't do any 'non-constant' formatting, why would you?
OK, now I'm confused. Are you or are you not arguing that FORMAT
sucks (allowing for historical political compromise blah which I
think we can now take as read and not have to explicitly state in
every post) because it uses strings, and you'd rather use sexps?
If your point was that a sexp-based language for formatting would be a
nice _addition_ to Lisp, then I agree entirely. You just confused me
by flaming an existing facility that is not intended to solve your
problem, instead of decrying the absense of any facility that is.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Douglas Philips
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F4F6980.1020100@mac.com>
Daniel Barlow wrote:
> OK, now I'm confused. Are you or are you not arguing that FORMAT
> sucks (allowing for historical political compromise blah which I
> think we can now take as read and not have to explicitly state in
> every post) because it uses strings, and you'd rather use sexps?
Hmmm, now I am confused!
Format does two things: Interpolating strings into other strings and
turning non-string things into strings that are then also simultaneously
interpolated.
What I'm flaming is the 2nd part. FORMAT control-strings are a mini
language (maybe not so mini really) written as encoded strings instead
of as s-exprs. They are terse, powerful and inscrutable. They are not
subject to reflection (i.e. not extensible, partitionable, subject to
ordinary macro treatment, etc.).
> If your point was that a sexp-based language for formatting would be a
> nice _addition_ to Lisp, then I agree entirely. You just confused me
> by flaming an existing facility that is not intended to solve your
> problem, instead of decrying the absense of any facility that is.
I'm more confused now too.
I've never said to eliminate FORMAT, just deprecate it for something
cleaner. How sad that after 10 years, FORMAT is the acme of formatted
output for CL. There is clearly too much history to remove it, and
little point in provoking that debate.
I'm not sure I'm any less confused about why I confused you, but
hopefuly this mssage will diminish total confusion...
<D\'gou
Douglas Philips <····@mac.com> writes:
> I've never said to eliminate FORMAT, just deprecate it for something
> cleaner. How sad that after 10 years, FORMAT is the acme of formatted
> output for CL.
Before people came up with FORMAT, what do you think they used to do
formatted output? And why did they come up with FORMAT? Somebody (I
think it was Kent) recently commented on this issue here.
I'm sure your urge to change Common Lisp will not be received with big
enthusiasm by community. But if you really want to change things then
how about designing a better alternative to FORMAT and let people
choose? If it will be any better, resonable people will switch. You
will be able to measure the success of your invention by how many
people do it.
And I'm not trying to get in the way of progress. Just the opposite
-- I would be happy to see something better than FORMAT to emerge.
But talk about deprecation no earlier than that.
--
Janis Dzerins
Common Lisp -- you get more than what you see.
Janis Dzerins schrieb:
> ... And why did they come up with FORMAT?
Well. It is the third time I stumbled over this kind of problem. There
might be a name-giving-bottle-neck. Often one has a better version of
(example) car. Most named the new version my-car or car2.
Now this is the beginn of 100 years, so every name could end with the
last 2 digits of the actual year. Doing so the new-format becomes to
format03. What do you think about this?
stefan
lin8080 <·······@freenet.de> writes:
> Janis Dzerins schrieb:
>
> > ... And why did they come up with FORMAT?
>
> Well. It is the third time I stumbled over this kind of problem. There
> might be a name-giving-bottle-neck. Often one has a better version of
> (example) car. Most named the new version my-car or car2.
> Now this is the beginn of 100 years, so every name could end with the
> last 2 digits of the actual year. Doing so the new-format becomes to
> format03. What do you think about this?
Didn't you learn anything from the Y2k hype? You should at least call
it format2003. And if somebody else comes up with an idea to rewrite
format this year? Same month? Forget packages -- they are for wimps.
C programmers have done ok without namespaces for a long time now.
I think you should also put your name in every function you write so
people using it know whom to credit for writing that outstanding
function. An example would be: format-lin8080-2003-09-02-10-20.
--
Janis Dzerins
Common Lisp -- you get more than what you see.
Janis Dzerins schrieb:
> lin8080 <·······@freenet.de> writes:
> > Now this is the beginn of 100 years, so every name could end with the
> > last 2 digits of the actual year. Doing so the new-format becomes to
> > format03. What do you think about this?
>
> Didn't you learn anything from the Y2k hype? You should at least call
> it format2003.
But I think this hype is over. No more xxx-2000 programmes.
> And if somebody else comes up with an idea to rewrite
> format this year? Same month?
> Oh. Thats right. 03A 03B..? Uh better not.
> Forget packages -- they are for wimps.
aha
> C programmers have done ok without namespaces for a long time now.
> I think you should also put your name in every function you write so
> people using it know whom to credit for writing that outstanding
> function. An example would be: format-lin8080-2003-09-02-10-20.
No. My typo rate is to large for doing so. I take a look into the
HyperSpec, finding the longest syntax and numbering the let commands.
Maybe a new � in the book of records can be added?
stefan
On Fri, 29 Aug 2003 02:46:56 +0100, Daniel Barlow <···@telent.net> wrote:
> Actually, I had regular expressions in mind as I wrote that article.
> A regex for "string containing `foo' " or "string with optional
> leading `the ', case-insensitive" is easy to write and read as text.
> A regex for matching UK postal codes (as an example selected purely
> at random) on the other hand, I think would look a lot less friendly
> as a string. Perl-style regexes have the same desirable "describe
> simple things succintly" attribute as format strings; like format
> strings they also tend to become unreadable when they get
> complicated. But that doesn't invalid the desirability of a
> compressed format for the simple cases. I'd rather read
>
> "content-(type|length):"
>
> than
>
> (:SEQUENCE "content-" (:REGISTER (:ALTERNATION "type" "length")) #\:)
>
> Obviously cl-ppcre is better than format in that it lets me expand
> the first form into the second as the problem grows, or if I need to
> manipulate it programmatically. It's nice to have this migration
> path, but that doesn't mean I want to start with the long form.
FWIW, I completely agree with this. It would be nice if both FORMAT as
well as LOOP would allowed for more introspection, FORMAT mainly to
allow more complicated format controls to be described and manipulated
as s-expressions, LOOP mainly to be able to extend/change the syntax.
But this is of course said with hindsight and I wouldn't blame the
language designers for this "oversight." I just fear that it might be
hard to add this as a "layered standard" atop existing implementations
because it might be costly in terms of performance. But what do I
know?
Cheers,
Edi.
From: Christopher C. Stacy
Subject: extensability [Re: What's happening in the Lisp world today?]
Date:
Message-ID: <un0drnefa.fsf@dtpq.com>
>>>>> On 29 Aug 2003 10:27:50 +0200, Edi Weitz ("Edi") writes:
Edi> It would be nice if both FORMAT as well as LOOP would allowed
Edi> for more introspection, FORMAT mainly to allow more complicated
Edi> format controls to be described and manipulated as s-expressions,
Edi> LOOP mainly to be able to extend/change the syntax.
Originally (in Zetalisp) LOOP was extensible and you could
easily write your own "iteration paths" for it:
(DEFINE-LOOP-SEQUENCE-PATH (ARRAY-ELEMENT ARRAY-ELEMENTS)
AREF ACTIVE-ARRAY-LENGTH)
would allow you to then write the loop clause:
FOR X BEING THE ARRAY-ELEMENTS OF ARF
You could also write totally LOOP extensions using the hairy
DEFINE-LOOP-PATH macro, which took syntax description (path names,
prepositions,) and called a user-defined parser ("handler").
We also used to have an API to define new kinds of hash tables
that would work with the standard Lisp functions.
I'm not sure why either of those got taken out of the language;
they seemed like good ideas to me. (Probably people couldn't
agree on how to support them in the non-Lisp Machine systems,
and they weren't considered "commonly" critical.)
For FORMAT, you don't get to invent new sub-languages by introducing
new dispatch characters, but you can call arbitrary functionality
using "~//, and you also have ~V. I think some implementations
provide extensions to define new dispatch characters, though.
On the one hand, it would be nice to be able to define new characters.
On the other hand, there is a namespace issue, and the larger question
of whether format strings are a good place to allow users to make
customized language extensions at all.
If you want some other kind of template layout language based on
list structure, you can write one that generates format strings.
I think people do this all the time for report generation paackages.
People have been using string descriptions for formatted output for
about 50 years. It was a major problem that MACLISP didn't have
them and thus forced you to call output functions all over the place.
Common Lisp has a good and well-proven way of doing formatting.
If you have a truly better idea, you should implement it on top of
Common Lisp, let people widely experiment with it for a few years
to see if they like it, and then see about standardizing it by
letting it become a popular library (maybe included by all vendors).
······@dtpq.com (Christopher C. Stacy) writes:
> I'm not sure why either of those got taken out of the language;
> they seemed like good ideas to me. (Probably people couldn't
> agree on how to support them in the non-Lisp Machine systems,
> and they weren't considered "commonly" critical.)
Perhaps a reason that extensible LOOP wasn't put in the ANS was
because loop keywords are string designators? Personally, I think it
would have been much better to just make LOOP respect their symbol
identity, but without doing that, you'd have namespacing hell.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Daniel Barlow
Subject: Re: extensability [Re: What's happening in the Lisp world today?]
Date:
Message-ID: <87bru6wv1r.fsf@noetbook.telent.net>
······@dtpq.com (Christopher C. Stacy) writes:
> For FORMAT, you don't get to invent new sub-languages by introducing
> new dispatch characters, but you can call arbitrary functionality
> using "~//, and you also have ~V. I think some implementations
> provide extensions to define new dispatch characters, though.
~// is nice (I have a few functions for things like day-of-week and
month-of-year, which makes date printing simpler) but incredibly
verbose because it always looks in CL-USER for the function, and I
never put functions in CL-USER. I don't know how I'd go about
choosing a better default package, though.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Christopher C. Stacy
Subject: Re: extensability [Re: What's happening in the Lisp world today?]
Date:
Message-ID: <ur83275rx.fsf@dtpq.com>
>>>>> On Sun, 31 Aug 2003 01:05:36 +0100, Daniel Barlow ("Daniel") writes:
Daniel> ······@dtpq.com (Christopher C. Stacy) writes:
>> For FORMAT, you don't get to invent new sub-languages by introducing
>> new dispatch characters, but you can call arbitrary functionality
>> using "~//, and you also have ~V. I think some implementations
>> provide extensions to define new dispatch characters, though.
Daniel> ~// is nice (I have a few functions for things like day-of-week and
Daniel> month-of-year, which makes date printing simpler) but incredibly
Daniel> verbose because it always looks in CL-USER for the function, and I
Daniel> never put functions in CL-USER. I don't know how I'd go about
Daniel> choosing a better default package, though.
You can specify the package in the usual syntax (with colons):
(format t "~//DATE:A/" (get-universal-time))
It is verbose, but this avoids the problem of the next programmer
having to guess which function would be (theoretically) called by
a customized dispatch character.
From: Damien Kick
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <ovptiizxh0.fsf@email.mot.com>
Douglas Philips <····@mac.com> writes:
> I wish the ILC conference web site had the speakers on the schedule (I
> can only make it for one day, so the question of which day depends on
> who is speaking when...) But I digress.
I will not be able to make it anywhere near NYC during the 12-15
October. Is there anywhere that one can obtain/purchase transcripts
of the articles or copies of the papers submitted, for ILC past and
present? I've been looking at the stuff for ILC2002 and I can only
find abstracts.
On 02 Sep 2003 16:34:03 -0500, Damien Kick <······@email.mot.com> wrote:
> I will not be able to make it anywhere near NYC during the 12-15
> October. Is there anywhere that one can obtain/purchase transcripts
> of the articles or copies of the papers submitted, for ILC past and
> present? I've been looking at the stuff for ILC2002 and I can only
> find abstracts.
Franz is selling the ILC 2002 proceedings. Follow the link from their
homepage <http://www.franz.com/>.
Edi.
Mario S. Mommer <········@yahoo.com> wrote in message news:<··············@cupid.igpm.rwth-aachen.de>...
> ········@hotmail.com (Tuang) writes:
> > I noticed that he posted several Arc-related updates,
> > one every few weeks or so, for a period of a few weeks (or months).
> > Then the updates stopped, and as far as I can tell, he hasn't changed
> > a single word on his Arc site for about two years, despite having
> > continued to update other areas of his site regularly. So I wondered
> > whether the initial brief flurry of progress reports followed by two
> > years of total silence meant that there was no longer any progress to
> > report, progress but a change of heart about publicly reporting it, or
> > some other possibility.
>
> Hm... Sounds like it really tanked.
That's usually the case when a formerly active project website has no
further updates after this much time. However, Edi correctly points
out that Graham is tying his name to "ARC" in the upcoming conference,
so maybe he just changed his mind about wanting outside input. I guess
I'll have to wait for some sort of conference report for an answer to
this little mystery.
>
> > Thinking someone here might know, I asked. I find it odd that you
> > would confuse a curiosity about the disappearance of status reports
> > long ago with an expectation that "a new language would be finished in
> > a few weeks".
>
> People here are a bit defensive. Don't be surprised, we have been
> taking the "something serious being done in lisp" troll for ages,
> which (rightly) pisses some people off like nobody's business. You
> don't look too much like such a troll to me, but hey.
Thanks. Being new, I haven't seen such trolls, but I would imagine
that trying to find out what's really going on would be a natural
thing for anyone investigating a new technology to do. Maybe some of
those "trolls" aren't trolls, either. It's harder to get the lay of
the land with Lisp (esp. when I mean the family, incl. Scheme, Arc,
maybe others I don't know exist), than with something like Java (I can
get Java news from any local newspaper) or Python (one stop shopping).
Of course, I believe you that genuine "ha ha, Lisp is dead" trolls
exist, but I would guess that there would be a lot of people who are
interested, but given the lack of commercial incentives ("Want a job
with us? Go learn Java!") just want to get a better sense of what
they're getting into, and how best to allocate their limited time and
attention, given the time it's likely to require.
I was just asking "what's happening now", but even an outright
expression of scepticism ("nothing's happening, is it?") wouldn't be
surprising from someone who is nevertheless intrigued by Lisp and
hoping to be persuaded to invest a lot of time in a skill that the
market seems to be warning is a waste of time. I wouldn't think it
would behoove the Lisp community to treat all investigators with
concerns as trolls.
In my own case, I'm less concerned about the market because I'm not
looking for employment as a staff coder, but I still need to get a
realistic overview (what's coming on strong, what's fading away, etc.)
in order to figure out how to approach learning to use Lisp in real
practice.
>
> > I'm not sure where better to ask. I'm just trying to get an overview
> > of what's happening in an area of computing that I'm finding
> > increasingly interesting.
>
> Maybe if you tell us what you plan to do with this information it is
> easier to help you.
Good point. Part of what I want is a set of better ways to think about
programming. I'm now absolutely certain that I want to use some form
of Lisp for this. Scheme seems a good choice for this, because I want
to pair it with teaching materials such as SICP that tend to use
Scheme. I can make use of the ideas when working in other, more
popular, languages. I'd like to learn more about AI, too, and many of
those materials use CL, so I'll need to learn both, it seems.
Eventually, I'd like to use Lisp itself for real production work, and
that seems to imply Common Lisp. Well, then, it would be nice if the
training platform I use is the same as the production platform, so I
can spend less time learning implementation details and more time
learning Lisp programming. In all likelihood, I'll be doing most
learning and experimenting on a Windows laptop, but future production
work will probably be deployed on Linux servers, given the way I see
the industry overall evolving. It sort of appears as though the best
production platforms are the commercial ones, but they are *very*
expensive, especially for two platforms and considering that I don't
know if I'll ever make any money from Lisp.
Open source implementations are affordable, but given the limited time
I have for Lisp, I don't want to have to learn several of them just
because A isn't available for Windows, and B isn't good enough for
production, and C, well, C is really a ghost project that savvy
Lispers (unbeknownst to me) are mostly abandoning in favor of D, or E,
but that's crippled demoware, but at least it includes a good editor
and installer because the open source versions also will probably
require the massive time sink of learning Emacs, then learning some
needed add-on Emacs module, then learning to install thru the
dependencies (perhaps including Cygwin) and configuration (all of
which time doesn't contribute to learning Lisp at all....)
If it were Perl or Python or Java or C... the choice would be easy
(because I know enough about them to answer my own questions.) I don't
know enough about the reality of the Lisp world to make the decisions
I need to make to avoid potentially wasting most of the time I have
available for Lisp on non-Lisp overhead.
And wanting to know about which domains are experiencing an increase
in Lisp usage is just part of scanning the horizon for projects that
might provide justification for allocating additional time (or money)
to Lisp.
That's what I plan to do with this info, so I really am looking for
well-informed, opinionated, judgmental overviews, but I don't think
that makes me a troll. ;-)
Thanks.
On 27 Aug 2003 13:58:33 -0700, ········@hotmail.com (Tuang) wrote:
>Good point. Part of what I want is a set of better ways to think about
>programming. I'm now absolutely certain that I want to use some form
>of Lisp for this. Scheme seems a good choice for this, because I want
>to pair it with teaching materials such as SICP that tend to use
>Scheme. I can make use of the ideas when working in other, more
>popular, languages. I'd like to learn more about AI, too, and many of
>those materials use CL, so I'll need to learn both, it seems.
I have been in this same boat, I settled on Common Lisp first because
of my desire to do real work. After learning to work with Common
Lisp, most the Scheme code I've looked at has been trivially easy to
understand. I personally think it's better to learn the more
difficult and expansive of the two and then look at the more
minimalist Scheme and understand it, than to going the other way.
Although that's just my opinion.
>
>Eventually, I'd like to use Lisp itself for real production work, and
>that seems to imply Common Lisp. Well, then, it would be nice if the
>training platform I use is the same as the production platform, so I
>can spend less time learning implementation details and more time
>learning Lisp programming. In all likelihood, I'll be doing most
>learning and experimenting on a Windows laptop, but future production
>work will probably be deployed on Linux servers, given the way I see
>the industry overall evolving. It sort of appears as though the best
>production platforms are the commercial ones, but they are *very*
>expensive, especially for two platforms and considering that I don't
>know if I'll ever make any money from Lisp.
Yeah, I've run into this same problem myself. I haven't settled on a
good platform for doing Gui based work, primarily because of the
expense involved with ACL, and it only licenses you for one platform.
Currently I use EMACS + ILISP + CLISP because it's easy to configure
on Windows, OS X and Linux.
>
>Open source implementations are affordable, but given the limited time
>I have for Lisp, I don't want to have to learn several of them just
>because A isn't available for Windows, and B isn't good enough for
>production, and C, well, C is really a ghost project that savvy
>Lispers (unbeknownst to me) are mostly abandoning in favor of D, or E,
>but that's crippled demoware, but at least it includes a good editor
>and installer because the open source versions also will probably
>require the massive time sink of learning Emacs, then learning some
>needed add-on Emacs module, then learning to install thru the
>dependencies (perhaps including Cygwin) and configuration (all of
>which time doesn't contribute to learning Lisp at all....)
Man, just bite the bullet and learn Emacs. :) IMO you won't regret
it. I started using Emacs about 8 months ago, and I don't use
anything else now, and I often wonder how I got along without it.
Just do it!! ;)
>If it were Perl or Python or Java or C... the choice would be easy
>(because I know enough about them to answer my own questions.) I don't
>know enough about the reality of the Lisp world to make the decisions
>I need to make to avoid potentially wasting most of the time I have
>available for Lisp on non-Lisp overhead.
>
I haven't used Perl much, but there is already a fork off python
called Stackless, and with Java and C the situation is the same or
worse as it is with Lisp. Ultimately it takes time and reading to get
to know the lay of the land.
I'm still in my learning journey with Lisp myself, I've been working
with it about as long as Emacs, but there are some very intelligent
and knowledgeable people on this newsgroup. They have helped me
immeasureably, and contrary to what some of them may *want* you to
think, they actually can be very helpful. ;)
umm...for this thread, you guys might want to ignore my sig..D'oh!!
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
Doug Tolton <·······@yahoo.com> wrote
>
> I'm still in my learning journey with Lisp myself, I've been working
> with it about as long as Emacs, but there are some very intelligent
> and knowledgeable people on this newsgroup. They have helped me
> immeasureably, and contrary to what some of them may *want* you to
> think, they actually can be very helpful. ;)
Yes, perhaps if I limit my questions here to technical details about
The One True Lisp I might find some good answers. I can probably take
my "get a perspective of what's going on and what it might mean for
me" questions to other venues with fewer sacred cows and rely on this
one as simply a technical resource. Having a good technical resource
is no small matter, especially when working with a less-commonly used
technology.
Mario S. Mommer wrote:
> If you observe carefully, it is not as fragmented as you may think. It
> is not as loud as other communities, but certainly not fragmented.
Eric S. Raymond once called the Lisp community "small but nevertheless
deeply fragmented" (http://pythonology.org/success&story=esr). Maybe
that's where the original poster's impression came from.
Matthias <····@yourself.pl> writes:
> Eric S. Raymond once called the Lisp community "small but
> nevertheless deeply fragmented"
> (http://pythonology.org/success&story=esr). Maybe that's where the
> original poster's impression came from.
well, if you consider Scheme a Lisp, then the community is deeply
fragmented.
but that's exactly analogous to the "scripting language" community
being deeply fragmented: Perl, Python, sh & Ruby are all scripting
languages, right? or the "OO language with C-like syntax" community
being likewise deeply fragmented.
not too mention the assembly language community.
define "is",
--m
--
All ITS machines now have hardware for a new machine instruction --
BFM
Be Fruitful and Multiply.
Please update your programs.
"Michael Livshin" <······@cmm.kakpryg.net> wrote in message
···················@laredo.verisity.com.cmm...
> Matthias <····@yourself.pl> writes:
>
> > Eric S. Raymond once called the Lisp community "small but
> > nevertheless deeply fragmented"
> > (http://pythonology.org/success&story=esr). Maybe that's where the
> > original poster's impression came from.
>
> well, if you consider Scheme a Lisp, then the community is deeply
> fragmented.
And if you don't consider Scheme a Lisp, then the community is *really*
deeply fragmented.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> And if you don't consider Scheme a Lisp, then the community is *really*
> deeply fragmented.
what part of "different laguage" is so hard to understand?^W^W^W^W^W^W^W^W^W^W
what meaning do you assign the term "the Lisp community"? what
interesting traits do the members of "the Lisp community" (as you
define it) have in common? how exactly is the noosphere made a better
place to think by asserting the existence of "the Lisp community" (as
you define it)?
--
SIGTHTBABW: a signal sent from Unix to its programmers at random
intervals to make them remember that There Has To Be A Better Way.
-- Erik Naggum
Michael Livshin wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > And if you don't consider Scheme a Lisp, then the community is *really*
> > deeply fragmented.
>
> what part of "different laguage" is so hard to
understand?^W^W^W^W^W^W^W^W^W^W
>
> what meaning do you assign the term "the Lisp community"? what
> interesting traits do the members of "the Lisp community" (as you
> define it) have in common? how exactly is the noosphere made a better
> place to think by asserting the existence of "the Lisp community" (as
> you define it)?
I think Tuang's original post expressed something that might help define a
useful "Lisp community":
"I'm trying to learn Lisp because I'm becoming fascinated with several of
the ideas it embodies. I'm not referring to Common Lisp or Scheme per se,
much less any specific implementation, but to the ideas that they seem to
share (to the limited extent I understand them so far.)"
There are significant common ideas between all Lisps, including Scheme,
which are not present in other kinds of non-Lisp languages. Important ideas
relating to syntax, functional abstraction, syntactical abstraction, and
ways of approaching problems. Someone who understands the rationale behind
one ought to be capable of understanding the rationale behind the other, in
a way that's not true of someone only familiar with non-Lisp languages.
I think there are plenty of reasons that a Lisp community which embraces
both Common Lisp and Scheme, as well as other Lisp variants, as varying
expressions of a common set of Good Ideas, would make the noosphere a better
place. I can explicate further if you wish. The previous paragraph hints
at some of the reasons. That's not to say that there isn't a place for a
Common Lisp community (e.g. this group), a Scheme community, etc.
As for the traits of members, I'd say the traits of a community capable of
focusing on and honoring the commonalities between Lisps would be very
positive traits. I'd turn the question around and ask why the opposite
would be (or is) a good thing?
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> I think Tuang's original post expressed something that might help define a
> useful "Lisp community":
>
> "I'm trying to learn Lisp because I'm becoming fascinated with several of
> the ideas it embodies. I'm not referring to Common Lisp or Scheme per se,
> much less any specific implementation, but to the ideas that they seem to
> share (to the limited extent I understand them so far.)"
but this is a kind of circular reasoning. you are saying "let's
assert that a community exists because newbies expect it to be there".
> There are significant common ideas between all Lisps, including
> Scheme, which are not present in other kinds of non-Lisp languages.
> Important ideas relating to syntax, functional abstraction,
> syntactical abstraction, and ways of approaching problems. Someone
> who understands the rationale behind one ought to be capable of
> understanding the rationale behind the other, in a way that's not
> true of someone only familiar with non-Lisp languages.
the only idea of the above that justifies a "Lisp community" is
"syntactic abstraction". the rest are a better match for "FP
community", really.
and if you look closely, you'll find that Common Lisp's and Scheme's
ideas of syntactic abstraction are actually very, very different.
> I think there are plenty of reasons that a Lisp community which
> embraces both Common Lisp and Scheme, as well as other Lisp
> variants, as varying expressions of a common set of Good Ideas,
> would make the noosphere a better place. I can explicate further if
> you wish.
> [ snip ]
> positive traits. I'd turn the question around and ask why the
> opposite would be (or is) a good thing?
I think I finally understand the reason I've butted in this thread in
the first place, so allow me to explain it and then decide whether we
are actually arguing.
when one says "the community is deeply fragmented", one implies two
things:
* fragmentation is bad.
* the community in question can (and should) be unified.
I claim that the phrase "the Lisp community is deeply fragmented", at
least if taken to mean "well, you see, there's Common Lisp and there's
Scheme", is pure propaganda, since the differences between CL and
Scheme (and the communities thereof) exist for a reason, are not bad,
and doing away with those differences is in nobody's interest.
--
You have a tendency to feel you are superior to most computers.
Michael Livshin wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>>I think Tuang's original post expressed something that might help define a
>>useful "Lisp community":
>> "I'm trying to learn Lisp because I'm becoming fascinated with several of
>>the ideas it embodies. I'm not referring to Common Lisp or Scheme per se,
>>much less any specific implementation, but to the ideas that they seem to
>>share (to the limited extent I understand them so far.)"
> but this is a kind of circular reasoning. you are saying "let's
> assert that a community exists because newbies expect it to be there".
It's not circular reasoning. We are discussing this section from
Tuang's second post:
I've already begun, and I like both CL and Scheme so much that I'm
curious to know more about what's going on in the Lisp world today. I
pay attention to new developments and trends in other languages I work
with, and now that I'm finding Lisp so interesting, I'm just doing the
same with Lisp. It's a much smaller community than the big, popular
languages (Java, C++, etc.) and more fragmented than most of the small
languages (Python, Ruby, etc., presumably because of Lisp's age), so
it makes it a little harder to find some types of info.
Matthias later wrote
Eric S. Raymond once called the Lisp community "small but
nevertheless deeply fragmented"
(http://pythonology.org/success&story=esr). Maybe that's where the
original poster's impression came from.
to which you commented:
well, if you consider Scheme a Lisp, then the community is deeply
fragmented.
Since Matthias was talking about Tuang's view of the Lisp community
the real question is: "Does Tuang consider Scheme a Lisp?".
Anton's (and my quote) clearly shows this is the case.
Whether there actually exists such a community is a different
discussion.
To that end, count the number of people that post both in
comp.lang.scheme and comp.lang.lisp. And draw your own
conclusion.
--
Jens Axel S�gaard
Jens Axel S�gaard <······@jasoegaard.dk> wrote
> We are discussing this section from
> Tuang's second post:
>
> I've already begun, and I like both CL and Scheme so much that I'm
> curious to know more about what's going on in the Lisp world today. I
> pay attention to new developments and trends in other languages I work
> with, and now that I'm finding Lisp so interesting, I'm just doing the
> same with Lisp. It's a much smaller community than the big, popular
> languages (Java, C++, etc.) and more fragmented than most of the small
> languages (Python, Ruby, etc., presumably because of Lisp's age), so
> it makes it a little harder to find some types of info.
>
> Matthias later wrote
>
> Eric S. Raymond once called the Lisp community "small but
> nevertheless deeply fragmented"
> (http://pythonology.org/success&story=esr). Maybe that's where the
> original poster's impression came from.
>
> to which you commented:
>
> well, if you consider Scheme a Lisp, then the community is deeply
> fragmented.
>
> Since Matthias was talking about Tuang's view of the Lisp community
> the real question is: "Does Tuang consider Scheme a Lisp?".
>
> Anton's (and my quote) clearly shows this is the case.
Wow, a debate over what I'm really thinking. I feel like Alan
Greenspan. ;-)
I think I'll weigh in on this debate on your side: yes, from my newbie
perspective, Scheme is a Lisp. The idea of using parentheses and
prefix notation to directly code in the parse tree, of code is data,
of programming in a functional style, of having functions as just
another data type to pass in to and return from other functions, of
having a "top level" to talk to that can be used to directly interact
with the components of a growing program, of having the extraordinary
ability to create new languages and whole programming paradigms on the
fly to suit the problem domain.... These things all in one language I
call "Lisp" (perhaps not knowing any better).
I don't yet know what people are talking about when they say that Lisp
and Scheme are "completely different", other than that CL seems to
come with an enormous, complicated set of add-ons (including, some
say, a lot of legacy baggage), and that CL seems generally reputed to
be the best choice among the Lisps for real production work. Beyond
that, I don't know and I'm not sure I dare ask. ;-)
In article <····························@posting.google.com>,
········@hotmail.com (Tuang) wrote:
> I think I'll weigh in on this debate on your side: yes, from my newbie
> perspective, Scheme is a Lisp. The idea of using parentheses and
> prefix notation to directly code in the parse tree, of code is data,
Just FYI, not to inflame this (very old) debate, Scheme programs are
actually not represented as parse trees. Scheme has a syntax for code,
and a syntax for data, and they happen to be the same, but Scheme
programs, like every other programming language and unlike Common Lisp,
are strings, not lists.
This is mostly an academic issue, but it has some practical implications,
e.g. the semantics of QUOTE. In Common Lisp the following:
(defun foo () '(1 2 3))
(eq (foo) (foo))
is guaranteed to return T. The Scheme equivalent is not.
Note: There was a very long thread on this recently in comp.lang.scheme.
If you want to respond to this post please go read that thread first.
E.
From: Joe Marshall
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <he41eusd.fsf@ccs.neu.edu>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <····························@posting.google.com>,
> ········@hotmail.com (Tuang) wrote:
>
>> I think I'll weigh in on this debate on your side: yes, from my newbie
>> perspective, Scheme is a Lisp. The idea of using parentheses and
>> prefix notation to directly code in the parse tree, of code is data,
>
> Just FYI, not to inflame this (very old) debate, Scheme programs are
> actually not represented as parse trees. Scheme has a syntax for code,
> and a syntax for data, and they happen to be the same, but Scheme
> programs, like every other programming language and unlike Common Lisp,
> are strings, not lists.
This isn't true! Scheme programs, while they are not *required* to be
lists, are certainly required to be isomorphic to lists for the
purposes of macro expansion.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <····························@posting.google.com>,
> > ········@hotmail.com (Tuang) wrote:
> >
> >> I think I'll weigh in on this debate on your side: yes, from my newbie
> >> perspective, Scheme is a Lisp. The idea of using parentheses and
> >> prefix notation to directly code in the parse tree, of code is data,
> >
> > Just FYI, not to inflame this (very old) debate, Scheme programs are
> > actually not represented as parse trees. Scheme has a syntax for code,
> > and a syntax for data, and they happen to be the same, but Scheme
> > programs, like every other programming language and unlike Common Lisp,
> > are strings, not lists.
>
> This isn't true! Scheme programs, while they are not *required* to be
> lists, are certainly required to be isomorphic to lists for the
> purposes of macro expansion.
This issue was also discussed at length in the recent thread on
comp.lang.scheme. I'll just note here that "are not required to be lists"
and "are not [necessarily] lists" mean the same thing.
E.
From: Joe Marshall
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <ptipd8yg.fsf@ccs.neu.edu>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
>
>> ···@jpl.nasa.gov (Erann Gat) writes:
>>
>> > In article <····························@posting.google.com>,
>> > ········@hotmail.com (Tuang) wrote:
>> >
>> >> I think I'll weigh in on this debate on your side: yes, from my newbie
>> >> perspective, Scheme is a Lisp. The idea of using parentheses and
>> >> prefix notation to directly code in the parse tree, of code is data,
>> >
>> > Just FYI, not to inflame this (very old) debate, Scheme programs are
>> > actually not represented as parse trees. Scheme has a syntax for code,
>> > and a syntax for data, and they happen to be the same, but Scheme
>> > programs, like every other programming language and unlike Common Lisp,
>> > are strings, not lists.
>>
>> This isn't true! Scheme programs, while they are not *required* to be
>> lists, are certainly required to be isomorphic to lists for the
>> purposes of macro expansion.
>
> This issue was also discussed at length in the recent thread on
> comp.lang.scheme. I'll just note here that "are not required to be lists"
> and "are not [necessarily] lists" mean the same thing.
When is a list not a list? Since the Scheme reader cannot know whether
a form is to be macroexpanded or not, and since the macroexpander takes
forms in list form, the reader must produce something acceptable to
CAR, CDR and PAIR? (CONSP). Ok, so it could be some sort of bizarre
reader-constructed object, but if you can take CAR and CDR and PAIR?
of it, exactly how does it differ from a list?
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> >
> >> ···@jpl.nasa.gov (Erann Gat) writes:
> >>
> >> > In article <····························@posting.google.com>,
> >> > ········@hotmail.com (Tuang) wrote:
> >> >
> >> >> I think I'll weigh in on this debate on your side: yes, from my newbie
> >> >> perspective, Scheme is a Lisp. The idea of using parentheses and
> >> >> prefix notation to directly code in the parse tree, of code is data,
> >> >
> >> > Just FYI, not to inflame this (very old) debate, Scheme programs are
> >> > actually not represented as parse trees. Scheme has a syntax for code,
> >> > and a syntax for data, and they happen to be the same, but Scheme
> >> > programs, like every other programming language and unlike Common Lisp,
> >> > are strings, not lists.
> >>
> >> This isn't true! Scheme programs, while they are not *required* to be
> >> lists, are certainly required to be isomorphic to lists for the
> >> purposes of macro expansion.
> >
> > This issue was also discussed at length in the recent thread on
> > comp.lang.scheme. I'll just note here that "are not required to be lists"
> > and "are not [necessarily] lists" mean the same thing.
>
> When is a list not a list? Since the Scheme reader cannot know whether
> a form is to be macroexpanded or not, and since the macroexpander takes
> forms in list form, the reader must produce something acceptable to
> CAR, CDR and PAIR? (CONSP). Ok, so it could be some sort of bizarre
> reader-constructed object, but if you can take CAR and CDR and PAIR?
> of it, exactly how does it differ from a list?
How many times are you going to make me repeat myself? All these
questions are asked and answered in the thread that begins with message id
··············@ID-60390.news.dfncis.de. Go ye forth and read it.
(I note in passing that you participated in that thread.)
E.
From: Joe Marshall
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <ad9scxs8.fsf@ccs.neu.edu>
···@jpl.nasa.gov (Erann Gat) writes:
> How many times are you going to make me repeat myself? All these
> questions are asked and answered in the thread that begins with message id
> ··············@ID-60390.news.dfncis.de. Go ye forth and read it.
>
> (I note in passing that you participated in that thread.)
Yes. I understand the issues. I am simply responding to your
original assertion that `Scheme programs, like every other programming
language and unlike Common Lisp, are strings, not lists'. This is a
somewhat vague statement, and what it implies is not true.
Here is why it is vague:
1. Common Lisp programs, when being run, are generally composed of
chunks of machine code or byte code.
2. Common Lisp programs, when being read or written by a human
being, are composed of sequences of characters in a file.
3. The Common Lisp function EVAL takes a piece of list structure as
an argument, but it is *permitted* to translate that list
structure into a convenient internal form for interpretation.
So a Common Lisp program may have several different representations
over its lifetime. Only at certain points in its lifetime
(macroexpansion time, or when invoking the *evalhook*) is it required
to have a list representation. (And by this I mean that the
representation is indistinguishable from a list using the standard
Common Lisp predicates. You could imagine some funky `augmented' cons
cell structure that was CONSP, and worked with CAR and CDR, but had a
hidden SYS:%%MAGIC-SLOT field. Such a thing wouldn't `be a list', but
not in any meaningful way.)
Here is why it is not true:
1. Scheme programs, when being run, are generally composed of
chunks of machine code (or byte code).
2. Scheme programs, when being read or written by a human
being, are composed of sequences of characters in a file.
3. The Scheme function EVAL takes a piece of list structure as
an argument, but it is *permitted* to translate that list
structure into a convenient internal form for interpretation.
So a Scheme program may have several different representations over
its lifetime. At certain points in its lifetime (macroexpansion time)
it is required to have a list representation. (And by this I mean
that the representation is indistinguishable from a list using the
standard Scheme predicates.) The macro system of Scheme is a mapping
from lists->lists, so the macro system simply would not work if
programs behaved differently from lists.
The *only* difference between the two is this:
1. Common Lisp programs are read by the Common Lisp READ function.
2. Scheme programs need not be read by the Scheme READ function.
This is `a difference that makes no difference' because the macro
system in Scheme requires exactly the same sort of lists that the READ
function would have produced.
I've decided to go ahead and reply to this at length and start a new
thread because there seems to be a great deal of confusion on these
points.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > How many times are you going to make me repeat myself? All these
> > questions are asked and answered in the thread that begins with message id
> > ··············@ID-60390.news.dfncis.de. Go ye forth and read it.
> >
> > (I note in passing that you participated in that thread.)
>
> Yes. I understand the issues. I am simply responding to your
> original assertion that `Scheme programs, like every other programming
> language and unlike Common Lisp, are strings, not lists'. This is a
> somewhat vague statement, and what it implies is not true.
That depends on what you think it implies.
The semantics of Common Lisp, unlike every other programming langauge, are
defined on Lisp objects. The semantcs of Scheme, like every other
programming language except Common Lisp, are defined on strings. The
syntax of those strings happens to be the same as the syntax for lists,
but this in and of itself does not require there to be any particular
relationship between the two.
Of course, one obvious way to implement Scheme is to use the same parser
for both programs and lists (since they have the same syntax), and at a
casual glance it would seem to be crazy to do anything else. And yet
there are Scheme implementations that really do have two separate parsers,
one for programs, and a different one for lists. Schemers have what they
consider to be perfectly sound reasons for doing it this way.
This is one indication of the truly deep gulf that separates the two
languages. The Lisp-1 vs Lisp-2 issue is a red herring; Scheme and Lisp
really represent two completely different mindsets about how programming
languages ought to work, indeed about what programs *are*. That CL uses
list syntax for programs is a reflection of its actual semantics. That
Scheme uses list syntax for programs is mostly a historical accident. In
fact, there are people in the Scheme community who think that using list
syntax for programs is unnecessarily confusing and ought to be changed.
> 3. The Scheme function EVAL takes a piece of list structure as
> an argument
That is not necessarily true. Scheme's EVAL is defined to take "a Scheme
program represented as data." The standard does not require that those
data be lists, and furthermore it does not require that even if they are
lists that they be the particular lists you would get by using the READ
function to parse a Scheme program. Granted, the examples shown in the
standard do it this way, but those are just that: examples. The standard
does not require this behavior. A Scheme EVAL that took Scheme programs
represented as strings would be compliant with the standard, and arguably
more in keeping with the evolving spirit of Scheme.
This is really the heart of the schism between Lisp and Scheme. Both have
their roots in a Lisp where there was a well-defined relationship between
code and lists. Scheme has been gradually drifting away from that idea
and towards the rest of the world where there is a clear distinction
between program and data (at least at the user level) while CL has
maintained the original idea.
Of course, because Scheme has its roots in Lisp, and because the idea of a
clearly defined relationship between code and data is so appealling, you
will find many implementations of Scheme where that relatinship is
maintained, where programs are parsed by READ, and where you can write
macros using backquote. But this behavior is not required by the Scheme
standard, and indeed these ideas are slowly being deprecated in the Scheme
mindset.
> So a Scheme program may have several different representations over
> its lifetime. At certain points in its lifetime (macroexpansion time)
> it is required to have a list representation. (And by this I mean
> that the representation is indistinguishable from a list using the
> standard Scheme predicates.)
No, this is not true. (Well, the first sentence is true, but the rest
isn't.) It may be that Scheme programs are required at some point in
their lives to have a representation that is isomorphic to lists (and even
that is questionable) but it is not required to be represented as a list.
And, more to the point, it is not required to be represented as any
particular kind of list, and (most important) that representation is not
required to be accessible to the user in any way.
In Common Lisp the program represented by the string "(defun foo () t)" is
required to be represented by a list with four elements. In Scheme, the
program represented by the string "(define foo (lambda () #T))" could be
represented as a list of three elements, or it could be represented as a
structure, or a vector, or even a list that looks like: (program :type
:definition :name "foo" :value (lambda-expression :arglist () :body #T)))
> The macro system of Scheme is a mapping
> from lists->lists, so the macro system simply would not work if
> programs behaved differently from lists.
No, that is not true. Scheme's macro system is more or less the same as
Dylan's. Dylan programs may be represented as lists under the hood, but
that representation is not available to the user. The situation is the
same in both langauges. Dylan's syntax makes this clear; Scheme's syntax
makes it confusing (which is one of the arguments for abandoning the
syntax).
> The *only* difference between the two is this:
>
> 1. Common Lisp programs are read by the Common Lisp READ function.
>
> 2. Scheme programs need not be read by the Scheme READ function.
>
> This is `a difference that makes no difference' because the macro
> system in Scheme requires exactly the same sort of lists that the READ
> function would have produced.
I disagree. This is a difference that makes an enormous difference. It
can actually change the semantics of programs. In particular, it changes
the semantics of QUOTE.
But there is a much deeper issue here. Just as Lispers shudder at
Python's string-based EVAL because strings provide too little structure,
Schemers (and Dylaners and MLers and Haskellers, with whom Schemers have
much mindset in common) shudder at Lisp's list-based eval (there was no
EVAL in Scheme before R5RS) because they think that lists provide too
little structure for representing programs. Representing programs as
lists admits all sorts of horrible (in their minds) things like
unintentional symbol capture and whatnot. The Scheme/Dylan/ML/Haskell
mindset is to come up with a principled solution to this problem (hygienic
macros) whereas the CL mindset is to come up with a workable hack (Lisp-2)
and move on. Lisp-1 vs Lisp-2 is not the real issue, it's just a proxy
for the real issue, which is whether or not representing programs as lists
is really a good idea. Lispers think it is, and Schemers (at least as
represented by their standard) think it isn't. (Note that representing
programs as lists (which is what Lisp does) is NOT the same thing as using
the same syntax for writing programs as you do for writing lists (which is
what Scheme does)).
(NOTE: You may find yourself tempted to cite section 1.2 of R5RS in
rebuttal to my position. My claim is that section 1.2 is an artifact of
Scheme's history, not an accurate reflection of the current Scheme
mindset. I predict that if there is ever an R6RS that this passage will
disappear.)
One last thing: please note the title of this post. I do not have a
position about whether Scheme is or is not a Lisp. I think it's a waste
of time to split those kinds of semantic hairs. The purpose of this post
was not to take a position, but merely to explain why some people think
that Scheme is not a Lisp despite the fact that it looks like a Lisp and
even calls itself a Lisp.
E.
Erann Gat wrote:
> But there is a much deeper issue here. Just as Lispers shudder at
> Python's string-based EVAL because strings provide too little structure,
> Schemers (and Dylaners and MLers and Haskellers, with whom Schemers have
> much mindset in common) shudder at Lisp's list-based eval (there was no
> EVAL in Scheme before R5RS) because they think that lists provide too
> little structure for representing programs.
> Representing programs as
> lists admits all sorts of horrible (in their minds) things like
> unintentional symbol capture and whatnot.
Hey, remember the truce?
I am sorry, but I simply can't understand what the choice of
representation of programs have to do with how the macro system works.
It is possible for a Scheme implementation to use a list representation
of programs. There is (for Scheme) one problem with this choice. If the
implementation needs to give the programmer an syntax error and wants
to provide file, line number and column position - where should it
put that information? One can not put the information in the Scheme
symbols, since they don't (in many implementions) have property lists.
If they had, it would be more reasonable to use lists for the
representation.
--
Jens Axel S�gaard
In article <·························@dread12.news.tele.dk>,
=?ISO-8859-1?Q?Jens_Axel_S=F8gaard?= <······@jasoegaard.dk> wrote:
> Erann Gat wrote:
>
> > But there is a much deeper issue here. Just as Lispers shudder at
> > Python's string-based EVAL because strings provide too little structure,
> > Schemers (and Dylaners and MLers and Haskellers, with whom Schemers have
> > much mindset in common) shudder at Lisp's list-based eval (there was no
> > EVAL in Scheme before R5RS) because they think that lists provide too
> > little structure for representing programs.
>
> > Representing programs as
> > lists admits all sorts of horrible (in their minds) things like
> > unintentional symbol capture and whatnot.
>
> Hey, remember the truce?
Sorry, did you see what I wrote as critical? It wasn't intended to be.
(Or did you just forget to put in a smiley?)
> I am sorry, but I simply can't understand what the choice of
> representation of programs have to do with how the macro system works.
You must be a Schemer. ;-)
If programs are required to be represented as lists in a standardized way
then the user can construct and analyze programs by constructing and
analyzing lists in a standardized way. If they aren't then s/he can't.
E.
In article <····················@k-137-79-50-101.jpl.nasa.gov>,
···@jpl.nasa.gov (Erann Gat) wrote:
> In article <·························@dread12.news.tele.dk>,
> =?ISO-8859-1?Q?Jens_Axel_S=F8gaard?= <······@jasoegaard.dk> wrote:
>
> > Erann Gat wrote:
> >
> > > But there is a much deeper issue here. Just as Lispers shudder at
> > > Python's string-based EVAL because strings provide too little structure,
> > > Schemers (and Dylaners and MLers and Haskellers, with whom Schemers have
> > > much mindset in common) shudder at Lisp's list-based eval (there was no
> > > EVAL in Scheme before R5RS) because they think that lists provide too
> > > little structure for representing programs.
> >
> > > Representing programs as
> > > lists admits all sorts of horrible (in their minds) things like
> > > unintentional symbol capture and whatnot.
> >
> > Hey, remember the truce?
>
> Sorry, did you see what I wrote as critical? It wasn't intended to be.
> (Or did you just forget to put in a smiley?)
>
> > I am sorry, but I simply can't understand what the choice of
> > representation of programs have to do with how the macro system works.
>
> You must be a Schemer. ;-)
>
> If programs are required to be represented as lists in a standardized way
> then the user can construct and analyze programs by constructing and
> analyzing lists in a standardized way. If they aren't then s/he can't.
>
> E.
Yes, we want InterLisp back.
Read Erik Sandewall, The Lisp Experience, 1978
It gives valuable insight in the discussion of "structure vs. text"
with respect to user interfaces (editors, histories, ...)
in the InterLisp vs. MacLisp communities. The Appendix has
a letter by Stallman and an answer by Sandewall regarding these
issues. Common Lisp and Emacs are the wrong step in the wrong
direction, if the direction would be more pure Lisp.
Rainer Joswig wrote:
> Yes, we want InterLisp back.
>
> Read Erik Sandewall, The Lisp Experience, 1978
>
> It gives valuable insight in the discussion of "structure vs. text"
> with respect to user interfaces (editors, histories, ...)
> in the InterLisp vs. MacLisp communities. The Appendix has
> a letter by Stallman and an answer by Sandewall regarding these
> issues. Common Lisp and Emacs are the wrong step in the wrong
> direction, if the direction would be more pure Lisp.
I have looked at all the Amazons I know (.com, .co.uk, .de, .fr) and I
haven't found this book.
Could you give some more background information for this statement?
Thanks,
Pascal
> > Read Erik Sandewall, The Lisp Experience, 1978
This article appeared in ACM Computing Surveys, Volume 10, Issue 1, March
1978:
http://portal.acm.org/citation.cfm?id=356719
The text is available but requires purchase or the appropriate ACM
membership.
Pascal Costanza <········@web.de> writes:
> Rainer Joswig wrote:
>
>> Yes, we want InterLisp back.
>> Read Erik Sandewall, The Lisp Experience, 1978
>> It gives valuable insight in the discussion of "structure vs. text"
>> with respect to user interfaces (editors, histories, ...)
>> in the InterLisp vs. MacLisp communities. The Appendix has
>> a letter by Stallman and an answer by Sandewall regarding these
>> issues. Common Lisp and Emacs are the wrong step in the wrong
>> direction, if the direction would be more pure Lisp.
>
> I have looked at all the Amazons I know (.com, .co.uk, .de, .fr) and I
> haven't found this book.
A discussion similar to that mentioned by Rainer, including Stallman's
letter, was also published in:
"Interactive Programming Environments"
D.R. Barstow, H.E. Shrobe, E. Sandewall
McGraw-Hill, 1984
ISBN 0-07-003885-6
Not that this book is any easier to find, mind you. I got my used copy
from Abebooks.com. See this paper, included in the book (page 31):
"Programming in an Interactive Environment: The LISP Experience"
E. Sandewall
ACM Computing Surveys, 10:1 (March 1978), pp. 35-71
Stallman's letter, which is on page 75 in the book and appears as
Appendix A to Sandewall's paper, was originally published in:
ACM Computing Surveys, 10:4 (December 1978), pp. 505-508
Finally, the book has a reply by Sandewall on page 76.
> Could you give some more background information for this statement?
I am currently busy-ish, but if you are unable to locate the book or
the papers, just let me know.
Paolo
--
Paolo Amoroso <·······@mclink.it>
Paolo Amoroso wrote:
> Pascal Costanza <········@web.de> writes:
>
>
>>Rainer Joswig wrote:
>>
>>
>>>Yes, we want InterLisp back.
>>>Read Erik Sandewall, The Lisp Experience, 1978
>>>It gives valuable insight in the discussion of "structure vs. text"
>>>with respect to user interfaces (editors, histories, ...)
>>>in the InterLisp vs. MacLisp communities. The Appendix has
>>>a letter by Stallman and an answer by Sandewall regarding these
>>>issues. Common Lisp and Emacs are the wrong step in the wrong
>>>direction, if the direction would be more pure Lisp.
>>
>>I have looked at all the Amazons I know (.com, .co.uk, .de, .fr) and I
>>haven't found this book.
[...]
> See this paper, included in the book (page 31):
>
> "Programming in an Interactive Environment: The LISP Experience"
> E. Sandewall
> ACM Computing Surveys, 10:1 (March 1978), pp. 35-71
>
> Stallman's letter, which is on page 75 in the book and appears as
> Appendix A to Sandewall's paper, was originally published in:
>
> ACM Computing Surveys, 10:4 (December 1978), pp. 505-508
>
> Finally, the book has a reply by Sandewall on page 76.
Thanks a lot. I have found all these papers at http://www.acm.org/dl -
ACM Computing Surveys, 10:4 also includes a reply by Sandemann, so I
guess it's the same as the reprinted in the book.
Pascal
Pascal Costanza <········@web.de> writes:
> Rainer Joswig wrote:
>
> > Yes, we want InterLisp back.
> > Read Erik Sandewall, The Lisp Experience, 1978
> > It gives valuable insight in the discussion of "structure vs. text"
> > with respect to user interfaces (editors, histories, ...)
> > in the InterLisp vs. MacLisp communities. The Appendix has
> > a letter by Stallman and an answer by Sandewall regarding these
> > issues. Common Lisp and Emacs are the wrong step in the wrong
> > direction, if the direction would be more pure Lisp.
>
> I have looked at all the Amazons I know (.com, .co.uk, .de, .fr) and I
> haven't found this book.
>
> Could you give some more background information for this statement?
It's probably doable contacting Erik Sandewall directly and ask if you
can have a copy of the text. Last I heard, he was at Linkoping
University, probably at IDA (the CS department).
//Ingvar (lack of title due to lack of knowing)
--
My posts are fair game for anybody who wants to distribute the countless
pearls of wisdom sprinkled in them, as long as I'm attributed.
-- Martin Wisse, in a.f.p
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <7k4vzg78.fsf@comcast.net>
···@jpl.nasa.gov (Erann Gat) writes:
> I've decided to go ahead and reply to this at length and start a new
> thread because there seems to be a great deal of confusion on these
> points.
I agree. The Scheme standard goes to great lengths to discriminate
between objects and their printed representation. For some reason,
people seem to think that this means Scheme is defined only for the
printed representation.
> The semantics of Common Lisp, unlike every other programming
> langauge, are defined on Lisp objects. The semantcs of Scheme, like
> every other programming language except Common Lisp, are defined on
> strings.
To be pedantic, the semantics of Scheme are defined (in Section 7.2)
as set of domain equations. It is the formal syntax I want to focus
on.
>> 3. The Scheme function EVAL takes a piece of list structure as
>> an argument
> That is not necessarily true. Scheme's EVAL is defined to take "a Scheme
> program represented as data." The standard does not require that those
> data be lists, and furthermore it does not require that even if they are
> lists that they be the particular lists you would get by using the READ
> function to parse a Scheme program. Granted, the examples shown in the
> standard do it this way, but those are just that: examples. The standard
> does not require this behavior. A Scheme EVAL that took Scheme programs
> represented as strings would be compliant with the standard, and arguably
> more in keeping with the evolving spirit of Scheme.
The `Scheme program represented as data' is clearly meant to be list
structure. This is stated repeatedly in other parts of the standard.
The examples show list structure, the examples do not show strings.
That definition of EVAL does not explicitly *rule out* strings, that
hardly means that it is *intended* to mean them!
> The syntax of those strings happens to be the same as the syntax for
> lists, but this in and of itself does not require there to be any
> particular relationship between the two.
This is incorrect, and the Scheme standard *emphasizes* that there is
a deep relationship between lists and programs.
Section 1.2:
`The grammar of Scheme generates a sublanguage of the language used
for data. An important consequence of this simple, uniform
representation is the susceptibility of Scheme programs and data to
uniform treatment by other Scheme programs.'
Section 3.3:
`Scheme's syntax has the property that any sequence of characters
that is an expression is also the external representation of some
object. This can lead to confusion, since it may not be obvious out
of context whether a given sequence of characters is intended to
denote data or program, but it is also a source of power, since it
facilitates writing programs such as interpreters and compilers that
treat programs as data (or vice versa).'
Section 6.3.2:
`Within literal expressions and representations of objects read by
the read procedure, the forms '<datum>, `<datum>, ,<datum>, and
,@<datum> denote two-element lists whose first elements are the
symbols quote, quasiquote, unquote, and unquote-splicing,
respectively. The second element in each case is <datum>. This
convention is supported so that arbitrary Scheme programs may be
represented as lists. That is, according to Scheme's grammar, every
<expression> is also a <datum> (see section 7.1.2). Among other
things, this permits the use of the read procedure to parse Scheme
programs. See section 3.3.'
Section 7.1.2:
`Any string that parses as an <expression> will also parse as a
<datum>.'
> (NOTE: You may find yourself tempted to cite section 1.2 of R5RS in
> rebuttal to my position. My claim is that section 1.2 is an
> artifact of Scheme's history, not an accurate reflection of the
> current Scheme mindset. I predict that if there is ever an R6RS
> that this passage will disappear.)
I don't claim to know the `Scheme mindset', or to be able predict the
contents of a future report. I will note, however, that simple
excision of section 1.2 will not suffice.
> Of course, one obvious way to implement Scheme is to use the same parser
> for both programs and lists (since they have the same syntax), and at a
> casual glance it would seem to be crazy to do anything else. And yet
> there are Scheme implementations that really do have two separate parsers,
> one for programs, and a different one for lists.
This is true, but since the grammar that generates programs is a
subset of that which generates data, the two parsers must act the same
on lists that could be programs. You could have as many parsers as
you like, but they have to act the same vis-a-vis programs and lists.
> Schemers have what they consider to be perfectly sound reasons for
> doing it this way.
PLT Scheme keeps track of the line and character offset when lists
from a file. It uses these to help find missing open or close
parens. It's quite handy in this regard. This has little to do with
whether Scheme programs are `strings'.
> This is one indication of the truly deep gulf that separates the two
> languages. The Lisp-1 vs Lisp-2 issue is a red herring; Scheme and Lisp
> really represent two completely different mindsets about how programming
> languages ought to work, indeed about what programs *are*. That CL uses
> list syntax for programs is a reflection of its actual semantics. That
> Scheme uses list syntax for programs is mostly a historical accident. In
> fact, there are people in the Scheme community who think that using list
> syntax for programs is unnecessarily confusing and ought to be changed.
I cannot claim to know the mindset of either the Common Lisp or Scheme
communities. Each community attracts its share of crackpots, so I can
certainly believe that there are those that think that character
strings are superior to list syntax. There are those that believe
that a *richer* structure than lists ought to be used, but you can
find them in the Common Lisp community as well.
>> So a Scheme program may have several different representations over
>> its lifetime. At certain points in its lifetime (macroexpansion time)
>> it is required to have a list representation. (And by this I mean
>> that the representation is indistinguishable from a list using the
>> standard Scheme predicates.)
>
> No, this is not true. (Well, the first sentence is true, but the rest
> isn't.) It may be that Scheme programs are required at some point in
> their lives to have a representation that is isomorphic to lists (and even
> that is questionable) but it is not required to be represented as a list.
> And, more to the point, it is not required to be represented as any
> particular kind of list, and (most important) that representation is not
> required to be accessible to the user in any way.
It is accessible to the user via macros and macros are defined on lists.
> In Common Lisp the program represented by the string "(defun foo () t)" is
> required to be represented by a list with four elements. In Scheme, the
> program represented by the string "(define foo (lambda () #T))" could be
> represented as a list of three elements, or it could be represented as a
> structure, or a vector, or even a list that looks like: (program :type
> :definition :name "foo" :value (lambda-expression :arglist () :body #T)))
Again, programs have several different representations. In common
lisp, a string "(defun foo () t)" may be read yielding the 4 element
list you describe. That 4 element list is processed by the compiler
into some intermediate form, and that intermediate form is processed
into machine code. The intermediate forms may be CLOS structures
created with (make-instance 'program :type :definition :name "foo"
:value (lambda-expression :arglist () :body #t)). The system is
*allowed* to do whatever it likes so long as it *observably* follows
the definition.
>> The *only* difference between the two is this:
>>
>> 1. Common Lisp programs are read by the Common Lisp READ function.
>>
>> 2. Scheme programs need not be read by the Scheme READ function.
>>
>> This is `a difference that makes no difference' because the macro
>> system in Scheme requires exactly the same sort of lists that the READ
>> function would have produced.
>
> I disagree. This is a difference that makes an enormous difference. It
> can actually change the semantics of programs. In particular, it changes
> the semantics of QUOTE.
Could you give an example that either clearly demonstrates that
different semantics follow from using a function similar to READ (but
not actually named READ)? Can you give an example where QUOTE can
tell?
>> The macro system of Scheme is a mapping from lists->lists, so the
>> macro system simply would not work if programs behaved differently
>> from lists.
> No, that is not true. Scheme's macro system is more or less the same as
> Dylan's. Dylan programs may be represented as lists under the hood, but
> that representation is not available to the user. The situation is the
> same in both langauges. Dylan's syntax makes this clear; Scheme's syntax
> makes it confusing (which is one of the arguments for abandoning the
> syntax).
I'm not an expert in Dylan, but it is easy to see that Scheme macros
are defined as list->list to transformations:
Section 7.1.3 of the standard enumerates the various forms that Scheme
expression may take. One of these forms is as follows:
<macro use> -> (<keyword> <datum>*)
<keyword> -> <identifier>
That is to say, a form that starts with a identifier and is followed
by any number of *data* (i.e., arbitrary list structure) may be a
macro use. Note that in Scheme, there are no reserved words, so an
expression such as (define (22 "foo") #(3 '8)) may in fact be
a legitimate program fragment if the user has replaced DEFINE with a
macro of his own choosing. So the Scheme reader *must* be
conservative and read the program as <data> because to do otherwise
may reject a legitimate program. Parenthesised forms read as data
create lists.
We can go further. Section 4.3.2 describes the macro transformation
language. It states ``The <pattern> in a <syntax rule> is a *list*
<pattern> that begins with the keyword for the macro.'' (emphasis
mine) Further down, the formal rules for matching a pattern state:
``An input form F matches a pattern P if and only if:
<clause 1 & 2 omitted here>
- P is a *list* (P1 ... Pn) and F is a *list* of n forms that match
P1 through Pn, respectively; or
- P is an improper *list* (P1 P2 ... Pn . Pn+1) and F is a *list* or
improper *list* of n or more forms that match P1 through Pn
respectively and whose nth `cdr' matches Pn+1; or
- P is of the form (P1 ... Pn Pn+1 <ellipsis>) where <ellipsis>
is the identifier ... and F is a proper *list* of at least n
forms, the first n of which match P1 through Pn, respectively,
and each remaining element of F matches Pn+1; or
<vector forms omitted>
- P is a datum and F is equal to P in the sense of the EQUAL?
procedure. '' (emphasis mine)
This is clearly described as operations on lists. And the final
clause covers the list case as well.
Because macros are defined as transformations on lists, Scheme *must*
represent programs internally as something isomorphic to lists.
There's no way to avoid that. This can be exposed through the
high-level macro system Scheme provides (although it is an
extraordinary pain in the ass to do so). Oleg Kiselyov and Al
Petrovsky have developed macros versions of CAR, CDR, CONS and NULL
that reflect the implicit list operations that high-level macros
provide. List structure is defined by induction over those
primitives.
In article <············@comcast.net>, ·············@comcast.net wrote:
> > I disagree. This is a difference that makes an enormous difference. It
> > can actually change the semantics of programs. In particular, it changes
> > the semantics of QUOTE.
>
> Could you give an example that either clearly demonstrates that
> different semantics follow from using a function similar to READ (but
> not actually named READ)? Can you give an example where QUOTE can
> tell?
Yes. The canonical example is:
(defun foo () '(1 2 3))
(eq (foo) (foo))
Common Lisp requires this to return T, but the Scheme equivalent is not
required to return #T (and indeed there are Scheme implementations that do
not return #T).
This was discussed at length in comp.lang.scheme recently in the thread
entitled "Store and retrieve function".
> Because macros are defined as transformations on lists, Scheme *must*
> represent programs internally as something isomorphic to lists.
> There's no way to avoid that.
OK, but I'd say this doesn't contradict my overall point, which is that
there is a much larger difference in mindset between CL and Scheme than
most people casually assume. To wit:
> This can be exposed through the
> high-level macro system Scheme provides (although it is an
> extraordinary pain in the ass to do so). Oleg Kiselyov and Al
> Petrovsky have developed macros versions of CAR, CDR, CONS and NULL
> that reflect the implicit list operations that high-level macros
> provide. List structure is defined by induction over those
> primitives.
Scheme has gone to extraordinary lengths to define a structure that is
isomorphic to lists, and yet for which further extraordinary effort is
needed to define CAR, CDR, CONS and NULL (so much so that the people who
figured out how to do it actually get credited by name for doing so!)
instead of just saying, as Common Lisp does, programs are lists, and so
because they are lists you can just call CAR, CDR, CONS and NULL on them.
Please note I am not making any value judgements about whether or not the
Scheme way is a good idea. I prefer CL, but I understand the arguments on
both sides. My main point here is just to point out that the differences
in mindset are huge, and go way beyond the trivial matter of Lisp-1 vs
Lisp-2. People are talking about unifying CL and Scheme. I am not taking
a position on the merits of such an endeavor. I only want people who are
comtemplating undertaking this unification to understand the magnitude of
the problem that they face.
E.
Erann Gat wrote:
> People are talking about unifying CL and Scheme.
I don't think anyone in this thread has actually suggested anything that
goes as far as what "unifying CL and Scheme" seems to imply. Rather, that
there might be benefits to greater cooperation, but that this would require
some concessions on both sides.
> I only want people who are comtemplating undertaking this
> unification to understand the magnitude of the problem that they face.
If such a unification were being undertaken, the technical problems you've
pointed out might still pale in comparison to the social ones! ;)
Anton
In article <···················@newsread2.news.atl.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
> Erann Gat wrote:
> > People are talking about unifying CL and Scheme.
>
> I don't think anyone in this thread has actually suggested anything that
> goes as far as what "unifying CL and Scheme" seems to imply. Rather, that
> there might be benefits to greater cooperation, but that this would require
> some concessions on both sides.
>
> > I only want people who are comtemplating undertaking this
> > unification to understand the magnitude of the problem that they face.
>
> If such a unification were being undertaken, the technical problems you've
> pointed out might still pale in comparison to the social ones! ;)
Yes, thanks for clarifying that. I probably should have said, "People are
talking about unifying the CL and Scheme communities." (Actually, people
talk about unifying the two languages as well, but I don't think anyone is
really taking that seriously.)
In any case, the main point is that everything I've written in this thread
needs to be read in the context of the thread's title.
E.
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <wucvc920.fsf@comcast.net>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <············@comcast.net>, ·············@comcast.net wrote:
>
>> > I disagree. This is a difference that makes an enormous difference. It
>> > can actually change the semantics of programs. In particular, it changes
>> > the semantics of QUOTE.
>>
>> Could you give an example that either clearly demonstrates that
>> different semantics follow from using a function similar to READ (but
>> not actually named READ)? Can you give an example where QUOTE can
>> tell?
>
> Yes. The canonical example is:
>
> (defun foo () '(1 2 3))
> (eq (foo) (foo))
>
> Common Lisp requires this to return T, but the Scheme equivalent is not
> required to return #T (and indeed there are Scheme implementations that do
> not return #T).
I don't see how this example demonstrates anything about READ.
The scheme implementation that returns #F does so because it
aggresively inlines nearly everything. As a result, the procedure FOO
gets `split' into two different procedures. For some implementation
dependent reason the quoted structure is split as well.
> People are talking about unifying CL and Scheme. I am not taking a
> position on the merits of such an endeavor. I only want people who
> are comtemplating undertaking this unification to understand the
> magnitude of the problem that they face.
I think `unifying' CL and Scheme would be a bad idea for both sides.
In article <············@comcast.net>, ·············@comcast.net wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <············@comcast.net>, ·············@comcast.net wrote:
> >
> >> > I disagree. This is a difference that makes an enormous difference. It
> >> > can actually change the semantics of programs. In particular, it changes
> >> > the semantics of QUOTE.
> >>
> >> Could you give an example that either clearly demonstrates that
> >> different semantics follow from using a function similar to READ (but
> >> not actually named READ)? Can you give an example where QUOTE can
> >> tell?
> >
> > Yes. The canonical example is:
> >
> > (defun foo () '(1 2 3))
> > (eq (foo) (foo))
> >
> > Common Lisp requires this to return T, but the Scheme equivalent is not
> > required to return #T (and indeed there are Scheme implementations that do
> > not return #T).
>
> I don't see how this example demonstrates anything about READ.
It doesn't. It demonstrates that in Scheme one cannot reliably apply the
model that a Scheme program is a list.
> The scheme implementation that returns #F does so because it
> aggresively inlines nearly everything. As a result, the procedure FOO
> gets `split' into two different procedures. For some implementation
> dependent reason the quoted structure is split as well.
That is not relevant to the point I am trying to make, which is that there
is a huge difference in mental models between Scheme and CL. (Read the
title of this thread again.) That there are defensible arguments for
doing things the Scheme way doesn't change the fact that it's very
different from the CL way, so different that many things that are
perfectly natural for Schemers come as great shocks to CLers, and vice
versa.
> > People are talking about unifying CL and Scheme. I am not taking a
> > position on the merits of such an endeavor. I only want people who
> > are comtemplating undertaking this unification to understand the
> > magnitude of the problem that they face.
>
> I think `unifying' CL and Scheme would be a bad idea for both sides.
The mertis of any idea can only be measured with respect to a goal. I
think that a lot of friction between the two sides is due to people
applying the false assumption that everyone shares the same goals. I
respectfully submit that refraining from judging things as "bad ideas"
independent of any context would go a long way towards reducing the amount
of thrashing that goes on when people talk about these kinds of issues.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <············@comcast.net>, ·············@comcast.net wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > Yes. The canonical example is:
> > >
> > > (defun foo () '(1 2 3))
> > > (eq (foo) (foo))
> > >
> > > Common Lisp requires this to return T, but the Scheme equivalent
> > > is not required to return #T (and indeed there are Scheme
> > > implementations that do not return #T).
> >
> > I don't see how this example demonstrates anything about READ.
>
> It doesn't. It demonstrates that in Scheme one cannot reliably
> apply the model that a Scheme program is a list.
How is this demonstrated?
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
<···@barzilay.org> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <············@comcast.net>, ·············@comcast.net wrote:
> >
> > > ···@jpl.nasa.gov (Erann Gat) writes:
> > >
> > > > Yes. The canonical example is:
> > > >
> > > > (defun foo () '(1 2 3))
> > > > (eq (foo) (foo))
> > > >
> > > > Common Lisp requires this to return T, but the Scheme equivalent
> > > > is not required to return #T (and indeed there are Scheme
> > > > implementations that do not return #T).
> > >
> > > I don't see how this example demonstrates anything about READ.
> >
> > It doesn't. It demonstrates that in Scheme one cannot reliably
> > apply the model that a Scheme program is a list.
>
> How is this demonstrated?
To be more precise, it demonstrates that one cannot reliably apply the
model that a Scheme program is the list produced by running the text of
the program through the READ function once. A Scheme program may be such
a list, but you can't count on it. If you could you could count on (eq
(foo) (foo)) returning #T, but you can't, so you can't. In Common Lisp
you can.
Put this another way: Common Lisp semantics are defined in terms of the
concept of a *form*, which is a first-class data object. Scheme semantics
are not; they are instead defined directly on the text of the program.
The only thing that you can count on is that you can run the text of a
Scheme program through READ and get a list. But that doesn't necessarily
reflect anything that happens when you send the same text to the Scheme
interpreter. Many Scheme interpreters will parse the code using READ, but
you can't count on it.
This has other important consequences besides the different semantics of
QUOTE. For example, Scheme has no reader macros, and no easy way to add
them because you'd have to described separately how they worked when
parsing programs and when parsing data. Scheme has macros, but no
portable way to access macro expansions.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> <···@barzilay.org> wrote:
>
> > How is this demonstrated?
>
> To be more precise, it demonstrates that one cannot reliably apply
> the model that a Scheme program is the list produced by running the
> text of the program through the READ function once.
> [...]
Look, I know what your *opinion* is. This goes back to that other
thread where you said:
| I'd argue for (eqv? (foo) (foo)) --> #T on the grounds of how READ
| is defined: [...]
But what you didn't provide then, and AFAICT, you still don't, is some
proof that this is example somehow shows that Scheme does not use
`read' to parse input. IIRC, the two implementations that had the
"misbehaved quote" were using read. To me it looked like your
argument was supposed to be
r5rs-read-definition => example-is-always-true
and when the RHS of this was shown as false you concluded that it
makes something different on the LHS.
So my question still stands, and I'll repeat it for clarity. Assuming
that I work with a Scheme implementation, or even some Lisp
implementation where your "canonical example":
(defun foo () '(1 2 3))
(eq (foo) (foo))
returns `nil'. How does this show that the implementation does not
represent code list data?
To make this even clearer -- when you continue saying:
> A Scheme program may be such a list, but you can't count on it. If
> you could you could count on (eq (foo) (foo)) returning #T, but you
> can't, so you can't. In Common Lisp you can.
then I assume that the fact that "a Scheme program may be such a list"
should manifest itself in the guarantee that if this is so then
`(eq (foo) (foo))' is true. How are these two things related?
> Put this another way: Common Lisp semantics are defined in terms of
> the concept of a *form*, which is a first-class data object. Scheme
> semantics are not; they are instead defined directly on the text of
> the program. The only thing that you can count on is that you can
> run the text of a Scheme program through READ and get a list.
So you say that Scheme's semantics are such that they assign some
value to evaluating the string "(foo bar)", and you also say that
passing that string to the reader will produce the expected list, and
that CL's semantics would assign the semantic information to the list
rather than to the input string. How does this affects my decision on
what language to use? -- what possible code would be different or
impossible on one side?
> For example, Scheme has no reader macros, and no easy way to add
> them because you'd have to described separately how they worked when
> parsing programs and when parsing data. Scheme has macros, but no
> portable way to access macro expansions.
There are enough Schemes that have reader macros, how is their
implementation more difficult than in a Lisp implementation?
True, there is no portable way to access macro expansion, which is
obvious given that there is no portable low-level macro facility --
but how is that related to a "Scheme is defined on strings" issue?
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
<···@barzilay.org> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> > <···@barzilay.org> wrote:
> >
> > > How is this demonstrated?
> >
> > To be more precise, it demonstrates that one cannot reliably apply
> > the model that a Scheme program is the list produced by running the
> > text of the program through the READ function once.
> > [...]
>
> Look, I know what your *opinion* is.
No, I don't think you do.
> This goes back to that other thread where you said:
>
> | I'd argue for (eqv? (foo) (foo)) --> #T on the grounds of how READ
> | is defined: [...]
That's right.
> But what you didn't provide then, and AFAICT, you still don't, is some
> proof that this is example somehow shows that Scheme does not use
> `read' to parse input.
That's wrong. I have not said that Scheme does not use READ to parse
input. All I have said is that it is not required to, and that not all
Scheme implementations do. This is not my opinion, this is a fact pounded
into my head by Schemers, and it came as a great shock to me.
> So my question still stands, and I'll repeat it for clarity. Assuming
> that I work with a Scheme implementation, or even some Lisp
> implementation where your "canonical example":
>
> (defun foo () '(1 2 3))
> (eq (foo) (foo))
>
> returns `nil'. How does this show that the implementation does not
> represent code list data?
It doesn't, and that is not my claim. Re-read my clarification above carefully.
Since you are attacking a straw man, I will not respond to the rest of
your post, except to observe that you consistently confuse what some
Scheme implementations actually do with what they are required to do.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> <···@barzilay.org> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> > > <···@barzilay.org> wrote:
> > >
> > > > How is this demonstrated?
> > >
> > > To be more precise, it demonstrates that one cannot reliably apply
> > > the model that a Scheme program is the list produced by running the
> > > text of the program through the READ function once.
> > > [...]
> >
> > Look, I know what your *opinion* is.
>
> No, I don't think you do.
To the extent of your posts, I do know it.
> > This goes back to that other thread where you said:
> >
> > | I'd argue for (eqv? (foo) (foo)) --> #T on the grounds of how READ
> > | is defined: [...]
>
> That's right.
>
> > But what you didn't provide then, and AFAICT, you still don't, is some
> > proof that this is example somehow shows that Scheme does not use
> > `read' to parse input.
>
> That's wrong. I have not said that Scheme does not use READ to
> parse input. All I have said is that it is not required to, and
> that not all Scheme implementations do. This is not my opinion,
> this is a fact pounded into my head by Schemers, and it came as a
> great shock to me.
OK, let me try yet another paraphrase then, as direct as I can produce
now:
Scheme implementations are not required to use `read' to parse
input. Does this fact have any effect on me as a programmer that
switches to/from such an implementation? (Effect is defined as
different code.)
* If the answer is "yes", then I would very much like to see such an
effect.
* If the answer is "no", then whatever effect there is, it must be
some issue of terminology.
> > So my question still stands, and I'll repeat it for clarity.
> > Assuming that I work with a Scheme implementation, or even some
> > Lisp implementation where your "canonical example":
> >
> > (defun foo () '(1 2 3))
> > (eq (foo) (foo))
> >
> > returns `nil'. How does this show that the implementation does not
> > represent code list data?
>
> It doesn't, and that is not my claim. Re-read my clarification
> above carefully.
OK, so what *does* this example demonstrate?
> Since you are attacking a straw man, I will not respond to the rest
> of your post, except to observe that you consistently confuse what
> some Scheme implementations actually do with what they are required
> to do.
Please feel free to enlighten me.
[BTW, this or any other parts of my posts are *not* sarcasm, this
issue is very related to my current work, and if there *any* code that
should be different in the two worlds, I would very much like to see
it.]
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
<···@barzilay.org> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> > <···@barzilay.org> wrote:
> >
> > > ···@jpl.nasa.gov (Erann Gat) writes:
> > >
> > > > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> > > > <···@barzilay.org> wrote:
> > > >
> > > > > How is this demonstrated?
> > > >
> > > > To be more precise, it demonstrates that one cannot reliably apply
> > > > the model that a Scheme program is the list produced by running the
> > > > text of the program through the READ function once.
> > > > [...]
> > >
> > > Look, I know what your *opinion* is.
> >
> > No, I don't think you do.
>
> To the extent of your posts, I do know it.
No. You only know my opinion to the extent that I have revealed it
through my posts, and I have been making an effort not to inject my
opinions into this thread.
> OK, let me try yet another paraphrase then, as direct as I can produce
> now:
>
> Scheme implementations are not required to use `read' to parse
> input. Does this fact have any effect on me as a programmer that
> switches to/from such an implementation? (Effect is defined as
> different code.)
>
> * If the answer is "yes", then I would very much like to see such an
> effect.
>
> * If the answer is "no", then whatever effect there is, it must be
> some issue of terminology.
I would define "effect" differently: it has an "effect" if it can cause
the same code to produce two different results on two different yet
standards-compliant Scheme implementations. On this definition the answer
is "yes", and I have given an example, and reiterated several times now,
so I don't see much point in repeating it yet again.
E.
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@192.168.1.52>...
> That's wrong. I have not said that Scheme does not use READ to parse
> input. All I have said is that it is not required to, and that not all
> Scheme implementations do.
Which implementations do you mean exactly? Any references, perhaps?
cheers,
felix
Eli Barzilay <···@barzilay.org> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> > <···@barzilay.org> wrote:
> >
> > > How is this demonstrated?
> >
> > To be more precise, it demonstrates that one cannot reliably apply
> > the model that a Scheme program is the list produced by running the
> > text of the program through the READ function once.
> > [...]
>
> Look, I know what your *opinion* is. This goes back to that other
> thread where you said:
>
> | I'd argue for (eqv? (foo) (foo)) --> #T on the grounds of how READ
> | is defined: [...]
>
> But what you didn't provide then, and AFAICT, you still don't, is some
> proof that this is example somehow shows that Scheme does not use
> `read' to parse input. IIRC, the two implementations that had the
> "misbehaved quote" were using read. To me it looked like your
> argument was supposed to be
>
> r5rs-read-definition => example-is-always-true
>
> and when the RHS of this was shown as false you concluded that it
> makes something different on the LHS.
>
> So my question still stands, and I'll repeat it for clarity. Assuming
> that I work with a Scheme implementation, or even some Lisp
> implementation where your "canonical example":
>
> (defun foo () '(1 2 3))
> (eq (foo) (foo))
>
> returns `nil'. How does this show that the implementation does not
> represent code list data?
>
> To make this even clearer -- when you continue saying:
>
> > A Scheme program may be such a list, but you can't count on it. If
> > you could you could count on (eq (foo) (foo)) returning #T, but you
> > can't, so you can't. In Common Lisp you can.
>
> then I assume that the fact that "a Scheme program may be such a list"
> should manifest itself in the guarantee that if this is so then
> `(eq (foo) (foo))' is true. How are these two things related?
Because READ turns the input into a structure, the list:
[.|.]->[.|.]->[.|.]->[.|.]->NIL
| | | |
DEFUN FOO NIL [.|.]->[.|.]->NIL
| |
QUOTE [.|.]->[.|.]->[.|.]->NIL
| | |
1 2 3
This is turned into a function definition and on calling the function,
QUOTE returns *exactly* its argument. Since list (and indeed all sorts
of object) identity is important in lisp, it thus returns THE SAME
list every time (well, the return value is EQ). So, barring function
re-definitions, (eq (foo) (foo)) should always be true.
Contrast this with a function BAR, such that:
(defun bar () (list 1 2 3))
With this definition it is "obvious" that (eq (bar) (bar)) cannot ever
be true (barring function redefinitions).
//Ingvar
--
My posts are fair game for anybody who wants to distribute the countless
pearls of wisdom sprinkled in them, as long as I'm attributed.
-- Martin Wisse, in a.f.p
Ingvar Mattsson <······@cathouse.bofh.se> writes:
> Because READ turns the input into a structure, the list:
>
> [.|.]->[.|.]->[.|.]->[.|.]->NIL
> | | | |
> DEFUN FOO NIL [.|.]->[.|.]->NIL
> | |
> QUOTE [.|.]->[.|.]->[.|.]->NIL
> | | |
> 1 2 3
Thank you for the box/pointer ascii art. You could improve it by
adding little "v"s below "|"s, but it would still be redundant.
> This is turned into a function definition and on calling the function,
> QUOTE returns *exactly* its argument. Since list (and indeed all sorts
> of object) identity is important in lisp, it thus returns THE SAME
> list every time (well, the return value is EQ).
(So you say that quote works this way because list identity is
important?)
> So, barring function re-definitions, (eq (foo) (foo)) should always
> be true.
And again, my question is how is that related to that magical fact
that in Scheme the evaluator or the semantics use strings.
Please read my post again, and Erann's claim.
> Contrast this with a function BAR, such that:
> (defun bar () (list 1 2 3))
> With this definition it is "obvious" that (eq (bar) (bar)) cannot
> ever be true (barring function redefinitions).
This is supoprting my point. If you look closely, you'll find out
that the little ascii diagram for this function look the same. Then
you might ask yourself -- if one function is returning a different
object every time, and another function returns the same one, and both
pieces of code are represented in the same way, then how come the
original example returning `nil' is an indication of anything?
Or maybe you're trying to emphasize my point here?
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Eli Barzilay <···@barzilay.org> writes:
> Ingvar Mattsson <······@cathouse.bofh.se> writes:
>
> > Because READ turns the input into a structure, the list:
> >
> > [.|.]->[.|.]->[.|.]->[.|.]->NIL
> > | | | |
> > DEFUN FOO NIL [.|.]->[.|.]->NIL
> > | |
> > QUOTE [.|.]->[.|.]->[.|.]->NIL
> > | | |
> > 1 2 3
...
> > Contrast this with a function BAR, such that:
> > (defun bar () (list 1 2 3))
> > With this definition it is "obvious" that (eq (bar) (bar)) cannot
> > ever be true (barring function redefinitions).
>
> This is supoprting my point. If you look closely, you'll find out
> that the little ascii diagram for this function look the same. Then
> you might ask yourself -- if one function is returning a different
> object every time, and another function returns the same one, and both
> pieces of code are represented in the same way, then how come the
> original example returning `nil' is an indication of anything?
What are you talking about? The bar version clearly does not have the
same representation.
/Jon
·········@rcn.com (Jon S. Anthony) writes:
> Eli Barzilay <···@barzilay.org> writes:
>
> > Ingvar Mattsson <······@cathouse.bofh.se> writes:
> >
> > > Because READ turns the input into a structure, the list:
> > >
> > > [.|.]->[.|.]->[.|.]->[.|.]->NIL
> > > | | | |
> > > DEFUN FOO NIL [.|.]->[.|.]->NIL
> > > | |
> > > QUOTE [.|.]->[.|.]->[.|.]->NIL
> > > | | |
> > > 1 2 3
> ...
> > > Contrast this with a function BAR, such that:
> > > (defun bar () (list 1 2 3))
> > > With this definition it is "obvious" that (eq (bar) (bar)) cannot
> > > ever be true (barring function redefinitions).
> >
> > This is supoprting my point. If you look closely, you'll find out
> > that the little ascii diagram for this function look the same. Then
> > you might ask yourself -- if one function is returning a different
> > object every time, and another function returns the same one, and both
> > pieces of code are represented in the same way, then how come the
> > original example returning `nil' is an indication of anything?
>
> What are you talking about? The bar version clearly does not have the
> same representation.
Sure it isn't -- I should have said "similar" instead of "the same",
since my point is that it's the same *kind* of representation -- cons
cells, symbols, numbers etc. All you need to do is remove one link,
and change one symbol. Or if somehow the magic fact that the specific
structure of the `foo' definition is the one that matters, then just
use this:
(defmacro kuote (l) `(list ,@(mapcar #'(lambda (x) `',x) l)))
(defun baz () (kuote (1 2 3)))
And the change is in just one symbol, and even not much there. My
question is still open -- how is the different behavior of `baz' and
`foo' related to the semantics being defined on strings or lists?
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
<···@barzilay.org> wrote:
> ·········@rcn.com (Jon S. Anthony) writes:
>
> > Eli Barzilay <···@barzilay.org> writes:
> >
> > > Ingvar Mattsson <······@cathouse.bofh.se> writes:
> > >
> > > > Because READ turns the input into a structure, the list:
> > > >
> > > > [.|.]->[.|.]->[.|.]->[.|.]->NIL
> > > > | | | |
> > > > DEFUN FOO NIL [.|.]->[.|.]->NIL
> > > > | |
> > > > QUOTE [.|.]->[.|.]->[.|.]->NIL
> > > > | | |
> > > > 1 2 3
> > ...
> > > > Contrast this with a function BAR, such that:
> > > > (defun bar () (list 1 2 3))
> > > > With this definition it is "obvious" that (eq (bar) (bar)) cannot
> > > > ever be true (barring function redefinitions).
> > >
> > > This is supoprting my point. If you look closely, you'll find out
> > > that the little ascii diagram for this function look the same. Then
> > > you might ask yourself -- if one function is returning a different
> > > object every time, and another function returns the same one, and both
> > > pieces of code are represented in the same way, then how come the
> > > original example returning `nil' is an indication of anything?
> >
> > What are you talking about? The bar version clearly does not have the
> > same representation.
>
> Sure it isn't -- I should have said "similar" instead of "the same",
> since my point is that it's the same *kind* of representation -- cons
> cells, symbols, numbers etc. All you need to do is remove one link,
> and change one symbol. Or if somehow the magic fact that the specific
> structure of the `foo' definition is the one that matters, then just
> use this:
>
> (defmacro kuote (l) `(list ,@(mapcar #'(lambda (x) `',x) l)))
> (defun baz () (kuote (1 2 3)))
>
> And the change is in just one symbol, and even not much there. My
> question is still open -- how is the different behavior of `baz' and
> `foo' related to the semantics being defined on strings or lists?
So many red herrings, so little time.
Your question presumes that there is a difference between quote and
kuote. In Common Lisp there is, in Scheme there may or may not be. In
fact, if you translate kuote into Scheme's macro system, then your kuote
is a valid implementation of Scheme's quote (and indeed there is at least
one Scheme that actually implements quote in pretty much that way).
The reason kuote is a valid implementation of Scheme's quote is that the
semantics of (scheme-quote X) are that it returns X, but this is a
definition of the semantics of the string "(quote X)", not the semantics
of the list whose car is the symbol QUOTE. Because it is the definition
of the semantics of a string, what it means is that you get back not the
specific object X (because there is no specific object X), but an object
whose string representation is X. Two such objects may or may not be EQ.
In Common Lisp the definition of (quote X) is the same -- it returns X --
but the meaning of that definition is different because it is a definition
on a *form*, not a string, that is, it's a definition on a list of two
elements, the first of which is the symbol QUOTE and the second is any
Lisp object. X need not even have a printed representation. For example,
in Common Lisp you can do:
? (defmacro foo () (list (quote quote) (function car))) ; Note no backquote
FOO
? (macroexpand '(foo))
'#<Compiled-function CAR #xAC894E>
T
? (car (macroexpand '(foo)))
QUOTE
? (cadr (macroexpand '(foo)))
#<Compiled-function CAR #xAC894E>
? (foo)
#<Compiled-function CAR #xAC894E>
?
Doing that (i.e. writing a macro whose expansion is a quote form whose
argument is an object that has no readable represenation) is (as far as I
know) not possible in standard Scheme.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> <···@barzilay.org> wrote:
>
> > [...]
> > (defmacro kuote (l) `(list ,@(mapcar #'(lambda (x) `',x) l)))
> > (defun baz () (kuote (1 2 3)))
> > [...]
>
> Your question presumes that there is a difference between quote and
> kuote. In Common Lisp there is, in Scheme there may or may not be.
OK, OK, I got that part. My *question* is -- how does that show that
Scheme is defined on strings?
> In fact, if you translate kuote into Scheme's macro system, then
> your kuote is a valid implementation of Scheme's quote (and indeed
> there is at least one Scheme that actually implements quote in
> pretty much that way).
*rolls eyes*
I know (and I know). And the fact that you keep ignoring is that the
fact that there is an implementation that implements quote in this
way and uses `read' to parse input is a strong indication that the
result of `(eq (foo) (foo))' is unrelated to the language being
defined on strings or s-exps.
> The reason kuote is a valid implementation of Scheme's quote is that
> the semantics of (scheme-quote X) are that it returns X, but this is
> a definition of the semantics of the string "(quote X)", not the
> semantics of the list whose car is the symbol QUOTE.
And by the way this is defined, it is necessarily the semantics of
"( quote X )" etc -- of any string that when passed to `read' returns
that list. Does the fact that it is not directly defined on sexps has
any effect on my programs? It's a simple question -- all you need is
an example of a program that would break if its semantics is defined
on strings. Your example doesn't seem to do this.
> Because it is the definition of the semantics of a string, what it
> means is that you get back not the specific object X (because there
> is no specific object X), but an object whose string representation
> is X. Two such objects may or may not be EQ.
This is a result of how `quote' is implemented, not how semantics is
defined.
> [...] For example, in Common Lisp you can do:
>
> ? (defmacro foo () (list (quote quote) (function car))) ; Note no backquote
> FOO
> ? (macroexpand '(foo))
> '#<Compiled-function CAR #xAC894E>
> T
> ? (car (macroexpand '(foo)))
> QUOTE
> ? (cadr (macroexpand '(foo)))
> #<Compiled-function CAR #xAC894E>
> ? (foo)
> #<Compiled-function CAR #xAC894E>
> ?
>
> Doing that (i.e. writing a macro whose expansion is a quote form
> whose argument is an object that has no readable represenation) is
> (as far as I know) not possible in standard Scheme.
Yes, this is one thing which is defined in the CL spec and not in the
Scheme spec. Unfortunately this is still not an indicator of when
your implementation uses `read' to parse code.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> <···@barzilay.org> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> > > <···@barzilay.org> wrote:
> > >
> > > > ···@jpl.nasa.gov (Erann Gat) writes:
> > > >
> > > > > To be more precise, it demonstrates that one cannot reliably apply
> > > > > the model that a Scheme program is the list produced by running the
> > > > > text of the program through the READ function once.
> > > > > [...]
> > > >
> > > > Look, I know what your *opinion* is.
> > >
> > > No, I don't think you do.
> >
> > To the extent of your posts, I do know it.
>
> No. You only know my opinion to the extent that I have revealed it
> through my posts,
I think it is pretty clear what the definition of "know your opinion
is", in the same way that when we physically talk it is safe to assume
that we were not engaged in telepathic communication without knowing.
> and I have been making an effort not to inject my opinions into this
> thread.
Please see above -- you write:
> > > > > To be more precise, it demonstrates that one cannot reliably apply
> > > > > the model that a Scheme program is the list produced by running the
> > > > > text of the program through the READ function once.
And I did not see any factual support for this argument. Until I see
some concrete example, this claim is in opinion land, in this case,
your opinion.
> > OK, let me try yet another paraphrase then, as direct as I can produce
> > now:
> >
> > Scheme implementations are not required to use `read' to parse
> > input. Does this fact have any effect on me as a programmer that
> > switches to/from such an implementation? (Effect is defined as
> > different code.)
> >
> > * If the answer is "yes", then I would very much like to see such an
> > effect.
> >
> > * If the answer is "no", then whatever effect there is, it must be
> > some issue of terminology.
>
> I would define "effect" differently: it has an "effect" if it can
> cause the same code to produce two different results on two
> different yet standards-compliant Scheme implementations.
This was my definition -- if you get two different results, then
obviously code must be different in that world than code in a world
that has some guarantees. What's unclear here is the definition of
"it".
> On this definition the answer is "yes", and I have given an example,
> [...]
You have given an example that shows that `quote' can be implemented
in an unexpected way (or, *evaluating* `quote' can be done in an
unexpected way). You have not given an example where Scheme's
character-string world has an effect of code.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
<···@barzilay.org> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> > <···@barzilay.org> wrote:
> >
> > > [...]
> > > (defmacro kuote (l) `(list ,@(mapcar #'(lambda (x) `',x) l)))
> > > (defun baz () (kuote (1 2 3)))
> > > [...]
> >
> > Your question presumes that there is a difference between quote and
> > kuote. In Common Lisp there is, in Scheme there may or may not be.
>
> OK, OK, I got that part. My *question* is -- how does that show that
> Scheme is defined on strings?
It (in and of itself) doesn't, and I never said it did. You can keep
knocking down straw men if you like, but I will soon tire of this game and
stop responding. If you want to continue this conversation you need to
make a better-faith attempt to understand what it is that I am actually
trying to say rather than impose your own view of the world on my words.
> > In fact, if you translate kuote into Scheme's macro system, then
> > your kuote is a valid implementation of Scheme's quote (and indeed
> > there is at least one Scheme that actually implements quote in
> > pretty much that way).
>
> *rolls eyes*
>
> I know (and I know). And the fact that you keep ignoring is that the
> fact that there is an implementation that implements quote in this
> way and uses `read' to parse input is a strong indication that the
> result of `(eq (foo) (foo))' is unrelated to the language being
> defined on strings or s-exps.
No. The fact that the implementation in question actually uses READ to
parse input is entirely irrelevant to my argument, and if you don't see
that then you have not understood what I have been saying.
> > The reason kuote is a valid implementation of Scheme's quote is that
> > the semantics of (scheme-quote X) are that it returns X, but this is
> > a definition of the semantics of the string "(quote X)", not the
> > semantics of the list whose car is the symbol QUOTE.
>
> And by the way this is defined, it is necessarily the semantics of
> "( quote X )" etc -- of any string that when passed to `read' returns
> that list. Does the fact that it is not directly defined on sexps has
> any effect on my programs?
For the thousandth time, yes.
> It's a simple question
Yes indeed, and I have given a simple answer.
> -- all you need is
> an example of a program that would break if its semantics is defined
> on strings. Your example doesn't seem to do this.
No, that is faulty logic. What I need is an example of a program that
would break if Scheme's semantics were defined on lists. I have provided
such an example, and therefore proven that Scheme's semantics are not
defined on lists. Granted that does not prove that Scheme's semantics are
defined on strings, but it would seem to be the only remaining
possibility. Still, the door is open for you (or anyone else) to suggest
one.
> > Because it is the definition of the semantics of a string, what it
> > means is that you get back not the specific object X (because there
> > is no specific object X), but an object whose string representation
> > is X. Two such objects may or may not be EQ.
>
> This is a result of how `quote' is implemented, not how semantics is
> defined.
No. You are really missing something fundamental. What is at issue here
is not what any particular Scheme implementation actually does, but rather
what is considered correct behavior of a Scheme implementation that
purports to conform to the standard. The actual existence of the
implementation in question is not relevant. What is relevant is that the
consensus view of the Scheme community is that this implementation is a
correct implementation of Scheme. But this would be the case whether or
not this implementation actually existed. The fact that it exists merely
serves to take the discussion out of the abstract.
> Yes, this is one thing which is defined in the CL spec and not in the
> Scheme spec. Unfortunately this is still not an indicator of when
> your implementation uses `read' to parse code.
That is correct, but again irrelevant. You keep missing the point. What
matters is not that CL actually uses READ, but that one can reliably apply
the model that it does use READ whether or not it actually does. (In
fact, I believe that there are CL implementations that use a function
other than #'cl:read to read code at the top level. But this too is
irrelevant.)
> > > > > Look, I know what your *opinion* is.
> > > >
> > > > No, I don't think you do.
> > >
> > > To the extent of your posts, I do know it.
> >
> > No. You only know my opinion to the extent that I have revealed it
> > through my posts,
>
> I think it is pretty clear what the definition of "know your opinion
> is", in the same way that when we physically talk it is safe to assume
> that we were not engaged in telepathic communication without knowing.
You apparently don't know my opinion even in that restricted sense. The
passage in question:
> To be more precise, it demonstrates that one cannot reliably apply
> the model that a Scheme program is the list produced by running the
> text of the program through the READ function once.
is not "my" opinion in any sense of the word. It is what I was told by
members of the Scheme community. My opinion (as expressed with no
ambiguity at the start of the c.l.s. thread that started this whole mess)
was that Scheme programs ought to be considered lists. But the necessary
consequence of this is that (eq? (foo) (foo)) must return #T. And I was
subsequently informed in no uncertain terms that my opinion was considered
wrong by the Scheme community. So you see, the view you are taking issue
with is in fact precisely the opposite of my actual opinion.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> <···@barzilay.org> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> > > <···@barzilay.org> wrote:
> > >
> > > > [...]
> > > > (defmacro kuote (l) `(list ,@(mapcar #'(lambda (x) `',x) l)))
> > > > (defun baz () (kuote (1 2 3)))
> > > > [...]
> > >
> > > Your question presumes that there is a difference between quote and
> > > kuote. In Common Lisp there is, in Scheme there may or may not be.
> >
> > OK, OK, I got that part. My *question* is -- how does that show that
> > Scheme is defined on strings?
>
> It (in and of itself) doesn't, and I never said it did.
Huh??
At the beginning of the subthread with the current subject line you
said:
| The semantics of Common Lisp, unlike every other programming
| langauge, are defined on Lisp objects. The semantcs of Scheme, like
| every other programming language except Common Lisp, are defined on
| strings.
(And BTW, at that post you said:
| And yet there are Scheme implementations that really do have two
| separate parsers, one for programs, and a different one for lists.
and I don't know about such implementations, and you never came up
with references...)
Anyway, for Joe's claim that:
| The Scheme function EVAL takes a piece of list structure as an
| argument
you replied:
| That is not necessarily true. [...]
and:
| A Scheme EVAL that took Scheme programs represented as strings would
| be compliant with the standard, and arguably more in keeping with
| the evolving spirit of Scheme.
(BTW, how does this "keep with the evolving spirit of Scheme" when
there is no implementation that does this? Can you now tell how
Scheme evolves better than people who use Scheme?)
and eventually you said:
| This is a difference that makes an enormous difference. It can
| actually change the semantics of programs. In particular, it
| changes the semantics of QUOTE.
I have taken this to indicate that there must be some observable
effect of this, as other have -- for example, Jens replied:
| I am sorry, but I simply can't understand what the choice of
| representation of programs have to do with how the macro system
| works.
and "prunesquallor" replied:
| The `Scheme program represented as data' is clearly meant to be list
| structure. This is stated repeatedly in other parts of the
| standard.
So along with all that, I also understood that you think there is some
observable Scheme behavior that demonstrates the fact that it uses
strings and not lists. Now you say that there isn't any such
difference, so we're back at the beginning -- your claim is that there
is some difference, but that difference doesn't have any physical
consequences (in the form of code). From now on, when you say that
there is some great mindset difference between program representation
as lists (Lisp) or strings (Scheme), don't forget to add that this
does not have any programming consequences.
> You can keep knocking down straw men if you like, but I will soon
> tire of this game and stop responding.
I think that you can stop -- looks like you don't have a concrete
example of the difference.
> If you want to continue this conversation you need to make a
> better-faith attempt to understand what it is that I am actually
> trying to say rather than impose your own view of the world on my
> words.
Imposing my world view on you?? Where did this happen?? I'm not
imposing any view on anyone. I didn't even come in this thread with
any view -- just a question: does the Lisp-Scheme supposed difference
in representing program have any effect on me as a programmer? A
positive answer requires an example which you have not provided. Your
canonical example shows something else, as "prunesquallor" said:
| I don't see how this example demonstrates anything about READ.
> > > In fact, if you translate kuote into Scheme's macro system, then
> > > your kuote is a valid implementation of Scheme's quote (and indeed
> > > there is at least one Scheme that actually implements quote in
> > > pretty much that way).
> >
> > *rolls eyes*
> >
> > I know (and I know). And the fact that you keep ignoring is that the
> > fact that there is an implementation that implements quote in this
> > way and uses `read' to parse input is a strong indication that the
> > result of `(eq (foo) (foo))' is unrelated to the language being
> > defined on strings or s-exps.
>
> No. The fact that the implementation in question actually uses READ
> to parse input is entirely irrelevant to my argument, and if you
> don't see that then you have not understood what I have been saying.
But this was supposed to somehow expose the fact that Scheme might not
use `read'. If you don't mean that then you have not made
understandable what you were saying.
> > > The reason kuote is a valid implementation of Scheme's quote is that
> > > the semantics of (scheme-quote X) are that it returns X, but this is
> > > a definition of the semantics of the string "(quote X)", not the
> > > semantics of the list whose car is the symbol QUOTE.
> >
> > And by the way this is defined, it is necessarily the semantics of
> > "( quote X )" etc -- of any string that when passed to `read' returns
> > that list. Does the fact that it is not directly defined on sexps has
> > any effect on my programs?
>
> For the thousandth time, yes.
And for the thousand+1st time, what program?
> > -- all you need is an example of a program that would break if its
> > semantics is defined on strings. Your example doesn't seem to do
> > this.
>
> No, that is faulty logic.
Now, *that* is faulty logic.
> What I need is an example of a program that would break if Scheme's
> semantics were defined on lists. I have provided such an example,
> and therefore proven that Scheme's semantics are not defined on
> lists. [...]
You need either. Some code that works on one side and doesn't work on
the other side of the "semantics defined on lists" question. The
example you have given shows some strange implementation of `quote'
and some strange function inlining/quote-splicing.
> > > Because it is the definition of the semantics of a string, what it
> > > means is that you get back not the specific object X (because there
> > > is no specific object X), but an object whose string representation
> > > is X. Two such objects may or may not be EQ.
> >
> > This is a result of how `quote' is implemented, not how semantics is
> > defined.
>
> No. You are really missing something fundamental. What is at issue
> here is not what any particular Scheme implementation actually does,
> but rather what is considered correct behavior of a Scheme
> implementation that purports to conform to the standard. The actual
> existence of the implementation in question is not relevant.
Right, and you appeal to the fact that such an implementation is valid
to prove something about how the semantics are defined.
> What is relevant is that the consensus view of the Scheme community
> is that this implementation is a correct implementation of Scheme.
And yet it is unrelated to the issue you began with -- not with what
is considered a correct implementation of `quote', but on how is the
language defined.
> > Yes, this is one thing which is defined in the CL spec and not in
> > the Scheme spec. Unfortunately this is still not an indicator of
> > when your implementation uses `read' to parse code.
>
> That is correct, but again irrelevant. You keep missing the point.
> What matters is not that CL actually uses READ, but that one can
> reliably apply the model that it does use READ whether or not it
> actually does.
And the people are still waiting for a reason for why this is not true
in Scheme.
> (In fact, I believe that there are CL implementations that use a
> function other than #'cl:read to read code at the top level. But
> this too is irrelevant.)
(unsurprisingly.)
[
> You apparently don't know my opinion even in that restricted sense.
> The passage in question:
>
> > To be more precise, it demonstrates that one cannot reliably apply
> > the model that a Scheme program is the list produced by running
> > the text of the program through the READ function once.
>
> is not "my" opinion in any sense of the word.
If I tell you that camels spit 7.5 times for every time they shit, it
would be an opinon -- until I learn about camels.
> It is what I was told by members of the Scheme community.
And if I after I tell you that you tell it to other people, it is
still an opinion. So I am using opinion as the opposite of `fact' or
`proved fact'. If that's incorrect, feel free to sue me.
]
> My opinion (as expressed with no ambiguity at the start of the
> c.l.s. thread that started this whole mess) was that Scheme programs
> ought to be considered lists. But the necessary consequence of this
> is that (eq? (foo) (foo)) must return #T.
But as far as I have seen, you never showed that this is a necessary
consequence.
> And I was subsequently informed in no uncertain terms that my
> opinion was considered wrong by the Scheme community.
Maybe it is the connection between the `eq?' form and representation
that was considered wrong?
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
<···@barzilay.org> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> > <···@barzilay.org> wrote:
> >
> > > ···@jpl.nasa.gov (Erann Gat) writes:
> > >
> > > > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> > > > <···@barzilay.org> wrote:
> > > >
> > > > > [...]
> > > > > (defmacro kuote (l) `(list ,@(mapcar #'(lambda (x) `',x) l)))
> > > > > (defun baz () (kuote (1 2 3)))
> > > > > [...]
> > > >
> > > > Your question presumes that there is a difference between quote and
> > > > kuote. In Common Lisp there is, in Scheme there may or may not be.
> > >
> > > OK, OK, I got that part. My *question* is -- how does that show that
> > > Scheme is defined on strings?
> >
> > It (in and of itself) doesn't, and I never said it did.
>
> Huh??
Yes, I rather expected that response.
[Much snippage]
> So along with all that, I also understood that you think there is some
> observable Scheme behavior that demonstrates the fact that it uses
> strings and not lists. Now you say that there isn't any such
> difference
No, that is not what I said. What I said was (annotated to make the
meaning clear):
It (the relationship between kuote and quote) in and of itself doesn't
(demonstrate that the semantics of Scheme are defined on strings).
> does the Lisp-Scheme supposed difference
> in representing program have any effect on me as a programmer? A
> positive answer requires an example which you have not provided.
That is not so. I have provided an example. You can dispute whether my
example demonstrates what I said it does, but you cannot dispute that I
have in fact provided one, at least not if you want to continue this
dialog.
> And for the thousand+1st time, what program?
You're going to have to figure that out on your own. I have reached the
limits of my patience with you. Hint: it's two lines of code.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> <···@barzilay.org> wrote:
>
> > Huh??
>
> Yes, I rather expected that response.
Same.
> > does the Lisp-Scheme supposed difference in representing program
> > have any effect on me as a programmer? A positive answer requires
> > an example which you have not provided.
>
> That is not so. I have provided an example. You can dispute
> whether my example demonstrates what I said it does, but you cannot
> dispute that I have in fact provided one, at least not if you want
> to continue this dialog.
Yes, you have provided an example, and yes I have disputed it, and no
you have not showed that your example does what it is supposed to do
or given a different example. And despite what you're trying to make
of it, this should be something exact -- there either is an example or
there isn't, and if there is, it should be something that can be
clearly explained. It should definitely not take the form of
something that can be disputed, since it is not about some vague
notions of the "spirit" of Lisp or Scheme, or about subjective
statements like "call/cc is inherently evil" etc.
> > And for the thousand+1st time, what program?
>
> You're going to have to figure that out on your own. I have reached
> the limits of my patience with you. Hint: it's two lines of code.
If I am stupid enough to not understand by now that you insist on your
explanation-less example, then you should know better than trying to
push it yet another time. Either explain how your example shows that
Scheme can be implemented by character strings, or don't, but
certainly don't say again that it does work and expect some magic to
happen.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <ptikarex.fsf@comcast.net>
Eli Barzilay <···@barzilay.org> writes:
>
> and "prunesquallor" replied:
>
Just to make sure that no one is confused:
(eq ·············@comcast.net ···@ccs.neu.edu) => t
Erann Gat wrote:
> What I need is an example of a program that
> would break if Scheme's semantics were defined on lists. I have provided
> such an example, and therefore proven that Scheme's semantics are not
> defined on lists.
I haven't followed every nuance of this discussion by any means, and I may
even be repeating someone's point, in which case please forgive me. But I
have an observation/question:
In the example you gave:
(defun foo () '(1 2 3))
(eq (foo) (foo))
...whether this results in true or false doesn't necessarily answer the
question of whether the program is represented as a list. Surely, an
equally important factor is whether the meaning of a literal value in a
program, whether explicitly or implicitly quoted, is (a reference to) the
part of the program where the value appears; or, whether the appearance of
that value in code is a merely a way of denoting the construction of an
equivalent value at the time the code is executed.
If it's the latter, then even a language which represents code as lists at
all times, and is required by its specification to do so, *could*
nevertheless return false in the above case, unless the specification also
fully specifies the meaning of constants that appear in code. As I
understand it, the Scheme spec doesn't fully specify either of these issues.
IOW, I don't think I agree with this statement:
> > > Because it is the definition of the semantics of a string, what it
> > > means is that you get back not the specific object X (because there
> > > is no specific object X), but an object whose string representation
> > > is X. Two such objects may or may not be EQ.
The Scheme spec doesn't say anything about strings in this respect, does it?
The object you get back is guaranteed to be 'equal' ('equal?' in Scheme) to
the quoted representation in code, but it doesn't need to be 'eq', if the
code is considered to be an instruction for generating the value, rather
than the actual value itself.
A statement that's perhaps more clearly in conflict with what I'm saying is
this one:
> My opinion ... was that Scheme programs ought to be considered
> lists. But the necessary consequence of this is that (eq? (foo) (foo))
> must return #T.
It isn't really "a necessary consequence", is it? Or have I perhaps missed
some precondition that makes it so?
Anton
Erann Gat wrote:
>>And by the way this is defined, it is necessarily the semantics of
>>"( quote X )" etc -- of any string that when passed to `read' returns
>>that list. Does the fact that it is not directly defined on sexps has
>>any effect on my programs?
>
> For the thousandth time, yes.
I haven't yet completely understood all the details, but here is a try.
Consider the following Common Lisp program:
(with-input-from-string (s "(quote x)")
(read s))
This is required to always return a list with exactly the same symbols
(not considering package settings). Furthermore, QUOTE is required to
return exactly the object that it is passed as an argument - it is not
allowed to create something new that "looks like" the object being passed.
You can rely on the fact that a Common Lisp program is a list as
constructed by READ, and therefore you know that the result of (defun
foo () (quote x)) is always the same (EQ).
If I understand correctly, a Scheme program is allowed to not be a list
and not be constructed by READ. Therefore, the X in (QUOTE X) can be
compiled into anything - for example a sequence of intructions that
creates a new object that "looks like" X.
Is this a correct understanding?
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
In article <·············@f1node01.rhrz.uni-bonn.de>, Pascal Costanza
<········@web.de> wrote:
> Erann Gat wrote:
>
> >>And by the way this is defined, it is necessarily the semantics of
> >>"( quote X )" etc -- of any string that when passed to `read' returns
> >>that list. Does the fact that it is not directly defined on sexps has
> >>any effect on my programs?
> >
> > For the thousandth time, yes.
>
> I haven't yet completely understood all the details, but here is a try.
> Consider the following Common Lisp program:
>
> (with-input-from-string (s "(quote x)")
> (read s))
>
> This is required to always return a list with exactly the same symbols
> (not considering package settings). Furthermore, QUOTE is required to
> return exactly the object that it is passed as an argument - it is not
> allowed to create something new that "looks like" the object being passed.
>
> You can rely on the fact that a Common Lisp program is a list as
> constructed by READ, and therefore you know that the result of (defun
> foo () (quote x)) is always the same (EQ).
>
> If I understand correctly, a Scheme program is allowed to not be a list
> and not be constructed by READ. Therefore, the X in (QUOTE X) can be
> compiled into anything - for example a sequence of intructions that
> creates a new object that "looks like" X.
>
> Is this a correct understanding?
Yep, except for one small detail: since symbols with the same print name
are guaranteed to be EQ in Scheme, (quote x) is always EQ even in Scheme.
The different behavior doesn't manifest itself unless the argument to
quote is something that can be duplicated, like a list (or a vector or a
string).
E.
Pascal Costanza wrote:
> If I understand correctly, a Scheme program is allowed to not be a list
This response will seem somewhat pedantic, but nevertheless
here is my view of the discussion.
What's a program?
-----------------
A program is presented to the compiler as text. Not all
text strings are legal programs.
1.2 Syntax
Scheme, like most dialects of Lisp, employs a fully parenthesized
prefix notation for programs and (other) data; the grammar of Scheme
generates a sublanguage of the language used for data. An important
consequence of this simple, uniform representation is the
susceptibility of Scheme programs and data to uniform treatment by
other Scheme programs. For example, the eval procedure evaluates a
Scheme program expressed as data.
The read procedure performs syntactic as well as lexical decomposition
of the data it reads. The read procedure parses its input as data
(section 7.1.2), not as program.
For each legal program there exists a list (represented internally),
which external representation (as a string) coincides with the program.
Now, if one wants to use the function eval to evaluate a program,
one needs to represent the program as data (which means as a list [and
not as a string]). When we talk about the program evaluated by eval,
we talk about the program which has the same form as the external
representation of the list given to eval.
The concept of a program is abstract. A program can have different
representations. The semantics of Scheme is defined using one
representation of program, but one should not take this choice
too literally. One should think of the semantics at the abstract level.
I don't think the above quote from R5RS allows eval to take the
program to evaluate as a string -- since a single string is a valid
program, that should evaluate to it self.
> and not be constructed by READ.
One can generate the data representing the program given to eval
using any method. There is no demand that read should be used.
But there is one restriction on the data: It's external representation
must be a legal program (i.e. follow the syntax).
> Therefore, the X in (QUOTE X) can be
> compiled into anything - for example a sequence of intructions that
> creates a new object that "looks like" X.
Yes and no.
It is correct that (quote <something>) can evaluate to any value
with the same external representation as <something>.
I'm just not sure about the "therefore". That (quote <something>) is
allowed to return any value with the same external representation as
<something> is a choice independent of the choice of representation of
program used in specifying the semantics.
I only small problems in a hypothetical change of the standard
to include this:
"All occurences of (quote <something>) in a program is required
to evaluate to the same value"
That said, all serious implementations will return the same value
for all occurences of (quote <something>).
Too relieve the essential dullness [*] of this post, I will
put the spot on the article
"Compiling Syntactically Recursive Programs"
by Christian Queinnec
<http://citeseer.nj.nec.com/queinnec93compiling.html>
Which describes a transformation from syntactically recursive
programs (which are not legal Scheme programs, since they don't
have an external representation) into non-syntactically-recursive
programs.
At least it's somewhat related.
--
Jens Axel S�gaard
[*] This is a quote. Anybody recognize it?
In article <·························@dread12.news.tele.dk>,
=?ISO-8859-1?Q?Jens_Axel_S=F8gaard?= <······@jasoegaard.dk> wrote:
> Pascal Costanza wrote:
>
> > If I understand correctly, a Scheme program is allowed to not be a list
>
> This response will seem somewhat pedantic, but nevertheless
> here is my view of the discussion.
>
> What's a program?
> -----------------
>
> A program is presented to the compiler as text. Not all
> text strings are legal programs.
>
> 1.2 Syntax
>
> Scheme, like most dialects of Lisp, employs a fully parenthesized
> prefix notation for programs and (other) data; the grammar of Scheme
> generates a sublanguage of the language used for data. An important
> consequence of this simple, uniform representation is the
> susceptibility of Scheme programs and data to uniform treatment by
> other Scheme programs. For example, the eval procedure evaluates a
> Scheme program expressed as data.
>
> The read procedure performs syntactic as well as lexical decomposition
> of the data it reads. The read procedure parses its input as data
> (section 7.1.2), not as program.
>
> For each legal program there exists a list (represented internally),
> which external representation (as a string) coincides with the program.
That's right, but they (the list corresponding to the program and the
program itself) are not the same thing in Scheme.
> Now, if one wants to use the function eval to evaluate a program,
> one needs to represent the program as data (which means as a list [and
> not as a string]).
The standard is actually silent on what "represented as data" actually
means. It is also worth noting that EVAL did not become part of Scheme
until R5RS.
> When we talk about the program evaluated by eval,
> we talk about the program which has the same form as the external
> representation of the list given to eval.
That's right.
> The concept of a program is abstract. A program can have different
> representations. The semantics of Scheme is defined using one
> representation of program, but one should not take this choice
> too literally. One should think of the semantics at the abstract level.
Perhaps one should, but there is a difference between what one should do
and what the standard actually requires.
> I don't think the above quote from R5RS allows eval to take the
> program to evaluate as a string -- since a single string is a valid
> program, that should evaluate to it self.
Actually, there is evidence even here of Scheme's unease with the concept
of program semantics defined on data objects. The Scheme standard says:
Numerical constants, string constants, character constants,
and boolean constants evaluate "to themselves"; they need not
be quoted.
Note the scare quotes around "to themselves". If the semantics of Scheme
were really defined on data objects no scare quotes would be necessary.
The scare quotes are there because the standard is deliberately trying to
dance around a commitment to programs-as-data-objects. Contrast this with
the wording in the CL spec:
A form that is neither a symbol nor a cons is defined to be a
self-evaluating object. Evaluating such an object yields the
same object as a result.
Note the lack of scare-quotes.
E.
Erann Gat wrote:
> Jens Axel S�gaard wrote:
>>Pascal Costanza wrote:
>>>If I understand correctly, a Scheme program is allowed to not be a list
>>
>>This response will seem somewhat pedantic, but nevertheless
>>here is my view of the discussion.
>>
>>What's a program?
>>-----------------
>>
>>A program is presented to the compiler as text. Not all
>>text strings are legal programs.
>>
>> 1.2 Syntax
>>
>> Scheme, like most dialects of Lisp, employs a fully parenthesized
>> prefix notation for programs and (other) data; the grammar of Scheme
>> generates a sublanguage of the language used for data. An important
>> consequence of this simple, uniform representation is the
>> susceptibility of Scheme programs and data to uniform treatment by
>> other Scheme programs. For example, the eval procedure evaluates a
>> Scheme program expressed as data.
>>
>> The read procedure performs syntactic as well as lexical decomposition
>> of the data it reads. The read procedure parses its input as data
>> (section 7.1.2), not as program.
>>
>>For each legal program there exists a list (represented internally),
>>which external representation (as a string) coincides with the program.
>
>
> That's right, but they (the list corresponding to the program and the
> program itself) are not the same thing in Scheme.
Agreed.
>>Now, if one wants to use the function eval to evaluate a program,
>>one needs to represent the program as data (which means as a list [and
>>not as a string]).
>
>
> The standard is actually silent on what "represented as data" actually
> means. It is also worth noting that EVAL did not become part of Scheme
> until R5RS.
It's not that direct, but I section 1.2 and the examples of
eval makes it clear that the representation of programs as data
that eval expects is a list representation.
Besides, an eval-string can be written as
(define (eval-string program-represented-as-string env-specifier)
(eval (read program-represented-as-string env-specifier)))
>>When we talk about the program evaluated by eval,
>>we talk about the program which has the same form as the external
>>representation of the list given to eval.
>
> That's right.
>
>>The concept of a program is abstract. A program can have different
>>representations. The semantics of Scheme is defined using one
>>representation of program, but one should not take this choice
>>too literally. One should think of the semantics at the abstract level.
> Perhaps one should, but there is a difference between what one should do
> and what the standard actually requires.
True.
>>I don't think the above quote from R5RS allows eval to take the
>>program to evaluate as a string -- since a single string is a valid
>>program, that should evaluate to it self.
>
>
> Actually, there is evidence even here of Scheme's unease with the concept
> of program semantics defined on data objects. The Scheme standard says:
>
> Numerical constants, string constants, character constants,
> and boolean constants evaluate "to themselves"; they need not
> be quoted.
>
> Note the scare quotes around "to themselves". If the semantics of Scheme
> were really defined on data objects no scare quotes would be necessary.
> The scare quotes are there because the standard is deliberately trying to
> dance around a commitment to programs-as-data-objects. Contrast this with
> the wording in the CL spec:
>
> A form that is neither a symbol nor a cons is defined to be a
> self-evaluating object. Evaluating such an object yields the
> same object as a result.
>
> Note the lack of scare-quotes.
Good observation.
I guess this is part of the reason that Pitman wrote:
If I were to characterize my reason for thinking Scheme is
unacceptable, I'd say a lot of it comes down to "lack of respect
for object identity". I regard object identity as core, and
functionality to follow from identity. Much of Scheme definitionalism
seems to me to regard functionality as core and identity as a
constructed notion.
The issue isn't just "is it defined textually or as objects", but more
fundamentally, does a definition (like other things) have object
identity? There are a great number of things whose identities in
Scheme are regarded as unimportant.
--
Jens Axel S�gaard
Jens Axel S�gaard wrote:
> One can generate the data representing the program given to eval
> using any method. There is no demand that read should be used.
> But there is one restriction on the data: It's external representation
> must be a legal program (i.e. follow the syntax).
>
>> Therefore, the X in (QUOTE X) can be
>> compiled into anything - for example a sequence of intructions that
>> creates a new object that "looks like" X.
>
>
> Yes and no.
>
> It is correct that (quote <something>) can evaluate to any value
> with the same external representation as <something>.
>
>
> I'm just not sure about the "therefore". That (quote <something>) is
> allowed to return any value with the same external representation as
> <something> is a choice independent of the choice of representation of
> program used in specifying the semantics.
>
> I only small problems in a hypothetical change of the standard
> to include this:
>
> "All occurences of (quote <something>) in a program is required
> to evaluate to the same value"
>
>
> That said, all serious implementations will return the same value
> for all occurences of (quote <something>).
Thanks for your reply. I think it helps to detect the actual
misunderstandings in this discussion.
Because Common Lisp requires the program to be constructed by read (or a
function with the same semantics as read) _and_ because QUOTE is
required to return the exact same object being passed to it, a function
(defun foo () (quote ...)) is required to always return the same (EQ)
object.
Because Scheme doesn't require the program to be constructed by read
_and_ because quote is not required to return the exact same object
being passed to it, such a function is not required to always return the
same object.
In Scheme, it doesn't help to fix this by changing the requirements for
QUOTE because the "program constructor" is allowed to rearrange the
program in arbitrary ways. A combination of the two following steps
would result in FOO returning different objects:
+ The "program constructor" arranges the code to create a new object
being passed to QUOTE (something that "looks like" the object as
represented in the program text).
+ An optimizer inlines each call to FOO.
Now, we would have at least as many different objects as calls to FOO
denoted by the same program text.
In Common Lisp, this situation cannot occur because the argument being
passed to QUOTE _is_ the object being returned by it. So even when an
optimizer inlines calls to FOO the inlined copies of the function body
would still refer to the exact same object.
For example, the internal representation of (progn (foo) (foo)) would
look as follows:
[.|.]->[.|.]->[.|.]->NIL
| | |
PROGN | [.|.]->[.|.]->NIL
| | |
| QUOTE @---+
| |
[.|.]->[.|.]->NIL |
| | |
QUOTE +----------+
The only way to fix this in Scheme would be to change the requirements
for _both_ the program constructor and QUOTE. For example, the program
constructor could be required to behave like READ.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
In article <·············@f1node01.rhrz.uni-bonn.de>, Pascal Costanza
<········@web.de> wrote:
> Because Common Lisp requires the program to be constructed by read (or a
> function with the same semantics as read)
That's not quite true. CL only requires that this be true for programs
represented as textual source code. But it is possible in CL to construct
programs by other means. There are legal CL programs that do not have
readable (or even printable) representations.
By contrast, all legal Scheme programs must be representable as text.
E.
Pascal Costanza wrote:
> In Scheme, it doesn't help to fix this by changing the requirements for
> QUOTE because the "program constructor" is allowed to rearrange the
> program in arbitrary ways. A combination of the two following steps
> would result in FOO returning different objects:
>
> + The "program constructor" arranges the code to create a new object
> being passed to QUOTE (something that "looks like" the object as
> represented in the program text).
>
> + An optimizer inlines each call to FOO.
>
> Now, we would have at least as many different objects as calls to FOO
> denoted by the same program text.
[For whole program compilation:]
If the implementation collects all quoted values in an array
and compiles (quote <something>) to
(quotations-ref <index-of-something>), then the same value
would be generated even though the calls were inlined.
But more to the point:
If the standard said that (quote <omething>) always should
return the same value, then optimizers should respect that
behaviour.
--
Jens Axel S�gaard
Jens Axel S�gaard wrote:
> Pascal Costanza wrote:
>
>> In Scheme, it doesn't help to fix this by changing the requirements
>> for QUOTE because the "program constructor" is allowed to rearrange
>> the program in arbitrary ways. A combination of the two following
>> steps would result in FOO returning different objects:
>>
>> + The "program constructor" arranges the code to create a new object
>> being passed to QUOTE (something that "looks like" the object as
>> represented in the program text).
>>
>> + An optimizer inlines each call to FOO.
>>
>> Now, we would have at least as many different objects as calls to FOO
>> denoted by the same program text.
>
>
> [For whole program compilation:]
> If the implementation collects all quoted values in an array
> and compiles (quote <something>) to
> (quotations-ref <index-of-something>), then the same value
> would be generated even though the calls were inlined.
>
>
> But more to the point:
>
> If the standard said that (quote <omething>) always should
> return the same value, then optimizers should respect that
> behaviour.
Sure. However, if the standard doesn't prescribe how these values are to
be constructed then you may still get different values. It's a
combination of the two points above that lead to the situation that (eq
(foo) (foo)) might be #f.
Because in Common Lisp it is required that a program needs to have list
structure, it is clear what "a value being passed to quote" is. Because
in Scheme the former is not required, the latter is not clear.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza wrote:
> Because in Common Lisp it is required that a program needs to have list
> structure, it is clear what "a value being passed to quote" is. Because
> in Scheme the former is not required, the latter is not clear.
If it's not clear, that's a fault in the writing of the Scheme standard. I
don't think there's anything about the behavior in question that isn't
clear.
(That assumes that "clear" isn't being used to mean "not specified" - the
fact that the result of (eq? (foo) (foo)) is not completely specified in the
Scheme standard, is by design.)
Anton
Anton van Straaten wrote:
> Pascal Costanza wrote:
>
>>Because in Common Lisp it is required that a program needs to have list
>>structure, it is clear what "a value being passed to quote" is. Because
>>in Scheme the former is not required, the latter is not clear.
>
>
> If it's not clear, that's a fault in the writing of the Scheme standard. I
> don't think there's anything about the behavior in question that isn't
> clear.
>
> (That assumes that "clear" isn't being used to mean "not specified" - the
> fact that the result of (eq? (foo) (foo)) is not completely specified in the
> Scheme standard, is by design.)
Indeed, I have meant "not specified". Thanks for your clarification.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza wrote:
> Jens Axel S�gaard wrote:
>> But more to the point:
>>
>> If the standard said that (quote <omething>) always should
>> return the same value, then optimizers should respect that
>> behaviour.
>
>
> Sure. However, if the standard doesn't prescribe how these values are to
> be constructed then you may still get different values. It's a
> combination of the two points above that lead to the situation that (eq
> (foo) (foo)) might be #f.
>
> Because in Common Lisp it is required that a program needs to have list
> structure, it is clear what "a value being passed to quote" is. Because
> in Scheme the former is not required, the latter is not clear.
I agree that one should be careful, if one wanted to change the
semantics, but I think it would be possible to make such a change.
One very na�ve implementation method would be to keep table
of values returned as the result as a quote-form so far,
and check there each a new quote form is evaluated.
I agree, that the Common Lisp case is much clearer.
--
Jens Axel S�gaard
From: ··········@YahooGroups.Com
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <REM-2003sep17-013@Yahoo.Com>
{{Date: Wed, 03 Sep 2003 09:21:52 +0200
From: Jens Axel Sxgaard <······@jasoegaard.dk>
If the standard said that (quote <something>) always should return the
same value, then optimizers should respect that behaviour.}}
But what precisely does "the same value" mean? For example, what if the
quoted value is a number or character, and the type of the return value
has been declared of that type, so that a non-boxed object can be
returned, and then the call to EQ re-boxes each copy separately and
voila returns NIL instead of T? This doesn't affect the case of (quote
(1 2 3)), but it indicates this is not the best language to use to
clearly say what we really mean.
I think if we want to mean what we always meant, we'll have to stick to
the original language, namely that READ of source code produces
such-and-such pointy structure composed mostly of daisy chains of CONS
pairs, and that EVAL on such a pointy structure has such and such
semantics for each function and special/macro-operator, and in
particular EVALuating a form whose CAR is QUOTE returns exactly the
CADR of the form as-is (not evaluated), and the compiler must arrange
to produce equivalent results. Whether it's EQ or not later depends on
other factors discussed elsewhere (whether it's a number or character
for example). One key point is that any sub-expression is EQ to itself,
and when passed around without any form of coercion (via COERCE or THE)
or copying (via COPY-LIST for example) it'll remain EQ to itself except
in case of numbers or characters.
··········@YahooGroups.Com writes:
> {{Date: Wed, 03 Sep 2003 09:21:52 +0200
> From: Jens Axel Sxgaard <······@jasoegaard.dk>
> If the standard said that (quote <something>) always should return the
> same value, then optimizers should respect that behaviour.}}
>
> But what precisely does "the same value" mean? For example, what if the
> quoted value is a number or character, and the type of the return value
> has been declared of that type, so that a non-boxed object can be
> returned, and then the call to EQ re-boxes each copy separately and
> voila returns NIL instead of T? This doesn't affect the case of (quote
> (1 2 3)), but it indicates this is not the best language to use to
> clearly say what we really mean.
Look up "same" in the glossary. Unadorned, "same" means "same under EQL".
Nothing in CL uses EQness as a meaningful test except a few legacy
efficiency hacks. In all "real" cases, EQL is the base-line identity
comparison function used consistently throught the language, and EQ
is sub-primitive exactly to hide the boxed issues you refer to above.
The standard assigns "identical" to mean "same under EQ", but doesn't use
the term much at all. It's there mostly to say "when we say 'same', we
don't mean 'identical' (unless we said 'same under EQ')".
When the file compiler becomes involved, the requirement is relaxed to
use the "similarity" rules for externalized constants.
> I think if we want to mean what we always meant, we'll have to stick to
> the original language, namely that READ of source code produces
> such-and-such pointy structure composed mostly of daisy chains of CONS
> pairs, and that EVAL on such a pointy structure has such and such
> semantics for each function and special/macro-operator, and in
> particular EVALuating a form whose CAR is QUOTE returns exactly the
> CADR of the form as-is (not evaluated), and the compiler must arrange
> to produce equivalent results.
There is no formal meaning to the word "equivalent" in the CL standard.
That's a fuzzy, handwaving term. The compiler, by the way, has to return
something "similar", not "equivalent". It's not that similar things
aren't equivalent, it's just that "equivalent" has no meaning without
additional cues specifying context; similarity comes pre-bundled with
a notion of context.
> Whether it's EQ or not later depends on
> other factors discussed elsewhere (whether it's a number or character
> for example). One key point is that any sub-expression is EQ to itself,
> and when passed around without any form of coercion (via COERCE or THE)
> or copying (via COPY-LIST for example) it'll remain EQ to itself except
> in case of numbers or characters.
I recommend never using the word EQ and always using EQL (and/or the glossary
term "same") when talking about what the standard requires, except in the
handful (six or seven?) of exception cases where EQ is specially called for.
But as a conceptual model, the language simply isn't based on EQ-level
identity, it's based on EQL-level identity. That is, CL creates a virtual
machine and within the "CL machine" the name for what you're calling EQ is
EQL; there are times when CL gives you subprimitive access to detecting some
implementation-level splitting of objects through the subprimitive EQ, but
if you never use EQ you would never know. This will keep you from having to
say "except in the case of numbers or characters" every 2 sentences.
From: ··········@YahooGroups.Com
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <REM-2003sep19-002@Yahoo.Com>
{{Date: 18 Sep 2003 07:07:23 -0400
From: Kent M Pitman <······@world.std.com>
In all "real" cases, EQL is the base-line identity comparison
function used consistently throught the language}}
It's my understanding that (EQL p q) returns true iff at least one of
these is/are true:
(1) (EQ p q) returns true;
(2) p and q are numbers of the same type with the same value;
(3) p and q are character objects representing exactly the same character.
Correct me if that's not correct.
[using EQL] {{will keep you from having to say "except in the case of
numbers or characters" every 2 sentences.}}
Hmm, indeed for my current purpose of discussion, using EQL seems to be
what I need to say to be concise. So then:
{{When the file compiler becomes involved, the requirement is relaxed
to use the "similarity" rules for externalized constants.}}
That statement is too vague/ambiguous to address our current need in
discussion. Yes, I know that if you load the same function in two
different times, the self-evaluating form or quoted constant deep
within the function won't necessarily be EQL between the two loadings,
so if you rename the function after the first loading, then call the
renamed version and the reloaded version and compare return values
(which include the constant), they (instances of that constant within
the return values) might not be EQL. But if you load the compiled
function just once, and then call it twice, are the returned values
(specifically the parts from from the constant) guaranteed by the
standard to be EQL (as CL programmers assume) or not (as Scheme
programmers accept)?
Example to clarify what I wrote above:
(defun foo () (cons :FOO (quote (1 2 3))))
;... Compile above to file and load result back in ...
(eql (foo) (foo)) ==> NIL (because CONS always makes a new pair)
(eql (cdr (foo)) (cdr (foo))) ==> T or not necessarily T ??
{{The compiler, by the way, has to return something "similar", not
"equivalent".}}
Only similar to the original I agree. But only similar to each other
when successive calls to the same function are made?? I.e. if the
compiler returns a compiled function containing something (some ONE
thing) similar to the original, does a call to the compiled code have
to return exactly that same one thing each time it's called, so the
successive return values (or constant-parts thereof) are EQL to each
other, or can the compiled code return a different (non EQL) something
each time it's called?
··········@YahooGroups.Com writes:
> ... But if you load the compiled
> function just once, and then call it twice, are the returned values
> (specifically the parts from from the constant) guaranteed by the
> standard to be EQL (as CL programmers assume) or not (as Scheme
> programmers accept)?
I believe the former. The variability is in how the loader reconstructs
what the file compiler has dumped, not in whether that thing that was
reconstructed is still a constant. It's still has constant identity,
it's just uncertain until it's reloaded what it is. Once back in the
Lisp world, nothing mucks with its identity.
> Example to clarify what I wrote above:
> (defun foo () (cons :FOO (quote (1 2 3))))
> ;... Compile above to file and load result back in ...
> (eql (foo) (foo)) ==> NIL (because CONS always makes a new pair)
> (eql (cdr (foo)) (cdr (foo))) ==> T or not necessarily T ??
Necessarily T.
> {{The compiler, by the way, has to return something "similar", not
> "equivalent".}}
>
> Only similar to the original I agree. But only similar to each other
> when successive calls to the same function are made?? I.e. if the
> compiler returns a compiled function containing something (some ONE
> thing) similar to the original, does a call to the compiled code have
> to return exactly that same one thing each time it's called, so the
> successive return values (or constant-parts thereof) are EQL to each
> other, or can the compiled code return a different (non EQL) something
> each time it's called?
If it was a constant, it is still a constant. Are you asking whether
someting is allowed to just change things spuriously? No, it's not.
There is the possibility of a relocating GC, and the identity of the moved
thing is visible to lowlevel facilities (and perhaps even to the printer
if the #<foo 12345> notation is used, sometimes creating an issue for
certain hash tables, but when this happens, the Lisp system is supposed
to cover the fact of the move, and the change in printed representation
should still be uniform--that is, any given instance will have uniformly
changed behavior; you can't find some "copies" (whatever that would mean)
of it that have some prior designation and others that don't; touching
them is supposed to flag the system to update stuff so that this transition
is invisible. and those numbers in #<...> are (i hope) documented to be not
reliable, only for debugging.
From: ··········@YahooGroups.Com
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <REM-2003sep20-001@Yahoo.Com>
{{Date: 19 Sep 2003 13:20:31 -0400
From: Kent M Pitman <······@world.std.com>
The variability is in how the loader reconstructs what the file
compiler has dumped, not in whether that thing that was reconstructed
is still a constant. It's still has constant identity, it's just
uncertain until it's reloaded what it is. Once back in the Lisp
world, nothing mucks with its identity.}}
So does the term "constant identity" exist in the formal spec, and does
it mean EQL of two such always returns T? Or if that's just your own
term, does the formal spec anywhere make it clear that a constant is
only necessarily EQUAL across PRINTing to file and READing back in, or
across compiling to a file and LOADing back in, but necessarily EQL
across compiling in-core and across all usages (*) within a single
LOADing or READing from file?
* (Usage means binding to local or special variable, referencing such a
binding, passing a parameter, returning a value, throwing/catching and
any similar return-from or error/signal/event handling, storing in any
place, retrieving from any place, and handling multiple values. It does
not include printing to a string and then reading from that string, or
any explicit copying such as COPY-LIST or non-last arg to APPEND etc.)
Actually, does the formal spec anywhere say that EQLity is preserved
across each of the kinds of usages I listed above? For example, if at
one level of program there's a local variable with some value, and that
value is passed to a function being called, and that function passes
that value to another function, and that function stores the value in a
place, and then back up at the original level
(EQL <OriginalValue> <FinalPlace>)
returns T?
The point is that it's not possible to directly test EQL across
different contexts such as inside and outside a function call, so it's
metaphysical (unobservable) whether the original value is EQL to some
deep-inside-function value, but whenever the daisy chain of values each
EQL to the next finally closes the loop, i.e. end value is in same
lexical context as original value, at that point EQL could be called
between original and endpoint and result should be T because of
metaphysical transitivity of EQL along each link in the chain yielding
observable fact relating the two endpoints.
{{Are you asking whether somet[h]ing is allowed to just change things
spuriously?}}
I'm asking whether the formal CL spec absolutely and unambiguously
forbids any of the usages (listed above) to break the EQL-ness of a
chain, or whether this is just something Lisp programmers (except
Scheme programmers) always took for granted and forgot to explicitly
state in the CL spec. For just one simple example: Does the CL spec
clearly state that if (lambda (x) ...) is applied to the lexical
variable y (i.e. the value/binding of y is passed as the binding of x),
that inside the body of that lambda form (EQL x y) would necessarily
return true (assuming that outer binding of y is somehow accessible)?
{{There is the possibility of a relocating GC, and the identity of the
moved thing is visible to lowlevel facilities (and perhaps even to
the printer if the #<foo 12345> notation is used, sometimes creating
an issue for certain hash tables, but when this happens, the Lisp
system is supposed to cover the fact of the move, and the change in
printed representation should still be uniform--that is, any given
instance will have uniformly changed behavior; you can't find some
"copies" (whatever that would mean) of it that have some prior
designation and others that don't; touching them is supposed to flag
the system to update stuff so that this transition is invisible. and
those numbers in #<...> are (i hope) documented to be not reliable,
only for debugging.}}
I think basically we're dealing with places where a value might be
held, using place in the sense of SETF, which includes simple-variable
bindings, object-slot bindings, and parts of objects such as CAR and
CDR of a CONS pair and ELT of a vector etc. When we pass arguments to
functions, make bindings via LET and LAMBDA, return values from
functions, etc., the original place whose value was the source for this
operation, and the new place which gets the value, must have EQL
values. So just before a relocating GC occurs, there are a set of
places that all have relatively EQL values. Then after the relocating
GC occurs, a mapping from old to new object preserves this relative EQL
property. If
(EQL place1old place2old) ==> T before the GC
and
place1old --GC-> place1new
place2old --GC-> place2new
then
(EQL place1new place2new) ==> T after the GC
How is the above claim observable, not metaphysical? By using anchors
(every symbol interned in every currently-present package, and every
stack frame currently active, and any register-located values of the
current frame, did I miss anything?), following links from there to get
a sample of places, performing EQLs on those places before the GC,
writing out the results of those EQLs, then doing the EQLs, then
following the "same" links from the same anchors to arrive at the same
sample of places and performing the corresponding EQLs on those post-GC
places, and comparing results to what had been written before.
(Quotes around "same" because after the GC the actual links may be
different because the target has been relocated, so for example CAR of
a place that didn't move might point to an object that has moved. So
"same" means perform the same operations such as SYMBOL-VALUE or CAR
with possibly different machine results before and after the GC.)
So I agree a properly working GC should preserve EQLness across the GC
operation, but is that unambiguously stated in the formal CL spec?
Big question: Is a relocating GC allowed to collapse constants to
consume less memory after the GC? For example, is the following
behaviour allowed or forbidden:
(defconstant *a* '(1 2 3))
(defconstant *b* '(2 3))
(eql (cdr *a*) *b*) ==> NIL
(gc)
(eql (cdr *a*) *b*) ==> T
I assume of course that splitting and/or collapsing EQness of numbers
and characters is allowed at any time, including during a GC, right?
(Which is part of why we're sticking to talking about EQL nowadays.)
··········@YahooGroups.Com writes:
> So does the term "constant identity" exist in the formal spec, and does
> it mean EQL of two such always returns T? Or if that's just your own
> term, does the formal spec anywhere make it clear that a constant is
> only necessarily EQUAL across PRINTing to file and READing back in, or
> across compiling to a file and LOADing back in, but necessarily EQL
> across compiling in-core and across all usages (*) within a single
> LOADing or READing from file?
The spec says that QUOTE returns object. It doesn't say "any of several
objects that are equivalent under some predicate of our choice".
The reason there is any issue at all is that there is a question about
which object necessarily created by living in the universe we're in. To
have it be the same object even across file writes would require a universal
unchanging globally accessible namespace of objects, which was not the intent.
So some accomodation is made to the reality of trying to write something
out and read it back in.
But other than that accomodation, I would ask the reverse question: what
gives you any reason to believe it won't return the EQL object? When
IDENTITY returns the object that it is given, do you worry you'll just get an
equivalent object? The terminology used for IDENTITY and for QUOTE are
close to the same (not exactly the same only because I was sloppy). So
if you trust one and not the other, why is that?
> * (Usage means binding to local or special variable, referencing such a
> binding, passing a parameter, returning a value, throwing/catching and
> any similar return-from or error/signal/event handling, storing in any
> place, retrieving from any place, and handling multiple values. It does
> not include printing to a string and then reading from that string, or
> any explicit copying such as COPY-LIST or non-last arg to APPEND etc.)
>
> Actually, does the formal spec anywhere say that EQLity is preserved
> across each of the kinds of usages I listed above?
Well, it uses the english word "the" referring to "the object" all over,
as if there were no other. This implies a certain degree of strong identity
relationship. The glossary defines "same" as meaning EQL in order to
emphasize this.
> For example, if at
> one level of program there's a local variable with some value, and that
> value is passed to a function being called, and that function passes
> that value to another function, and that function stores the value in a
> place, and then back up at the original level
> (EQL <OriginalValue> <FinalPlace>)
> returns T?
Yes, that's why all the fuss is made about it not being EQ. To emphasize
that the degree of latitude an implementation has is at the EQ/EQL boundary,
not higher.
Also, there are a billion examples in the spec that wouldn't work if
this were not reliably true.
> The point is that it's not possible to directly test EQL across
> different contexts such as inside and outside a function call, so it's
> metaphysical (unobservable) whether the original value is EQL to some
> deep-inside-function value, but whenever the daisy chain of values each
> EQL to the next finally closes the loop, i.e. end value is in same
> lexical context as original value, at that point EQL could be called
> between original and endpoint and result should be T because of
> metaphysical transitivity of EQL along each link in the chain yielding
> observable fact relating the two endpoints.
And, indeed, for unobservables, the implementation is allowed to cheat
as long as it doesn't cut corners on observables. The simplest example
of that is the lisp machine use of forwarding pointers. (mentioned
again below, i see. oops--i'm repeating myself) It _is_ possible
in that case to get splitting internally on the lispm, but EQL lies about
it and tracks the forwarding implicitly so that you can't really tell.
(It does create a performance cost and a gc cost, but that is beyond the
scope of language semantics (which I'm some days sad is true, but
nevertheless is useful and used in some cases).)
> {{Are you asking whether somet[h]ing is allowed to just change things
> spuriously?}}
>
> I'm asking whether the formal CL spec absolutely and unambiguously
Unambiguously? It's written in English.
But I think it both intends and achieves this result.
Others are welcome to advance alternate theories but I would
encourage them to do them only if they truly believe both their
claim is right and necessary. Otherwise, you're just asking to split
the community over a hypothetical.
> forbids any of the usages (listed above) to break the EQL-ness of a
> chain, or whether this is just something Lisp programmers (except
> Scheme programmers) always took for granted and forgot to explicitly
> state in the CL spec. For just one simple example: Does the CL spec
> clearly state that if (lambda (x) ...) is applied to the lexical
> variable y (i.e. the value/binding of y is passed as the binding of x),
> that inside the body of that lambda form (EQL x y) would necessarily
> return true (assuming that outer binding of y is somehow accessible)?
I think it does forbid this.
I don't think many compiler optimizations would work if you assumed
otherwise.
I'm nearly certain a lot of the examples in the spec would break if you
did this. (Not that the examples in the spec are "binding" in a formal
sense, but they do act to normalize people's interpretation.)
> {{There is the possibility of a relocating GC, and the identity of the
> moved thing is visible to lowlevel facilities (and perhaps even to
> the printer if the #<foo 12345> notation is used, sometimes creating
> an issue for certain hash tables, but when this happens, the Lisp
> system is supposed to cover the fact of the move, and the change in
> printed representation should still be uniform--that is, any given
> instance will have uniformly changed behavior; you can't find some
> "copies" (whatever that would mean) of it that have some prior
> designation and others that don't; touching them is supposed to flag
> the system to update stuff so that this transition is invisible. and
> those numbers in #<...> are (i hope) documented to be not reliable,
> only for debugging.}}
>
> I think basically we're dealing with places where a value might be
> held, using place in the sense of SETF, which includes simple-variable
> bindings, object-slot bindings, and parts of objects such as CAR and
> CDR of a CONS pair and ELT of a vector etc. When we pass arguments to
> functions, make bindings via LET and LAMBDA, return values from
> functions, etc., the original place whose value was the source for this
> operation, and the new place which gets the value, must have EQL
> values. So just before a relocating GC occurs, there are a set of
> places that all have relatively EQL values. Then after the relocating
> GC occurs, a mapping from old to new object preserves this relative EQL
> property.
Yes.
> If
> (EQL place1old place2old) ==> T before the GC
> and
> place1old --GC-> place1new
> place2old --GC-> place2new
> then
> (EQL place1new place2new) ==> T after the GC
> How is the above claim observable, not metaphysical? By using anchors
> (every symbol interned in every currently-present package, and every
> stack frame currently active, and any register-located values of the
> current frame, did I miss anything?), following links from there to get
> a sample of places, performing EQLs on those places before the GC,
> writing out the results of those EQLs, then doing the EQLs, then
> following the "same" links from the same anchors to arrive at the same
> sample of places and performing the corresponding EQLs on those post-GC
> places, and comparing results to what had been written before.
> (Quotes around "same" because after the GC the actual links may be
> different because the target has been relocated, so for example CAR of
> a place that didn't move might point to an object that has moved. So
> "same" means perform the same operations such as SYMBOL-VALUE or CAR
> with possibly different machine results before and after the GC.)
(It's also observable by print name sometimes,but this is a documented
thing.)
> So I agree a properly working GC should preserve EQLness across the GC
> operation, but is that unambiguously stated in the formal CL spec?
>
> Big question: Is a relocating GC allowed to collapse constants to
> consume less memory after the GC? For example, is the following
> behaviour allowed or forbidden:
> (defconstant *a* '(1 2 3))
> (defconstant *b* '(2 3))
> (eql (cdr *a*) *b*) ==> NIL
> (gc)
> (eql (cdr *a*) *b*) ==> T
No. For one thing, the GC doesn't exist in the spec at all, so your
question is functionally equivalent to
(eql (cdr *a*) *b*) ==> NIL
;time passes
(eql (cdr *a*) *b*) ==> T
And I think the only thing that is allowed to change identity, such as it is,
is externalization (what Java calls serialization). Once something is
"in the image", it has identifiable identity. This isn't said anywhere,
but there is no allowance for it to be otherwise either. The places
where splitting/coalescing is allowed are stated.
> I assume of course that splitting and/or collapsing EQness of numbers
> and characters is allowed at any time, including during a GC, right?
> (Which is part of why we're sticking to talking about EQL nowadays.)
Right. The whole point is that you might be in a situation like Maclisp
had where you have a set of registers allocated for heap-consed pointers
and a set of registers for "numbers" (not gc'd, since they are not lisp
data in some sense). A properly compiled function may realize that
intermediate quantities do not escape and so needs to be able to move
the numbers into number registers and do math on them. In the process,
their identity may be lost. e.g., (+ x 0) might yield x or might yield
something else, since (+ x y) might yield a new number and y might equal
0. In Maclisp, small fixnums were usually interned in the heap and tended
to end up re-eq-ified after, but larger fixnums didn't. (The exact number
was dependent on how much storage was left at the end of certain pages
when other things finished compiling; that number was added to a fixed
minimum number of cells that were always present for interning.) It was
possible to make non-eq small fixnums by rplacd'ing large fixnums in low
safety code. :) I mention this both because it's cute and also because
the maclisp number code was reknowned for being as fast as (actually,
faster than) DEC FORTRAN on the pdp10, and because as far as I know, CL
is designed to permit tricks like Maclisp used to do (even though machine
architectures and image layouts have changed such that it isn't always
relevant to do some of those tricks).
One could, btw, argue that some other data structures should have similar
capabilities, especially if there were hardwares that supported those
other data. Though just offhand, I'd say the sudden turn the world took
toward RISC instruction sets made that less likely. At the time of CL's
design, there were lots of wide-word instruction sets that made it more
likely and CL's design might should have accomodated those things
better, but it turns out not to have mattered too much...
From: ··········@YahooGroups.Com
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <REM-2003sep17-012@Yahoo.Com>
{{Date: 01 Sep 2003 17:52:45 -0400
From: Eli Barzilay <···@barzilay.org>
And by the way this is defined, it is necessarily the semantics of "(
quote X )" etc -- of any string that when passed to `read' returns
that list. Does the fact that it is not directly defined on sexps
has any effect on my programs?}}
Let me jump in and try to clarify this point: In CL, there's a point
after (defun ... (quote (1 2 3)) ...) has been read in where there's a
multi-level list whose CAR is the identifier DEFUN and somewhere deep
inside it there's exactly this data structure:
(QUOTE [ ])
!
(1 2 3)
That code snippet is defined by CL to return exactly that sub-list (1 2
3), not some copy of it, when evaluated. So if that snippet is
evaluated multiple times, all the return values will be EQ to each
other, even if a garbage collect happens between them, so long as we're
in the same core-image.
Now the compiler is required to generate code which respects those
semantics for that (QUOTE ...) code snippet. In particular, the
function being defined, is required to generate code equivalent to
evaluating that snippet once per call, not some other snippet, not a
copy of that snippet, but that exact snippet itself. So the compiled
code is required in CL to return that exact same (1 2 3) lower-level
list each time, so (eq (foo) (foo)) is guaranteed to be true.
More generally, if that particular (quote (1 2 3)) object were
generated in memory once, and were included as a snippet deep inside
the pointy-strucures expressing five different function definitions and
two global variable defconstants or defvars with initial value, and
those functions were all compiled, and then all five functions were
called and the sub-expression of that global were evaluated, all seven
return values would be EQ. (Not necessarily the return value of the
whole function, for example if one of the functions wrapped something
around the return value from that code snippet, but the return value
from that snipped would be EQ and by extracting it from the function
return value we could verify indeed it was EQ.) If you don't like user
programs CONSing up structures then passing them to the compiler, you
could use the repeat-part #1= and #1# notation to lexically include the
same exact sub-pointy-structure seven places in the five function
definitions and the two global var/const definitions.
But in Scheme, the claim is that the above logic is invalid, because
repeatedly calling the function that contains the (QUOTE (1 2 3))
snippet doesn't necessarily yield EQ results, hence Scheme semantics
aren't defined on the pointy structure resulting from READing in the
program source, and as Erann Gat says in his other followup to your
article [[Granted that does not prove that Scheme's semantics are
defined on strings, but it would seem to be the only remaining
possibility.]] (More properly: The above logic is an implication If
Scheme semantics are defined on pointy structures from READing source
code, then EQ would return T. But EQ doesn't return T, hence Scheme
semantics aren't defined on pointy structures from reading source
code.) And if you want to nitpick that: In CL, *every* function and
special/macro operator is precisely defined on how it treats data given
as pointy structures. In Scheme, this is not true, at least one special
operator, namely QUOTE, doesn't satisfy that.
Eli Barzilay <···@barzilay.org> writes:
> Ingvar Mattsson <······@cathouse.bofh.se> writes:
[SNIP]
> > This is turned into a function definition and on calling the function,
> > QUOTE returns *exactly* its argument. Since list (and indeed all sorts
> > of object) identity is important in lisp, it thus returns THE SAME
> > list every time (well, the return value is EQ).
>
> (So you say that quote works this way because list identity is
> important?)
No, I say QUOTE works this way because identity is important, the
arument to QUOTE need not be a list, it may (say) be a symbol.
Obviously, in the case of symbols, it's hard(er) to get two with the
same name, in the same packaeg, that aren't EQ. t's the most
sensible way of returning a value from what (after all) is a special
operator that says "please return argument unevaluated".
> > So, barring function re-definitions, (eq (foo) (foo)) should always
> > be true.
>
> And again, my question is how is that related to that magical fact
> that in Scheme the evaluator or the semantics use strings.
If teh semantics of the language is defined on lists, the above
example *cannot* return non-EQ lists, since teh function has teh
actual return value embedded in itself, verbatim.
If, say, it uses a completely different internal representation and
creates the return value from scratch (since tehre is no embedded list
to return verbatim), we can't really expect the return values to be EQ.
> Please read my post again, and Erann's claim.
I have. You seem to miss the point that the return value is embedded
verbatim in the function definition in function FOO. This is obviously
doable even in something defined in term of "strings" (just scan the
function until you find stuff that needs to be returned verbatim,
convert to internal format on function definition, then return as-is
when needed), but it's something one gets "for less cost"[1] if the
language is defined in terms of a richer set of data than "strings".
> > Contrast this with a function BAR, such that:
> > (defun bar () (list 1 2 3))
> > With this definition it is "obvious" that (eq (bar) (bar)) cannot
> > ever be true (barring function redefinitions).
>
> This is supoprting my point. If you look closely, you'll find out
> that the little ascii diagram for this function look the same. Then
> you might ask yourself -- if one function is returning a different
> object every time, and another function returns the same one, and both
> pieces of code are represented in the same way, then how come the
> original example returning `nil' is an indication of anything?
The function LIST takes 0 or more arguments and creates a *new* list,
with those as atoms. So, the difference between QUOTE and LIST {and I
shall forgive you missing the simple fact that they do, actually, not
have the same "shape", since one is (s s s (s (s s s))) and the other
is (s s s (s s s s))} makes for a nice illustrating difference between
things that explicitly create new structure and things that explicitly
don't.
> Or maybe you're trying to emphasize my point here?
No, I am trying to demonstrate that while list representation is a
necessary condition, it is not the only condition needed to create teh
situation we're talking about.
//Ingvar
[1] I'd even go as far as to say "for free", but...
--
A routing decision is made at every routing point, making local hacks
hard to permeate the network with.
From: Lars Brinkhoff
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <858yp7jyoz.fsf@junk.nocrew.org>
Ingvar Mattsson <······@cathouse.bofh.se> writes:
> You seem to miss the point that the return value is embedded
> verbatim in the function definition in function FOO.
To illustrate this point:
> (defvar something (cons 1 2))
SOMETHING
> (defvar p `(defun foo () ',something))
P
> (pprint p)
(DEFUN FOO () '(1 . 2))
> (second (fourth p))
(1 . 2)
> (eval p)
FOO
> (eq (foo) (foo))
T
> (eq (foo) (second (fourth p)))
T
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Ingvar Mattsson wrote:
> > > So, barring function re-definitions, (eq (foo) (foo)) should always
> > > be true.
> >
> > And again, my question is how is that related to that magical fact
> > that in Scheme the evaluator or the semantics use strings.
>
> If teh semantics of the language is defined on lists, the above
> example *cannot* return non-EQ lists, since teh function has teh
> actual return value embedded in itself, verbatim.
Afaict, this has very little to do with whether the semantics of the
language is defined on lists. The issue in this example is the semantics of
'quote'. If 'quote' returns a reference to the actual value embedded in the
program code, then certainly, that value needs to be of the correct type, in
this case, a list.
However, a language with semantics defined on lists could have quote
semantics in which the quoted value is treated as an instruction to generate
a corresponding "instantiated" value. In such a language, even though it's
semantics are defined on lists, the function in question *can* return non-EQ
lists.
IOW, for the example to be "forced" to return true, in addition to
"semantics are defined on lists" it must be further assumed that "quote
returns a reference to a value embedded in the program code".
So it's the semantics of quote that determine whether the language needs to
be defined on lists, in order to have the desired EQ behavior in this case.
It really has little to do with whether the language is defined on lists
(internally) - ultimately, that's simply an implementation convenience that
should be irrelevant to the language user.
Corrections welcome.
Anton
From: ··········@YahooGroups.Com
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <REM-2003sep17-015@Yahoo.Com>
{{Date: Tue, 02 Sep 2003 12:19:14 GMT
From: "Anton van Straaten" <·····@appsolutions.com>
in addition to "semantics are defined on lists" it must be further
assumed that "quote returns a reference to a value embedded in the
program code".}}
Yes, I agree. Another way of putting it is:
If there's a pointy structure in memory, which is a valid program
fragment, CL defines how EVAL would process this program fragment,
including the return value. If inside that program fragment there's a
snippet which EVAL would receive recursively (i.e. this program
fragment would actually be EVALed inside the larger whole-fragment
evaluation), and if the CAR of this snippet is QUOTE, then the return
value from EVALing that snippet is exactly the CADR of that snippet.
Now let's assume this CADR of snippet is actually part of the pointy
structure that is returned by the whole program fragment: We can now
conclude that CADR of snippet must be shared EQ structure between the
snippet in that program fragment and the return value. Furthermore,
since the compiler is required to maintain the semantics of EVAL, that
same CADR of snippet must be shared EQ structure between the original
source fragment and the compilation thereof. If all pointers to the
program fragment are discarded, but the compilation thereof is kept,
and a GC happens, most of that program fragment may be reclaimed, but
that CADR of snippet must be kept, and it's EQ to part of the return
value from that compiled program fragment.
Now if we compile from a file to a file, for a brief moment both the
source pointy structure and compilation of it reside in memory and
share that same CADR-of-snippet structure. So whatever is written to
the compiled file must contain a representation of that same
CADR-of-snippet, and when the compiled file is later read back in a
copy of that same CADR-of-snippet must be built and must be linked from
the compiled fragment. So when that compiled fragment is executed, the
return value shares structure with that little part of the compiled
fragment, so when the compiled fragment is executed multiple times the
return values must all share that same EQ structure.
Apparently, from what I read in this thread, none of this
structure-sharing EQ stuff is required by the Scheme spec, not when
just EVALed, not when compiled in RAM, and not when compiled via a file
to a file then loaded in.
I like Kent's quote, elsewhere in this thread, that Scheme as defined
by the spec doesn't respect the identity of objects.
CL makes it clear that numbers and characters are the only kinds of
objects where object identity isn't respected.
··········@YahooGroups.Com wrote:
> {{Date: Tue, 02 Sep 2003 12:19:14 GMT
> From: "Anton van Straaten" <·····@appsolutions.com>
> in addition to "semantics are defined on lists" it must be further
> assumed that "quote returns a reference to a value embedded in the
> program code".}}
>
> Yes, I agree. Another way of putting it is:
> If there's a pointy structure in memory, which is a valid program
> fragment, CL defines how EVAL would process this program fragment,
> including the return value. If inside that program fragment there's a
> snippet which EVAL would receive recursively (i.e. this program
> fragment would actually be EVALed inside the larger whole-fragment
> evaluation), and if the CAR of this snippet is QUOTE, then the return
> value from EVALing that snippet is exactly the CADR of that snippet.
> Now let's assume this CADR of snippet is actually part of the pointy
> structure that is returned by the whole program fragment: We can now
> conclude that CADR of snippet must be shared EQ structure between the
> snippet in that program fragment and the return value. Furthermore,
> since the compiler is required to maintain the semantics of EVAL, that
> same CADR of snippet must be shared EQ structure between the original
> source fragment and the compilation thereof. If all pointers to the
> program fragment are discarded, but the compilation thereof is kept,
> and a GC happens, most of that program fragment may be reclaimed, but
> that CADR of snippet must be kept, and it's EQ to part of the return
> value from that compiled program fragment.
>
> Now if we compile from a file to a file, for a brief moment both the
> source pointy structure and compilation of it reside in memory and
> share that same CADR-of-snippet structure. So whatever is written to
> the compiled file must contain a representation of that same
> CADR-of-snippet, and when the compiled file is later read back in a
> copy of that same CADR-of-snippet must be built and must be linked from
> the compiled fragment. So when that compiled fragment is executed, the
> return value shares structure with that little part of the compiled
> fragment, so when the compiled fragment is executed multiple times the
> return values must all share that same EQ structure.
The way I stated it was specification-oriented, or at least intended as
such. You've translated it into, in effect, a possible implementation. It
may be the implementation that some, many or all CL's use, but it's possible
to specify this same behavior without requiring the implementation you
describe.
The Scheme spec takes the approach of describing a specification, rather
than one possible implementation strategy which results in the desired
specification. The spec is intended to support a variety of compilation
strategies and other language implementation decisions. If you wanted to
implement a Scheme as described above, you could do so and it would still be
standard-compliant. But if you wanted to implement a beta-reducing Scheme
which substitutes expressions whenever it can, which can have consequences
for the identity of literal objects in source code, you can do that too.
> I like Kent's quote, elsewhere in this thread, that Scheme as
> defined by the spec doesn't respect the identity of objects.
>
> CL makes it clear that numbers and characters are the only
> kinds of objects where object identity isn't respected.
The Scheme spec makes it quite clear that object identity is respected.
This can be seen in e.g. the definition of EQV?, which is defined to return
true for "pairs, vectors, or strings that denote the same locations in the
store [...or...] procedures whose location tags are equal".
What the Scheme spec doesn't do is guarantee that a literal object will be
assigned an identity based on the location in which it appears in a
program's source code. If you wish to give such an object a guaranteed
fixed identity, you have to take explicit steps to do so. For example,
Erann Gat's example:
(defun foo () '(1 2 3))
(eq (foo) (foo))
...could be implemented in Scheme as:
(define foo (let ((x '(1 2 3))) (lambda () x)))
(eq? (foo) (foo)) ; => #t (guaranteed by R5RS)
Anton
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <znhnw81t.fsf@comcast.net>
Ingvar Mattsson <······@cathouse.bofh.se> writes:
> If the semantics of the language is defined on lists, the above
> example *cannot* return non-EQ lists, since the function has the
> actual return value embedded in itself, verbatim.
>
> If, say, it uses a completely different internal representation and
> creates the return value from scratch (since there is no embedded list
> to return verbatim), we can't really expect the return values to be EQ.
The `quote' example is a red herring.
The only implementation of Scheme that I know of where
(define foo (lambda () (quote (1 2 3))))
(eq? (foo) (foo)) => #F
is Stalin. Stalin in fact uses READ and *does* represent it's
programs as list structure. However, Stalin does aggressive inlining,
so the compiler substitutes the lambda expression into all of the
places where it is invoked. This changes the expression to
(eq? ((lambda () (quote (1 2 3)))) ((lambda () (quote (1 2 3)))))
When this inlining occurs, the list structure of the source code is
deep-copied. So now there are two non-eq copies of the literal
list (1 2 3). This is further simplified into:
(eq? (quote (1 2 3)) (quote (1 2 3)))
which is trivially false if the lists are not shared.
This has nothing to do with whether the code was represented by lists
(because it is), but rather with whether the compiler is allowed to
`split' literal constants in the code. I'd argue that this particular
optimization is unusual and surprising, and it seems like a bad idea
(but perhaps there is some good reason to do the deep-copy), but this
example clearly proves that one *can* represent the language on list
structure, yet not return #T.
In article <············@comcast.net>, ·············@comcast.net wrote:
> Ingvar Mattsson <······@cathouse.bofh.se> writes:
>
>
> > If the semantics of the language is defined on lists, the above
> > example *cannot* return non-EQ lists, since the function has the
> > actual return value embedded in itself, verbatim.
> >
> > If, say, it uses a completely different internal representation and
> > creates the return value from scratch (since there is no embedded list
> > to return verbatim), we can't really expect the return values to be EQ.
>
> The `quote' example is a red herring.
No, it's not. You are attacking yet another straw man:
> This has nothing to do with whether the code was represented by lists
> (because it is)
What is at issue is not whether code is or is not represented by lists in
any particular implementation of Scheme. No one disputes that the vast
majority of Schemes (perhaps even all of them) represent code as lists.
What is at issue is whether the semantics of Scheme are defined on lists,
and more particularly, whether those semantics are defined on the specific
lists that correspond to the results of running the text of the source
code of a program through the READ function.
The short version of the argument is that if Scheme's semantics were so
defined then (eq (foo) (foo)) would be required to return #T, but it
isn't, so they aren't.
What is (mostly) a red herring is whether any Scheme implementations
actually exist for which (eq (foo) (foo)) is #F. The argument would be
equally valid either way, but fortunately there are Scheme implementations
for which (eq (foo) (foo)) is #F so at least we don't have to argue about
whether this situation ever actually occurs in practice. Clearly it
does. But that is the full extent to which the details of an
implementation are relevant.
What makes Scheme's semantics defined on strings rather than lists has
nothing to do with any Scheme implementation, it has to do with the way
the Scheme standard is written. It could be the case that all
implementations of C actually used an internal representation of code as
lists, but that would not change the fact that the semantics of C are
defined on strings, not lists. Likewise, the mere fact that all Scheme
implementations have an internal representation of code as lists does not
change the fact that the semantic of Scheme are defined on strings, just
as the semantics of C are. That the syntax of Scheme code happens to be a
subset of the syntax for Scheme data does not change the fact that the
semantics of code are defined on the string representations, not the
corresponding data structures. The Scheme standard goes to great lengths
to keep these separate.
The semantics of Lisp, by contrast, are defined on FORMS (of which lists
are a subset). Lisp is agnostic about how forms are created. They are
usually created by running text through the READ function, but they need
not be. This makes it possible to do thing like write programs with
elements that do not have readable (or even printable) representations.
That is not possible in Scheme. Whether this is a feature or a bug is
arguable. The point (and the only point I am trying to make) is: it's
different.
E.
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <r82zvyon.fsf@comcast.net>
···@jpl.nasa.gov (Erann Gat) writes:
> The short version of the argument is that if Scheme's semantics were so
> defined then (eq (foo) (foo)) would be required to return #T, but it
> isn't, so they aren't.
This is the crux of the matter. I simply do not see how it follows
that (eq (foo) (foo)) => t is a necessary consequence of representing
a program as list structure.
Given this situation:
(defun foo () (quote '(a b c)))
(defun bar () (quote '(a b c)))
is it a necassary consequence that (eq (foo) (bar)) be false?
In article <············@comcast.net>, ·············@comcast.net wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > The short version of the argument is that if Scheme's semantics were so
> > defined then (eq (foo) (foo)) would be required to return #T, but it
> > isn't, so they aren't.
>
> This is the crux of the matter. I simply do not see how it follows
> that (eq (foo) (foo)) => t is a necessary consequence of representing
> a program as list structure.
It isn't. It's a consequence of interpreting the definition of the
semantics of QUOTE on a list structure.
Let me try to distill the argument down to its logical essentials. My
claim is that there is no way to reconcile the following three things:
1. The result of evaluating (QUOTE X) is X.
2. The preceding sentence describes a property of a list, specifically a
list of two elements whose first element is the symbol QUOTE and the
second element is the unspecified datum X.
3. (eq (foo) (foo)) can be #F
Since 1 is a more or less direct quote from the standard, and 3 seems to
be the consensus of the Scheme community, it follows that 2 must be false.
> Given this situation:
>
> (defun foo () (quote '(a b c)))
> (defun bar () (quote '(a b c)))
>
> is it a necassary consequence that (eq (foo) (bar)) be false?
No, because CL explicitly allows the merging of constant lists.
E.
Erann Gat wrote:
> Let me try to distill the argument down to its logical essentials. My
> claim is that there is no way to reconcile the following three things:
>
> 1. The result of evaluating (QUOTE X) is X.
>
> 2. The preceding sentence describes a property of a list, specifically a
> list of two elements whose first element is the symbol QUOTE and the
> second element is the unspecified datum X.
>
> 3. (eq (foo) (foo)) can be #F
>
> Since 1 is a more or less direct quote from the standard, and 3 seems to
> be the consensus of the Scheme community, it follows that 2 must be false.
Afaict, that's correct. But #2 simply needs to be changed to say "...the
second element is a representation of the unspecified datum X" in order to
reconcile the three statements. That representation could even be a list.
This still doesn't seem to say anything about whether programs are defined
on lists, or about the "consequence of interpreting the definition of the
semantics of QUOTE on a list structure".
I'm not disagreeing that there's a difference in the respective standards,
and it certainly seems to be true that the CL standard requires a result
which the Scheme standard does not, but afaict this still is only indirectly
related to whether programs (or the semantics of QUOTE) are defined as
lists. I see it as primarily a question of what the meaning of the quoted
datum is considered to be.
Anton
Anton van Straaten wrote:
> Erann Gat wrote:
>
>>Let me try to distill the argument down to its logical essentials. My
>>claim is that there is no way to reconcile the following three things:
>>
>>1. The result of evaluating (QUOTE X) is X.
>>
>>2. The preceding sentence describes a property of a list, specifically a
>>list of two elements whose first element is the symbol QUOTE and the
>>second element is the unspecified datum X.
>>
>>3. (eq (foo) (foo)) can be #F
>>
>>Since 1 is a more or less direct quote from the standard, and 3 seems to
>>be the consensus of the Scheme community, it follows that 2 must be false.
>
>
> Afaict, that's correct. But #2 simply needs to be changed to say "...the
> second element is a representation of the unspecified datum X" in order to
> reconcile the three statements. That representation could even be a list.
> This still doesn't seem to say anything about whether programs are defined
> on lists, or about the "consequence of interpreting the definition of the
> semantics of QUOTE on a list structure".
The fact that programs in Common Lisp are required to be lists is only a
sufficient condition for (EQ (FOO) (FOO)) to always be T.
It is not a necessary condition. Other representations could also have
this effect. Maybe this is the core of the misunderstanding.
Common Lispniks can rely on (EQ (FOO) (FOO)) to be T because their
programs are required to have list structure. Schemers can't because the
representation of programs might be totally different. That's all Erann
wants to say I suppose.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
"Pascal Costanza" wrote:
> Anton van Straaten wrote:
> > Afaict, that's correct. But #2 simply needs to be changed to say
"...the
> > second element is a representation of the unspecified datum X" in order
to
> > reconcile the three statements. That representation could even be a
list.
> > This still doesn't seem to say anything about whether programs are
defined
> > on lists, or about the "consequence of interpreting the definition of
the
> > semantics of QUOTE on a list structure".
>
> The fact that programs in Common Lisp are required to be lists is only a
> sufficient condition for (EQ (FOO) (FOO)) to always be T.
I'm trying to point out that it's *not* a sufficient condition. The
appropriate specification for the semantics of QUOTE are also required, and
this seems to be the primary issue.
More generally, the issue may be the meaning of the statement "programs are
required to be lists". It seems that a further assumption may be being
bundled into this statement, which is that "literal data specified in a
program denotes itself". By this I mean that the actual value which occurs
in a program's list representation, is the value which is used at runtime -
i.e. a value with the same identity, if the value is an object with
identity.
This assumption implies that literal data in programs is not considered, for
example, to be an instruction designed to generate the corresponding data at
runtime, which is an alternative way that literal data can be handled in
programs defined on lists.
The self-denoting data feature can be considered a sufficient condition for
(EQ (FOO) (FOO)) to be T. However, defining programs on lists does not
require that data be self-denoting, so defining programs on lists is not
itself a sufficient condition.
> Common Lispniks can rely on (EQ (FOO) (FOO)) to be T because their
> programs are required to have list structure. Schemers can't because the
> representation of programs might be totally different. That's all Erann
> wants to say I suppose.
I would understand Erann's point if he were explicitly including the bit
about programs containing self-denoting data (or something equivalent).
Perhaps he can put this issue in context relative to his point. He's
indirectly talked about it in relation to the Scheme spec and datum which
"evaluates to itself", but without really addressing the connection to the
main point, afaict.
Anton
In article <·····················@newsread1.news.atl.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
> It seems that a further assumption may be being
> bundled into this statement, which is that "literal data specified in a
> program denotes itself".
That's not an assumption, that's the definition of the semantics of QUOTE.
You really need to read "What the Totoise Said to Achilles" by Lewis Carroll.
E.
Erann Gat wrote:
> In article <·····················@newsread1.news.atl.earthlink.net>,
> "Anton van Straaten" <·····@appsolutions.com> wrote:
>
> > It seems that a further assumption may be being
> > bundled into this statement, which is that "literal data specified in a
> > program denotes itself".
>
> That's not an assumption, that's the definition of the semantics of QUOTE.
Presumably you're referring to the semantics of QUOTE in CL specifically.
That's fine, but the point is that the idea that programs are lists is not
really the issue here. Since this point has been gone over more than once,
I'll try to put it in context.
IIUC, what the Scheme spec does is try to say that programs only need to be
lists in situations where its important for that to be the case. If it
succeeds at that, then the fact that programs are not "actually" lists at
all times shouldn't matter - programs are treated as an abstraction. If the
spec fails, and the non-listness of programs results in certain kinds of
behavior peeking through, then it means that the abstraction is not as
encapsulated as it could be.
In this case, the behavior that I think you claim peeks through the
abstraction really doesn't have to do with whether programs are defined as
lists - it has to do with the semantics chosen for QUOTE, by the spec.
Programs as lists may be one way to implement that behavior.
I had the impression that you were saying that since Common Lisp (and many
other Lisps) use that particular implementation of programs as lists (*and*
that the semantics of literal data are defined in a certain way), that
changing these implementation details necessarily results in a change in the
behavior of the language. I don't think that's true - it depends on the
abstract definition of programs, not on their concrete representation. The
fact that there *is* a difference in the behavior of the two languages, I
see as a choice that's independent of the question of whether programs are
lists.
Perhaps you consider this tangential to your main point. However, it seemed
to me that you were conflating issues, and I found it difficult to extract
what you were really saying as a result.
> You really need to read "What the Totoise Said to Achilles" by Lewis
Carroll.
I don't think that's justified. I think you're frustrated by a lack of
communication, but you shouldn't be too quick to assume it's all someone
else's fault.
Anton
In article <·····················@newsread2.news.atl.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
> I had the impression that you were saying that since Common Lisp (and many
> other Lisps) use that particular implementation of programs as lists (*and*
> that the semantics of literal data are defined in a certain way), that
> changing these implementation details necessarily results in a change in the
> behavior of the language.
No, that is not what I said. I have made no reference to implementations
except to show that (eq? (foo) (foo)) --> #F does in fact arise in
practice in some Schemes, and that it's not a purely academic concern.
Beyond that I have not said anything about implementations. I have been
talking about how the semantics of the language are defined.
> I don't think that's true
And you're right, it isn't true. It's also not what I've been saying.
> - it depends on the
> abstract definition of programs, not on their concrete representation. The
> fact that there *is* a difference in the behavior of the two languages, I
> see as a choice that's independent of the question of whether programs are
> lists.
Sigh. Just when I thought we were making progress you make the same
mistake AGAIN! What is it with you? The issue is not whether "programs
are lists". The issue is whether the SEMANTICS OF PROGRAMS ARE DEFINED ON
LISTS!
> > You really need to read "What the Totoise Said to Achilles" by Lewis
> Carroll.
>
> I don't think that's justified. I think you're frustrated by a lack of
> communication, but you shouldn't be too quick to assume it's all someone
> else's fault.
My basic position is that if a student doesn't get something then it's
usually the teacher's fault. But there comes a point when the number of
iterations of:
Teacher: X
Student: No, Y is wrong.
Teacher: But I didn't say Y, I said X
Student: No, Y is wrong.
exceeds a certain threshold and it starts to be the student's fault. In
our case, X = "Scheme's semantics are defined on text" and Y = "Scheme
programs in practice are not lists" or something like that.
We now have a new instantiation of this pattern with X = "You should read
Carroll" and Y = "It's all Anton's fault." Ironically, by challenging
this particular straw man that you have set up you will actually cause it
to be true.
E.
Erann Gat wrote:
> Sigh. Just when I thought we were making progress you make the same
> mistake AGAIN! What is it with you?
I made similar points in more than one post, but you didn't respond to any
of them directly until today. Perhaps you're confusing me with one of the
others participants in this thread, or perhaps you're seeing propagation
delay.
> The issue is not whether "programs are lists". The issue is whether
> the SEMANTICS OF PROGRAMS ARE DEFINED ON LISTS!
I foolishly used shorthand to summarize your point. I, too, am and have
been talking about the question of "whether the semantics of programs are
defined on lists". If you substitute that phrase wherever I have said
anything about programs being lists, or similar wording, I believe all my
points still stand.
However, I'll resummarize: the fact that the semantics of programs are
defined on lists is *not* a sufficient condition for the CL behavior of (EQ
(FOO) (FOO))=>T. I'm arguing that it's barely even a relevant condition.
In your first message with the current subject line, to take just one
example, you said "It can actually change the semantics of programs. In
particular, it changes the semantics of QUOTE."
Assuming that "it" refers to whether "the semantics of programs are defined
on lists" (you'll have to check the original message to see if I have the
correct context), then the quoted statement is false, in the sense that, as
I've pointed out, it's not whether "the semantics of programs are defined on
lists", but rather what the defined semantics of QUOTE are, and that these
semantics can work either way regardless of whether "the semantics of
programs are defined on lists".
As for Lewis Carroll, if I'm not understanding your point in that respect,
feel free to make it more directly. You didn't do so well with Swift's
eggs, as I recall - perhaps I am similarly analogically challenged.
Anton
On Wed, Sep 03, 2003 at 01:19:45PM +0000, Anton van Straaten wrote:
> I'm trying to point out that it's *not* a sufficient condition. The
> appropriate specification for the semantics of QUOTE are also required, and
> this seems to be the primary issue.
CL:
``quote object => object
object---an object; not evaluated.
The quote special operator just returns object.''
Scheme:
``syntax: quote <datum>
syntax: '<datum>
syntax: <constant>
`(quote <datum>)' evaluates to <datum>. <Datum> may be any external
representation of a Scheme object.''
``An important concept in Scheme (and Lisp) is that of the external
representation of an object as a sequence of characters.[...]
An external representation may be written in a program to obtain the
corresponding object (see quote)''
The essential difference is that in Scheme, quote is defined to operate
on external representations and in CL it operates directly on objects.
I don't see anywhere where it says that the same external representation
(sequence of characters) must result in the same identical object,
though it certainly may result in structurally equivalent objects. But
identity is the point here, and with objects, identity with self holds
trivially. It is also quite clear that the CL definition necessitates a
list structure syntax containing Lisp objects, and that the Scheme
definition is specified on characters in a sequence (which may or may
not be translated into a list structure).
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish wrote:
> The essential difference is that in Scheme, quote is defined to operate
> on external representations and in CL it operates directly on objects.
> I don't see anywhere where it says that the same external representation
> (sequence of characters) must result in the same identical object,
> though it certainly may result in structurally equivalent objects. But
> identity is the point here, and with objects, identity with self holds
> trivially. It is also quite clear that the CL definition necessitates a
> list structure syntax containing Lisp objects, and that the Scheme
> definition is specified on characters in a sequence (which may or may
> not be translated into a list structure).
That's a nice description, which I agree with. In particular, you described
the causal relationship the right way around: "It is also quite clear that
the CL definition necessitates a list structure syntax containing Lisp
objects", not vice versa as Erann seemed (to me) to have been saying. Note
still that the CL *behavior* could be obtained by a different definition.
Anton
In article <·····················@newsread2.news.atl.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
> Matthew Danish wrote:
> > The essential difference is that in Scheme, quote is defined to operate
> > on external representations and in CL it operates directly on objects.
> > I don't see anywhere where it says that the same external representation
> > (sequence of characters) must result in the same identical object,
> > though it certainly may result in structurally equivalent objects. But
> > identity is the point here, and with objects, identity with self holds
> > trivially. It is also quite clear that the CL definition necessitates a
> > list structure syntax containing Lisp objects, and that the Scheme
> > definition is specified on characters in a sequence (which may or may
> > not be translated into a list structure).
>
> That's a nice description, which I agree with. In particular, you described
> the causal relationship the right way around: "It is also quite clear that
> the CL definition necessitates a list structure syntax containing Lisp
> objects", not vice versa as Erann seemed (to me) to have been saying.
Then you have clearly misunderstood what I have been saying (not that this
is news) because what I have been saying is exactly the same thing that
Matthew said (though he apprently said it better than I did).
I'd be interested to know what I said that gave you the impression that I
intended the opposite causality because that was never my intent.
E.
Erann Gat wrote:
> In article <·····················@newsread2.news.atl.earthlink.net>,
> "Anton van Straaten" <·····@appsolutions.com> wrote:
>
> > Matthew Danish wrote:
> > > The essential difference is that in Scheme, quote is defined to
operate
> > > on external representations and in CL it operates directly on objects.
> > > I don't see anywhere where it says that the same external
representation
> > > (sequence of characters) must result in the same identical object,
> > > though it certainly may result in structurally equivalent objects.
But
> > > identity is the point here, and with objects, identity with self holds
> > > trivially. It is also quite clear that the CL definition necessitates
a
> > > list structure syntax containing Lisp objects, and that the Scheme
> > > definition is specified on characters in a sequence (which may or may
> > > not be translated into a list structure).
> >
> > That's a nice description, which I agree with. In particular, you
described
> > the causal relationship the right way around: "It is also quite clear
that
> > the CL definition necessitates a list structure syntax containing Lisp
> > objects", not vice versa as Erann seemed (to me) to have been saying.
>
> Then you have clearly misunderstood what I have been saying (not that this
> is news) because what I have been saying is exactly the same thing that
> Matthew said (though he apprently said it better than I did).
>
> I'd be interested to know what I said that gave you the impression that I
> intended the opposite causality because that was never my intent.
Here are some quotes. I'll start with this one, which most clearly
demonstrates the point I was trying to clarify:
"My opinion (as expressed with no ambiguity at the start of the c.l.s.
thread that started this whole mess)
was that Scheme programs ought to be considered lists. But the necessary
consequence of this is that (eq? (foo) (foo)) must return #T."
This clearly shows the causality in the direction I've been objecting to.
What Matthew said, in contrast, was that the CL *definition* necessitates a
list structure syntax...". One part of that definition is the definition of
QUOTE, and also the way that definition, and others, are worded. I agree
with Matthew's statement because the definition of CL defines the semantics
and behavior in question, and if it doesn't, something must be wrong.
I wanted clarification about your statement *as stated* (numerous times)
because your definition is only a subset of the CL definition - you have
focused on "the semantics of programs being defined on lists", and claimed
necessary consequences of that. This is more or less the inverse of what
Matthew said, which was that "list structure syntax containing Lisp objects"
was a consequence of the CL definition, not that that structure in itself
had the necessary consequence of a specific semantics.
Here are some further quotes. If we have somehow managed to reach greater
mutual understanding at this point and you don't need to read them, or want
to come back to them, please skip down to the row of asterisks below and
read beyond that.
I notice that READ figures prominently in some of the following quotes;
however, this simply seems part of the chain of reasoning you seemed to be
describing, from program semantics defined on lists, through READ, to an
inevitable consequence for your two-line example. It's that inevitable
consequence that I've been disputing, and here are some quotes of yours
which seem to claim that consequence:
"To be more precise, it demonstrates that one cannot reliably apply the
model that a Scheme program is the list produced by running the text of the
program through the READ function once. A Scheme program may be such a
list, but you can't count on it. If you could you could count on (eq (foo)
(foo)) returning #T, but you can't, so you can't."
Applying my point to the above: being able to count on, or reliably apply,
"the model that a Scheme program is the list produced by running the text of
the program through the READ function once", does *not* imply that you can
count on (eq (foo) (foo)) returning #T. A further condition is required, as
already discussed.
Similar wording from the same message:
"Many Scheme interpreters will parse the code using READ, but you can't
count on it. This has other important consequences besides the different
semantics of QUOTE."
Again, the semantics of QUOTE are not a consequence of the code being parsed
using READ, or the semantics of programs being defined on lists.
Here's another:
Erann> Eli> -- all you need is
Erann> Eli> an example of a program that would break if its semantics is
Erann> Eli> defined on strings. Your example doesn't seem to do this.
Erann>
Erann> No, that is faulty logic. What I need is an example of a program
Erann> that would break if Scheme's semantics were defined on lists.
Erann> I have provided such an example, and therefore proven that
Erann> Scheme's semantics are not defined on lists.
Scheme's semantics could be "defined on lists" without breaking your
example. Your example does not prove that "Scheme's semantics are not
defined on lists"; all it proves is that the semantics of Scheme's QUOTE is
defined to behave the way it is defined to behave.
Erann> Joe> The *only* difference between the two is this:
Erann> Joe>
Erann> Joe> 1. Common Lisp programs are read by the Common Lisp
Erann> Joe> READ function.
Erann> Joe>
Erann> Joe> 2. Scheme programs need not be read by the Scheme
Erann> Joe> READ function.
Erann> Joe>
Erann> Joe> This is `a difference that makes no difference' because the
macro
Erann> Joe> system in Scheme requires exactly the same sort of lists that
the READ
Erann> Joe> function would have produced.
Erann>
Erann> I disagree. This is a difference that makes an enormous difference.
Erann> It can actually change the semantics of programs. In particular, it
Erann> changes the semantics of QUOTE.
Once again, the described issue doesn't change the semantics of QUOTE. The
definition of the semantics of QUOTE defines the semantics of QUOTE,
regardless of how a program is read or whether a program's semantics is
defined on lists. But I'm repeating myself too much. I'll wrap up with
this next one:
Erann> Eli> Does the fact that it is not directly defined on sexps has
Erann> Eli> any effect on my programs?
Erann>
Erann> For the thousandth time, yes.
Here, my response is that it doesn't have to have any effect on your
programs, even if it does in Scheme's case. As I've mentioned elsewhere, I
know that this is tangential to your main point, but I nevertheless feel it
has been one of the points leading to confusion, and wanted to clarify it.
* * * End of quote marathon * * *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
As I have already said, I think that in the above cases, whenever you talked
about semantics being defined on lists, you actually meant something
further, most likely quite consciously. I think you may have hinted at it
here (last quote!) :
"What is at issue is whether the semantics of Scheme are defined on lists,
and more particularly, whether those semantics are defined on the specific
lists that correspond to the results of running the text of the source code
of a program through the READ function."
My point is a tricky one to make in natural language, but when you talk
about the "specific lists that...", I think you may be getting at my point.
But what I'm getting at is that even if the "semantics are defined on the
specific lists that correspond to the results of running the text of the
source code of a program through the READ function", it is *still* not a
necessary consequence that in your example, (eq (foo) (foo)) return T.
The semantics could be defined on the lists exactly as you describe, but the
semantics of QUOTE could still be defined to use a quoted object (like a
list) as a program instruction, used to generate a value 'EQUAL' to the
quoted object, but not necessarily an 'EQ' value.
The fact that Scheme's semantics differ from CL's in this respect is not a
consequence of the semantics of programs being defined on lists. The same
semantics could be achieved by different means. The differences relate to a
set of choices in the respective languages which may be related, but do not
necessarily form a direct chain of consequences.
Note that I understand that you originally wished to point out what you see
as some big differences between CL and Scheme. I'm certainly not denying
the difference or trying to minimize it. The reason I thought it important
to try to clarify the point I was making, or better understand how it
related to what you were saying, is that the CL/Scheme difference may seem
even bigger than it really is, if it is understood as a causal chain in
which a difference in some core decision has led to unavoidable ripple
effects. However, I don't believe that's an accurate characterization of
the nature of the difference.
Anton
In article <···················@newsread2.news.atl.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
> The fact that Scheme's semantics differ from CL's in this respect is not a
> consequence of the semantics of programs being defined on lists.
OK, I think I understand now why you believe this, but I still think
you're wrong. (Actually, I know you're wrong.)
Let me tell you a story.
When I was a graduate student I did my master's thesis on something called
"the problem of referential transparency". It has to do with avoiding
unwanted conclusions in AI systems based on formal logic. The classic
example is, "Mary knows Bill's phone number" and "Bill's phone number is
the same as John's phone number." From this one does not want to conclude
that Mary knows John's phone number, but under standard formal logic this
conclusion is unavoidable if one models these two statements as:
knows(Mary, phone-of(Bill))
phone-of(Bill) = phone-of(John)
This problem has for unfathomable reasons attracted the attention of
philosophers for a hundred years. Bertrand Russel came up with what I
consider to be the definitive solution, and I wrote my master's thesis on
essentially that solution, and how to implement it in Lisp. Being a good
academic at the time I dressed it up with a lot of fancy Greek symbols and
math, and talked a lot about Goedelization of first order formulae and
whatnot.
After I finished I had occasion to be on the left coast and on a whim
dropped in on John McCarthy at the Stanford CS department. He of course
had no idea who I was but still graciously agreed to meet with me. I
started to tell him about my thesis work, and I had just gotten to the
part about Goedel numbers when he stopped me and said something like,
"Yeah, that will work, but you really don't need all that hair. All you
need is quote."
That really floored me, because he was, of course, right. In five minutes
he had pretty much reduced 90% of my master's thesis down to a single
sentence.
The reason he was able to do that is that quotation is not an esoteric
concept, it's a very simple and straightforward concept. The semantics of
quote are that (quote X) returns X. Period, end of story.
The hairy end of the business is not what quote means, but rather what it
means to "return X". Does it mean X *itself*, or merely something that
looks like X? If John's phone number is the same as Bill's phone number,
are they really *the same thing*, or are they *two different things that
just happen to look the same*? (This is just rehashing the point that
Kent made about respecting identity.)
When CL says quote "returns X" it means that it returns X *itself*. When
Scheme says quote "returns X" it means that it returns something that just
happens to look like X. But the *reason* that Scheme says this is not
because it makes conscious choice of these semantics over other semantics,
it is because the object X *does not exist as a concept* in the extant
presentation of Scheme's semantics. Scheme programs are strings of
characters, not because (eq? (foo) (foo)) can return #F, but because
that's just what the Scheme standard says they are.
Look at section 1.3.4:
---
The symbol "=>" used in program examples should be read "evaluates to."
For example,
(* 5 8) ==> 40
means that the expression (* 5 8) evaluates to the object 40 . Or, more
precisely: the expression given by the sequence of characters " (* 5 8) "
evaluates, in the initial environment, to an object that may be
represented externally by the sequence of characters " 40 ".
---
Note the reference to "the expression given BY THE SEQUENCE OF
CHARACTERS". Scheme expressions are sequences of characters, not lists.
They are so not because (eq (foo) (foo)) can return #F, but because the
Scheme standard says so.
A consequence of this is that it is not possible in Scheme to give QUOTE
the "same-object" semantics that it has in Common Lisp because (and this
is the crux of the matter) THERE IS NO OBJECT FOR THE RESULT OF QUOTE TO
BE "THE SAME AS". X isn't an object, it's just a sequence of characters.
So the best you can do is return an object, some object, that is denoted
by that sequence of characters.
That is why the semantics of QUOTE in Scheme are:
"`(quote <datum>)' evaluates to <datum>. <Datum> may be any EXTERNAL
REPRESENTATION of a Scheme object." (Emphasis added.)
This is not a choice among the two possible interpretations of the
semantics of QUOTE, it is the only possible interpretation in a language
where "(QUOTE <datum>)" denotes a string of characters and not a list with
two elements.
So yes, it is possible to implement Schemes where programs are lists, and
in most Schemes programs are lists, but the Scheme standard goes to great
lengths - it bends over backwards - not to commit itself to programs being
lists, but rather to emphasize over and over again that programs are, just
like in all other programming languages, just strings of characters,
nothing more.
The (eq (foo) (foo)) example only serves to demonstrate that this design
decision does in fact have practical consequences despite the fact that
the syntax for Scheme code is a sub-language of the syntax for Scheme
data. Other than that it is, as someone else said earlier, a red herring.
E.
[This is going to be verbose, but I think that I managed to get a good
conclusion out of the whole story.]
···@jpl.nasa.gov (Erann Gat) writes:
> [...]
> After I finished I had occasion to be on the left coast and on a
> whim dropped in on John McCarthy at the Stanford CS department. He
> of course had no idea who I was but still graciously agreed to meet
> with me. I started to tell him about my thesis work, and I had just
> gotten to the part about Goedel numbers when he stopped me and said
> something like, "Yeah, that will work, but you really don't need all
> that hair. All you need is quote."
> [...]
This is the main point that allowed a different treatment of syntactic
reflection when computer programs are involved. As I said, this is
part of what I say in my own work, which involves doing a similar
trick in a theorem prover. The thing in my particular setting, is
that there is no way to have "proper quotation", where that term is
defined as a way of representing syntax by including the syntax
itself. (BTW, this is the only form of available quotation in natural
language -- Lisp adds quasi-quotes, which are a nice and simple
solution to many "ugly hacks" done by philosophers in the past (for
example, Quine used greek characters for `unquoted' meta-variables).)
Anyway, as I said, in my work there is no way to get a quoting
context, so I use a different trick that allows me to expose the
internal term representation (meta-level structures -- in Lisp that
would be the syntax objects as the compiler sees them) to the user
(object-level code -- in Lisp these are cons cells). The result of
that exposure in Lisp is that the compiler and the user share the
exact same data structure. The result of that is a much better syntax
reflection than the one that is traditionally used in logic, where any
actual implementation is secondary, so Godel numbers are "just as
good" as anything else, in contrast to programming languages where it
is clear that Godel numbers are terrible representations. I think
that this basic idea that comes from CS is what made McCarthy's remark
very obvious (and the fact that it floored and that it reduced 90% of
your work is a good indication that you were reading a lot of logic,
where this concept of exposing stuff is pretty much nonexistent).
(BTW, doing this trick formally is a lot harder than a single
sentence.)
Anyway, to get back at the current issue -- Common Lisp is designed as
a major restriction on implementations so they all implement a very
close language. As it was said over and over, Scheme, in addition to
being a different dialect of Lisp, is serving an academic crowd, so I
believe that a major guideline was not to restrict implementations too
much, which is consistent with the way things were decided and with
trying to keep the standard at the necessary minimal size -- not for
showing off how great it is that it is so small, but for allowing
different dialects of Scheme to co-exist (and I think that Scheme is
much more of a "language-family" definition than CL, which is a
popular reason for CLers to dismiss Scheme as impractical, where many
Schemers realize that the standard is most impractical and the
particular implementation they work in is what defines their actual
language, libraries etc etc).
One consequence of this approach (IMO) is not comitting on any
specific code representation -- it would be better if it allows
implementations to do whatever they want to represent code. This is
related to the side effect of having a bigger report if that
restriction is included, because the language is more restricted. Any
kind of a meta-level exposure to object-level will inherently lead to
mixing implementation-details and formal-semantics -- since that
exposure basically injects implementation values to user-land. The CL
solution to this is obvious -- there is one implementation technique
which is natural, popular among all existing Lisps, and unanimously
popular, so that was made part of the language. Now, I completely
agree with:
> [...] the Scheme standard goes to great lengths - it bends over
> backwards - not to commit itself to programs being lists,
but I believe that this:
> but rather to emphasize over and over again that programs are, just
> like in all other programming languages, just strings of characters,
> nothing more.
is incorrect. The thing is that if you follow the report, you have to
implement a language using any representation you want (which is what
"character strings" are used) like other languages, but what is *not*
like other languages is exactly the property that the syntax itself is
exposed to user-code. So Scheme implementation are not restricted by
a particular code representation, but they *are* restricted in that
whatever syntax representation they do use, it should be available as
user-accessible structures too. As an example of a very different
language that has this feature, take OCaml with CamlP4 -- CamplP4 (the
compiler component that does the parsing) has some complicated data
structures for representing code (very complicated, due to the strict
typing), and they allow you to write something like this:
let foo = <:expr< 1 + 2 >>
in ...
and that "<<...>>" thing will get expanded to some hairy looking big
expression involving things that looks roughly like:
ExApp(...,ExApp(...,ExLid(...,"+"),ExInt(...,"1")),ExInt(...,"2"))
(where "..." are actually some location information). Now, if you
ignore the verbosity, the fact that these are constructors for values
that are used by both implementation code and user code is exactly the
feature that R5RS requires, and other languages completely ignore.
The same one that is "more required" by CL -- "more" because it goes
further to specify the representation.
Now in other places in R5RS that were mentioned elsewhere in this
thread, there are indications that the syntax representation should be
equivalent to lists (using "external representation" in the
definition, where lists happen to have the same external
representation is also a thick hint). This is why I say that the fact
that the definition of syntax on "strings" has no practical effect.
Those other bits ensure that whatever the representation is, I can
pretend it's sexps and everything will be fine.
---but---
But all of this is still unrelated to any result of the (eq (foo)
(foo)) example, since that could easily be added to R5RS as is. The
simple way to do that would be to say that whatever is the
representation of the syntax inside the quote, it is the exact same
one that is returned on every evaluation of the quote form. I believe
that this would be a simple addition, and the whole "unspecified
representation" thing wouldn't make it harder to say. I think that
Kent was right in nailing this on the issue of identity -- adding that
bit would mean that code representation should have *an identity* and
that this identity can be shared between the implementation and user
code, but this is a *different* restriction (arguably, one that is
less important than the syntax exposure property). The only thing
that the foo example shows is that in Scheme quote can be implemented
like CL's backquote, with no identity commitment.
(BTW, in my reflection implementation there is no quote at all, yet it
has a very formal restriction similar to Scheme code as lists. And
that would be true even if there was a quote -- since there is no
`eq?' identity.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
<···@barzilay.org> wrote:
> [This is going to be verbose
Then you missed the whole point of my story, which was that what I'm
talking about is a very simple, intuitive concept, and if you find
yourself getting verbose about it then you've missed the point.
> Now, I completely agree with:
>
> > [...] the Scheme standard goes to great lengths - it bends over
> > backwards - not to commit itself to programs being lists,
>
> but I believe that this:
>
> > but rather to emphasize over and over again that programs are, just
> > like in all other programming languages, just strings of characters,
> > nothing more.
>
> is incorrect.
What else is there?
> So Scheme implementation are not restricted by
> a particular code representation, but they *are* restricted in that
> whatever syntax representation they do use, it should be available as
> user-accessible structures too.
No, they are restricted in that the character strings that are parsable as
programs must also be parseable as data by the READ function. But this is
nothing more than a requirement that a parser for the language be included
as part of the standard library. That is not enough in some people's
minds to make Scheme a Lisp. If it were, then adding a C parser (and
maybe the Boehm GC) to the C standard library would make C a Lisp. And
maybe it even *would* make C a Lisp, but you probably would not get a
consensus on that (I refer you again to the title of this thread).
> But all of this is still unrelated to any result of the (eq (foo)
> (foo)) example, since that could easily be added to R5RS as is.
No, it couldn't, at least not without also requiring:
(eq '(1 2 3) '(1 2 3)) --> #T
(Note: CL permits this, but does not require it.)
> (BTW, in my reflection implementation there is no quote at all, yet it
> has a very formal restriction similar to Scheme code as lists. And
> that would be true even if there was a quote -- since there is no
> `eq?' identity.)
Ah, now I see the motivation behind this discussion, and why you are
defending your position so passionately. So I should tell you a followup
to the story I told you earlier: Despite the fact that McCarthy in five
minutes managed to render a year's worth of work into a single sentence, I
still went on to have a pretty successful career. ;-) So don't worry.
Things will be OK. :-)
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> <···@barzilay.org> wrote:
>
> > [This is going to be verbose
>
> Then you missed the whole point of my story, which was that what I'm
> talking about is a very simple, intuitive concept, and if you find
> yourself getting verbose about it then you've missed the point.
Quite the other way.
> > So Scheme implementation are not restricted by a particular code
> > representation, but they *are* restricted in that whatever syntax
> > representation they do use, it should be available as
> > user-accessible structures too.
>
> No, they are restricted in that the character strings that are
> parsable as programs must also be parseable as data by the READ
> function.
You completely didn't read my post, or you completely ignored its
contents, or you're completely fixated on pretending one of these.
Let me summarise your reply, and answer appropriately:
> No
Yes
> > But all of this is still unrelated to any result of the (eq (foo)
> > (foo)) example, since that could easily be added to R5RS as is.
>
> No, it couldn't, at least not without also requiring:
>
> (eq '(1 2 3) '(1 2 3)) --> #T
>
> (Note: CL permits this, but does not require it.)
I was talking about exactly such an extension -- giving code
*identity* would do it without requiring the above.
> > (BTW, in my reflection implementation there is no quote at all,
> > yet it has a very formal restriction similar to Scheme code as
> > lists. And that would be true even if there was a quote -- since
> > there is no `eq?' identity.)
>
> Ah, now I see the motivation behind this discussion, and why you are
> defending your position so passionately.
This is unrelated to my motivation, only to the fact that I have spent
more than enough time thinking about it.
> So I should tell you a followup to the story I told you earlier:
> Despite the fact that McCarthy in five minutes managed to render a
> year's worth of work into a single sentence, I still went on to have
> a pretty successful career. ;-) So don't worry. Things will be OK.
> :-)
I really don't worry -- I know what work I did and there is no way to
reduce it to a single sentence, and I know that things will be ok.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
<···@barzilay.org> wrote:
> You completely didn't read my post, or you completely ignored its
> contents, or you're completely fixated on pretending one of these.
Actually, I think what happened is that I'm getting you confused with
Anton van Straaten. Let me go back and see if I can reconstruct what
happened. May take a while. Today is turning out to be very busy.
E.
I have now carefully re-read your orignal post, and my original response
(which was based on a too-hasty reading), and I stand by most of what I
originally wrote.
In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
<···@barzilay.org> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> > <···@barzilay.org> wrote:
> >
> > > [This is going to be verbose
> >
> > Then you missed the whole point of my story, which was that what I'm
> > talking about is a very simple, intuitive concept, and if you find
> > yourself getting verbose about it then you've missed the point.
>
> Quite the other way.
On careful re-reading I really do think you missed the point that I was
trying to make.
> > > So Scheme implementation are not restricted by a particular code
> > > representation, but they *are* restricted in that whatever syntax
> > > representation they do use, it should be available as
> > > user-accessible structures too.
> >
> > No, they are restricted in that the character strings that are
> > parsable as programs must also be parseable as data by the READ
> > function.
>
> You completely didn't read my post, or you completely ignored its
> contents, or you're completely fixated on pretending one of these.
> Let me summarise your reply, and answer appropriately:
>
> > No
>
> Yes
No. :-)
Your claim was:
"Scheme implementation are not restricted by a particular code
representation, but they *are* restricted in that whatever syntax
representation they do use, it should be available as user-accessible
structures too."
That is wrong.
Scheme code is required to be parseable by READ, and the result is
required to be a list.
By contrast, there is no constraint placed on how that code is represented
when it is treated as code. It might be a list, or it might not be.
Scheme specifically makes no commitment here.
So what you wrote is exactly wrong. Scheme implementations *are*
restricted to a particular code representation - it must be textual so
that it can be parsed by READ - and they are specifically NOT required to
make any underlying representation of that code available to the user
EXCEPT through the macro mechanism, which presents an abstraction that is
isomorphic to lists, which generally are lists, but which are deliberately
NOT required to actually BE lists, and (and this is the main point) which
are NOT required to be manipulable using the Scheme functions that
manipulate lists.
> > > But all of this is still unrelated to any result of the (eq (foo)
> > > (foo)) example, since that could easily be added to R5RS as is.
> >
> > No, it couldn't, at least not without also requiring:
> >
> > (eq '(1 2 3) '(1 2 3)) --> #T
> >
> > (Note: CL permits this, but does not require it.)
>
> I was talking about exactly such an extension -- giving code
> *identity* would do it without requiring the above.
Yes, and what I'm saying is that it would be very hard to change the
Scheme standard to do this.
But the main point, the one that you missed, is that this is not a
complicated issue. It's a simple issue: there's an essential difference
between Scheme and Lisp. You can characterise that difference in
different ways. I characterize it as, "Scheme semantics are defined on
text." Kent characterises it as, "CL code has identity (necessarily);
Scheme code doesn't (or at least isn't required to)." That difference is
mostly academic, but it does have some practical consequences. And some
people consider the CL binding of this property to be essential to
Lisp-ness, and that is why some people consider Scheme to not "be a Lisp"
despite the fact it calls itself a Lisp and appears for all intents and
purposes to be a Lisp.
E.
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <3cfb83ij.fsf@comcast.net>
···@jpl.nasa.gov (Erann Gat) writes:
> I have now carefully re-read your orignal post, and my original response
> (which was based on a too-hasty reading), and I stand by most of what I
> originally wrote.
>
> In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> <···@barzilay.org> wrote:
>
>> ···@jpl.nasa.gov (Erann Gat) writes:
>>
>> > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
>> > <···@barzilay.org> wrote:
>
>> > > But all of this is still unrelated to any result of the (eq (foo)
>> > > (foo)) example, since that could easily be added to R5RS as is.
>> >
>> > No, it couldn't, at least not without also requiring:
>> >
>> > (eq '(1 2 3) '(1 2 3)) --> #T
>> >
>> > (Note: CL permits this, but does not require it.)
>>
>> I was talking about exactly such an extension -- giving code
>> *identity* would do it without requiring the above.
>
> Yes, and what I'm saying is that it would be very hard to change the
> Scheme standard to do this.
Political issues of changing the standard aside (which I consider
to be the main obstacle), it would be not be difficult at all.
1. Amend the description of QUOTE to avoid the unfortunately
confusing text. Something like this:
(QUOTE <datum>) syntax
(QUOTE <datum>) evaluates to <datum>. <datum> may be any scheme
object that has an external representation. To clarify, <datum>
is the object created as a result of parsing an external
representation as if by the READ library procedure.
2. Specify clearly that READ is allowed to coalesce:
READ library procedure
READ converts external representations of Scheme objects into the
objects themselves. That is, it is a parser for the nonterminal
<datum>. It is unspecified whether aggregate objects returned by
READ are unshared, thus it is an error to mutate objects returned
by READ. (An implementation could, for instance, construct
object by `hash-consing' to minimize storage allocation.)
3. Specify clearly that EVAL is allowed to `split':
EVAL is allowed, but not required, to make a copy of its input.
It is an error to mutate objects that have been passed to EVAL.
Note that this implies the following:
(let ((x (list a b c))
(expression (list 'QUOTE x)))
(eq? x (eval expression (r6rs-environment)))) => #t or #f
4. Specify clearly the nature of <datum>:
<datum> is a subset of scheme objects that have external
representations. The grammar of <datum> is therefore
defined as a mapping from a sequence of tokens to Scheme
objects. The READ library procedure implements such
a parser.
5. Specify the difference in the BNF grammars in section 7.1
In section 7.1.1, the grammar is defined as a mapping between
character sequences and tokens.
In section 7.1.2, the grammar is defined as a mapping between
tokens and <datum>.
In section 7.1.3, the grammar is defined as a mapping between
*scheme objects* and expressions. Because scheme objects
cannot be literally placed on the page, the notation uses the
external representation of the object. To be clear: the
elements on the right hand side of the productions are
scheme object themselves, not their external representation.
Thus, for example,
the production:
<procedure call> --> (<operator> <operand>*)
is to be interpreted as a LIST with at least one element,
and that element is distinguished as the <operator> rather
than being interpreted as a token stream beginning and ending
with ( and ) respectively.
I'm pretty sure that something like this would be acceptable to
the RnRS authors.
In article <············@comcast.net>, ·············@comcast.net wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > I have now carefully re-read your orignal post, and my original response
> > (which was based on a too-hasty reading), and I stand by most of what I
> > originally wrote.
> >
> > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> > <···@barzilay.org> wrote:
> >
> >> ···@jpl.nasa.gov (Erann Gat) writes:
> >>
> >> > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
> >> > <···@barzilay.org> wrote:
> >
> >> > > But all of this is still unrelated to any result of the (eq (foo)
> >> > > (foo)) example, since that could easily be added to R5RS as is.
> >> >
> >> > No, it couldn't, at least not without also requiring:
> >> >
> >> > (eq '(1 2 3) '(1 2 3)) --> #T
> >> >
> >> > (Note: CL permits this, but does not require it.)
> >>
> >> I was talking about exactly such an extension -- giving code
> >> *identity* would do it without requiring the above.
> >
> > Yes, and what I'm saying is that it would be very hard to change the
> > Scheme standard to do this.
>
> Political issues of changing the standard aside (which I consider
> to be the main obstacle), it would be not be difficult at all.
Only if you punt on all the hard issues.
> 1. Amend the description of QUOTE to avoid the unfortunately
> confusing text. Something like this:
>
> (QUOTE <datum>) syntax
>
> (QUOTE <datum>) evaluates to <datum>. <datum> may be any scheme
> object that has an external representation. To clarify, <datum>
> is the object created as a result of parsing an external
^^^
> representation as if by the READ library procedure.
The word "the" implies that there is only one such object per representation.
What happens in the following cases (assuming a suitable definition of
read-from-string)?
(set! s "(1 2 3)")
(eq? (read-from-string s) (read-from-string s))
(eq? (read-from-string s) (read-from-string "(1 2 3)"))
(eq? (read-from-string s) (read-from-string (make-string #\( #\1 #\Space
#\2 #\Space #\3 #\) )))
Actually, changing the highlighted word "the" to "an" makes a pretty good
clarification on the current state of things.
> 3. Specify clearly that EVAL is allowed to `split':
>
> EVAL is allowed, but not required, to make a copy of its input.
How deep is EVAL allowed to copy?
> It is an error to mutate objects that have been passed to EVAL.
How deep does this restriction go? i.e. if I do:
(set! x '(1 2 3))
(set! y (list 'display x))
(eval y)
Am I now prohibited from calling set-car! on x?
> I'm pretty sure that something like this would be acceptable to
> the RnRS authors.
I doubt it.
E.
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <smn97h5o.fsf@comcast.net>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <············@comcast.net>, ·············@comcast.net wrote:
>
>> ···@jpl.nasa.gov (Erann Gat) writes:
>>
>> > I have now carefully re-read your orignal post, and my original response
>> > (which was based on a too-hasty reading), and I stand by most of what I
>> > originally wrote.
>> >
>> > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
>> > <···@barzilay.org> wrote:
>> >
>> >> ···@jpl.nasa.gov (Erann Gat) writes:
>> >>
>> >> > In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
>> >> > <···@barzilay.org> wrote:
>> >
>> >> > > But all of this is still unrelated to any result of the (eq (foo)
>> >> > > (foo)) example, since that could easily be added to R5RS as is.
>> >> >
>> >> > No, it couldn't, at least not without also requiring:
>> >> >
>> >> > (eq '(1 2 3) '(1 2 3)) --> #T
>> >> >
>> >> > (Note: CL permits this, but does not require it.)
>> >>
>> >> I was talking about exactly such an extension -- giving code
>> >> *identity* would do it without requiring the above.
>> >
>> > Yes, and what I'm saying is that it would be very hard to change the
>> > Scheme standard to do this.
>>
>> Political issues of changing the standard aside (which I consider
>> to be the main obstacle), it would be not be difficult at all.
>
> Only if you punt on all the hard issues.
>
>> 1. Amend the description of QUOTE to avoid the unfortunately
>> confusing text. Something like this:
>>
>> (QUOTE <datum>) syntax
>>
>> (QUOTE <datum>) evaluates to <datum>. <datum> may be any scheme
>> object that has an external representation. To clarify, <datum>
>> is the object created as a result of parsing an external
> ^^^
>> representation as if by the READ library procedure.
>
> The word "the" implies that there is only one such object per representation.
Yes. I expect that when I invoke READ on the printed representation
of a single object that I only get back one object. (I'm not implying
that it will be the *same* object each and every time.)
> What happens in the following cases (assuming a suitable definition of
> read-from-string)?
>
> (set! s "(1 2 3)")
> (eq? (read-from-string s) (read-from-string s))
> (eq? (read-from-string s) (read-from-string "(1 2 3)"))
> (eq? (read-from-string s) (read-from-string (make-string #\( #\1 #\Space
> #\2 #\Space #\3 #\) )))
all of these either #t or #f
> Actually, changing the highlighted word "the" to "an" makes a pretty good
> clarification on the current state of things.
I wanted to clarify that the *result* of QUOTE is the very *same* object
that was the argument to quote.
>> 3. Specify clearly that EVAL is allowed to `split':
>>
>> EVAL is allowed, but not required, to make a copy of its input.
>
> How deep is EVAL allowed to copy?
Forget this. It's bogus.
·············@comcast.net writes:
> Political issues of changing the standard aside (which I consider
> to be the main obstacle), it would be not be difficult at all.
I don't agree.
> 1. Amend the description of QUOTE to avoid the unfortunately
> confusing text. Something like this:
>
> (QUOTE <datum>) syntax
>
> (QUOTE <datum>) evaluates to <datum>. <datum> may be any scheme
> object that has an external representation. To clarify, <datum>
> is the object created as a result of parsing an external
> representation as if by the READ library procedure.
Any object that has an external representation would miss most of the
really useful objects.
For example, the implementations of CLOS (well, it was PCL and the
like at the time, long ago) that I'm familiar with really want either
LOAD-TIME-VALUE or QUOTE to be able to accomodate a literal reference
to the class wrapper table, to avoid having to reference it indirect
uselessly through some global variable's value cell as if the pointer
to the object were going to change, which it is not. (That is, the
pointer to the table object is not going to change, but the table
contents will, of course, change, and must be carefully shared.
Similar issues came up in my Fortran to Lisp translator, even longer
ago, for managing the shared memory arrays that were the Fortran virtual
memory. There is probably some discussion of this trick in
http://www.nhplace.com/kent/Papers/Fortran-to-Lisp.html
though it may be hard to ferret out due to changes in the language
nomenclature since then.
> 2. Specify clearly that READ is allowed to coalesce:
Making READ be allowed to coalesce does not show much respect for identity.
Changes to allow this are changes in the wrong direction.
Among other things, you are precluding the possibility of #. doing most
of its useful job, not that Scheme has it, but you're locking out even the
possibility of that as an option, which again drifts from identity-centric
changes.
> READ library procedure
>
> READ converts external representations of Scheme objects into the
> objects themselves. That is, it is a parser for the nonterminal
> <datum>. It is unspecified whether aggregate objects returned by
> READ are unshared, thus it is an error to mutate objects returned
> by READ. (An implementation could, for instance, construct
> object by `hash-consing' to minimize storage allocation.)
>
> 3. Specify clearly that EVAL is allowed to `split':
Making anything split identities is also a drift away from identity-centric.
I don't know why you think this would fix anything to be more CL-like.
This would be disastrous because not only does it preclude the correct
operation of #., but it doesn't even let you construct objects under
program control where identity matters. e.g.,
(eval `(lambda (x) (aref ',*the-class-table* ,class-index)))
If EVAL is allowed to make copies of things, then you won't be indexing
out of *the-class-table*, you'll be indexing out of a stale copy of it.
> EVAL is allowed, but not required, to make a copy of its input.
> It is an error to mutate objects that have been passed to EVAL.
>
> Note that this implies the following:
> (let ((x (list a b c))
> (expression (list 'QUOTE x)))
> (eq? x (eval expression (r6rs-environment)))) => #t or #f
>
> 4. Specify clearly the nature of <datum>:
>
> <datum> is a subset of scheme objects that have external
> representations. The grammar of <datum> is therefore
> defined as a mapping from a sequence of tokens to Scheme
> objects. The READ library procedure implements such
> a parser.
This means there are a lot of objects that can't be quoted.
That's not identity-centric either, since it says that some identities
are more identifying than others. In CL, identity is identity. The
rest is just "capability". What you're really saying here is
discriminating against some identities on the basis of something
unrelated to identity. This doesn't make it more CL-like.
> 5. Specify the difference in the BNF grammars in section 7.1
>
> In section 7.1.1, the grammar is defined as a mapping between
> character sequences and tokens.
>
> In section 7.1.2, the grammar is defined as a mapping between
> tokens and <datum>.
>
> In section 7.1.3, the grammar is defined as a mapping between
> *scheme objects* and expressions. Because scheme objects
> cannot be literally placed on the page, the notation uses the
> external representation of the object. To be clear: the
> elements on the right hand side of the productions are
> scheme object themselves, not their external representation.
>
> Thus, for example,
> the production:
> <procedure call> --> (<operator> <operand>*)
>
> is to be interpreted as a LIST with at least one element,
> and that element is distinguished as the <operator> rather
> than being interpreted as a token stream beginning and ending
> with ( and ) respectively.
>
> I'm pretty sure that something like this would be acceptable to
> the RnRS authors.
(Not with this one. But I'm used to disagreeing with most of the other
authors... ;)
Your proposed changes would not at all address the issues that CL
people have with it. So, if you had independent motivation to change
this for some Scheme-community-related-reason, I guess you could propose
it, but this actively goes in the wrong direction in my opinion and is
not even "better than nothing". It is, in my opinion, worse than nothing,
in that it precludes individual vendors from doing the right thing
compatibly with RnRS Scheme.
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <wucl7had.fsf@comcast.net>
Kent M Pitman <······@world.std.com> writes:
> ·············@comcast.net writes:
>
>> Political issues of changing the standard aside (which I consider
>> to be the main obstacle), it would be not be difficult at all.
>
> I don't agree.
It depends upon what the goals are. I was just interested
in removing confusion.
>> 1. Amend the description of QUOTE to avoid the unfortunately
>> confusing text. Something like this:
>>
>> (QUOTE <datum>) syntax
>>
>> (QUOTE <datum>) evaluates to <datum>. <datum> may be any scheme
>> object that has an external representation. To clarify, <datum>
>> is the object created as a result of parsing an external
>> representation as if by the READ library procedure.
>
> Any object that has an external representation would miss most of the
> really useful objects.
(QUOTE <datum>) syntax
(QUOTE <datum>) evaluates to <datum>. <datum> may be any scheme
object. In the case that <datum> has been created by parsing
source text, then <datum> is the object created as a result of
parsing an external representation as if by the READ library
procedure.
>> 2. Specify clearly that READ is allowed to coalesce:
>
> Making READ be allowed to coalesce does not show much respect for identity.
> Changes to allow this are changes in the wrong direction.
>
> Among other things, you are precluding the possibility of #. doing most
> of its useful job, not that Scheme has it, but you're locking out even the
> possibility of that as an option, which again drifts from identity-centric
> changes.
Ok, I'll rephrase. READ should be allowed to coalesce those objects
it creates via parsing (as opposed to those created via other
mechanism such as #.)
>> READ library procedure
>>
>> READ converts external representations of Scheme objects into the
>> objects themselves. That is, it is a parser for the nonterminal
>> <datum>. It is unspecified whether aggregate objects returned by
>> READ are unshared, thus it is an error to mutate objects returned
>> by READ. (An implementation could, for instance, construct
>> object by `hash-consing' to minimize storage allocation.)
>>
>> 3. Specify clearly that EVAL is allowed to `split':
>
> Making anything split identities is also a drift away from identity-centric.
> I don't know why you think this would fix anything to be more CL-like.
I didn't say I wanted to make it more CL-like, just less confusing.
> This would be disastrous because not only does it preclude the correct
> operation of #., but it doesn't even let you construct objects under
> program control where identity matters. e.g.,
Forget this one, then.
>> 4. Specify clearly the nature of <datum>:
>>
>> <datum> is a subset of scheme objects that have external
>> representations. The grammar of <datum> is therefore
>> defined as a mapping from a sequence of tokens to Scheme
>> objects. The READ library procedure implements such
>> a parser.
>
> This means there are a lot of objects that can't be quoted.
No, (after my adjustment to quote above) it means that there are a lot
of objects that cannot be written in source code. But that is how it
is now. The point of the clarification is that <datum> definitely
does *not* mean `token stream'.
>> 5. Specify the difference in the BNF grammars in section 7.1
>>
>> In section 7.1.1, the grammar is defined as a mapping between
>> character sequences and tokens.
>>
>> In section 7.1.2, the grammar is defined as a mapping between
>> tokens and <datum>.
>>
>> In section 7.1.3, the grammar is defined as a mapping between
>> *scheme objects* and expressions. Because scheme objects
>> cannot be literally placed on the page, the notation uses the
>> external representation of the object. To be clear: the
>> elements on the right hand side of the productions are
>> scheme object themselves, not their external representation.
>>
>> Thus, for example,
>> the production:
>> <procedure call> --> (<operator> <operand>*)
>>
>> is to be interpreted as a LIST with at least one element,
>> and that element is distinguished as the <operator> rather
>> than being interpreted as a token stream beginning and ending
>> with ( and ) respectively.
>>
>> I'm pretty sure that something like this would be acceptable to
>> the RnRS authors.
>
> (Not with this one. But I'm used to disagreeing with most of the other
> authors... ;)
>
> Your proposed changes would not at all address the issues that CL
> people have with it. So, if you had independent motivation to change
> this for some Scheme-community-related-reason, I guess you could propose
> it, but this actively goes in the wrong direction in my opinion and is
> not even "better than nothing". It is, in my opinion, worse than nothing,
> in that it precludes individual vendors from doing the right thing
> compatibly with RnRS Scheme.
Well, at least this is something constructive.
Erann Gat writes:
> But the main point, the one that you missed, is that this is not a
> complicated issue. It's a simple issue: there's an essential
> difference between Scheme and Lisp. You can characterise that
> difference in different ways. I characterize it as, "Scheme
> semantics are defined on text." Kent characterises it as, "CL code
> has identity (necessarily); Scheme code doesn't (or at least isn't
> required to)." That difference is mostly academic, but it does have
> some practical consequences. And some people consider the CL
> binding of this property to be essential to Lisp-ness, and that is
> why some people consider Scheme to not "be a Lisp" despite the fact
> it calls itself a Lisp and appears for all intents and purposes to
> be a Lisp.
I more or less agree.
Scheme is _not_ a lisp -- all lisps are implementations and Scheme is
not an implementation, it's a standard to which lisps may or may not
conform.
That isn't a purely pedantic point in this context. A good way to
use the words, in my opinion, would be to say things like:
1) Some lisps implement Scheme.
2) Some implementations of Scheme are not lisps.
3) If you stick only to the behaviors guaranteed by Scheme in your
lisp programs, you will find yourself feeling that you are not
quite taking full advantage of your lisp. (The "give me a damn
defmacro, already" syndrome, for example.)
4) Scheme appears to be, as much as anything, the self-conscious
creation of a standards committee that chose to resolve conflicting
ideas with underspecification rather than compromise. It would
only be a slight exaggeration to say that the implicit motto of
Scheme was "If you can't say The Right Thing, don't say anything at
all," (where the meaning of "The Right Thing" is surely a
problematic concept that, historically, appears to have related to
contemporary research into compiler design and teaching
techniques, and the personal intuitions that research gave rise to
among the committee members).
Compromises occurred, in Scheme, certainly -- but a prominent theme
of Scheme is that where committee members split over an issue that
appeared to have significant implementation implications, they
often sought resolutions that simply evaded the issue, sometimes
with the consequence of producing a standard that can be
implemented without necessarily implementing what you and I would
call a lisp.
5) Common Lisp is also not a lisp -- it, too, is a standard. But in
contrast to Scheme, Common Lisp appears to be the self-conscious
creation of a standards committee many of whose members had vested
interests in already well established, powerful lisps, each with an
extensive collection of libraries. It appears that when there were
conflicts among those members, the prevailing consideration was
more often "What can we do here that each of us can practically
implement without sacrificing our existing code too badly, and that
will help to ensure full-featured portability between our lisps?"
Moves towards some notion of The Right Thing surely occured in
Common Lisp -- but always they were subordinate to the idea of
making a collection of good lisps more valuable by making code
portable between them.
6) One ought to ask this: Let's suppose that the Scheme committee
wanted to make a tiny, "clean", mathematically precise,
pedagogically useful, handy-for-compiler/interpreter-research
standard. What historic forces drove them to diverge so
irreconcilably far from defining what would serve as a "core" of
Common Lisp? Why did Scheme finally wind up not only as not Common
Lisp, but as a language _irreconcilable_ with Common Lisp?
Wouldn't it obviously have been better if they had produced a
standard about which one could say "And look, just add
upward-compatible extensions and some libraries, and you've got
Common Lisp. Indeed, a really excellent Scheme compiler, it turns
out, is pretty darn good Common Lisp compiler. Add support for
declarations, and it's a damn fine Common Lisp compiler."
But they didn't. They diverged in a number of really serious ways.
The inequality of #f and () is probably the biggest. I don't see
any coherent way to make a Scheme #f value anything but awkward in
a Common Lisp lisp.
Other familiar divergences (function bindings being distinct from
value bindings, "proper tail recursion", differences in the
treatment of numbers, not enough Scheme semantics to make sense of
defmacro, etc.) are probably reconcilable. But deciding (in R5RS,
not sooner) to separate () and #f -- that was a declaration that
"These two standards shall never converge."
7) Some Common Lisp proponents seem to me to be stuck in a failed
dream. Calling it a "failed" dream risks being provocative --
sorry. The dream goes: "well, we'll make a standard (CL), and
then we'll be able to say to the suits `look, we have a standard.
You can buy from any of the N following vendors, whenever you
like. See? We're just as good as C/Ada/Fortran. Only we're
better, of course, because...well, just look at our hacks.'"
"Failed dream" _is_ too strong. "Niche dream" is better.
You saw the informal survey results, right? Very strong trend
towards "No, I don't use Lisp on my job but I'm trying to work on
that." or even just "No, I don't use lisp on my job. I wish!"
Portability is good and specifications are good. I'm not so sure
that much has really been bought, other than for a few
niche-employed hackers, by all the baggage of Common Lisp. A few
good-spirited memos making the rounds of implementors might have
achieved the same practical result.
And stuff has been lost. The last generation lispm hackers I heard
from made a big deal not just about lisp -- but about mastery.
About hacking at all levels of the system. If you needed to solve
something by hacking microcode -- cool! lucky you!. It seemed to
me much more about _owning_ every aspect of the computing system --
having access to all of it -- having freedom and the intellectual
wherewithal to put it to good use.
And then I read posts on this list. Posts from names I recognize
from old documents that I respect a lot. And, to be blunt, they
emphasize the standards in a way that I think amounts to
sucking-the-members-of-the-Suits-of-the-Imagination.
I want to explain what I mean by
"sucking-the-members-of-the-Suits-of-the-Imagination".
The Suits-of-the-Imagination are notorious anti-intellectual,
socially irresponsible liars. Here's one of their favorite tricks:
a) suit employs some brilliant hacker
b) hacker says "Well, we _really_ want to do things this way.
But you need to rearrange your budget / let me hire
so-and-so / tell the customers to change their schedule as
follows... / whatever. In short, you have to _do_
something. You have to confront the board / get on your
knees before the CFO / _think_ about the GD implications 2
years from now / retract some bullshit you spouted at the
last customer meeting / .... But _really_, this is the
Right Way to do it."
c) Suit's eyes glaze over. He really doesn't understand the
engineering issues. He doesn't want to -- that'd take
real work and he didn't do too good in engineering school /
at his last coding job / .... All he knows is that going
down on his knees before the CFO or being embarassed in
front of the customer is an afront to his dignity. The
Suit-of-the-Imagination has a birthright to perpetual and
uninterrupted dignity.
d) Suit gets a beer with a Fink. What's a fink? A Fink is
a guy who _does_ understand the engineering issues -- and
who doesn't care. A Fink is a B- engineer. A Fink is
the guy who got kicked off one too many projects. A Fink
is a cynical turd out to do as much damage as he can --
he's just Acting Out.
And the Suit tells the Fink a list of buzzwords the
brilliant hacker mentioned (coherent sentences aren't
necessary -- just the buzzwords). And the Fink ponders
and says, "OK, I know what this guy's buttons are. Here,
when he says `lisp', you say `standards' (or `ick, GC', or
`ick, only smart people like you can handle lisp' or `gee,
well, C++ is the industry standard'.)
e) Suit goes back to hacker and spews the comebacks from Fink.
Not very coherently but that doesn't matter. Hacker has
never imagined that people could be as cynical and
uncivilized and anti-intellectual as Suit and Fink. Suit
_must_ be saying something important -- there's simply no
other possibility. If Suit says something that doesn't
quite make sense -- no problem -- hacker will try to figure
out something vaguely sensible that must be what Suit
really meant. Hacker will take the imagined criticisms
seriously -- not as a fancy way to say "No, arbitrarilly"
but as an invitation to debate and refutation. The
feedback from Fink turns into a stick up Hacker's ass for
years to come and Hacker devotes way too much time and
energy working on refuting it.
f) Suit talks to his Suit Buddies about the experience. They
learn a trick or two. Suddenly, all of Hacker's Hacker
drinking buddies are facing Exactly the Same Bullshit.
Only they don't think it's bullshit. Hacker and Hacker
Buddies have never imagined that people could be as cynical
and uncivilized and anti-intellectual as Suits and Finks.
The feedback from Finks turns into a stick up the Hackers'
asses for years to come and Hackers devote way too much
time and energy working on refuting it -- only now they
have Inspiration in the form of a Misplaced Class Identity
(since all the Hackers are seeing similar problems).
g) Hackers waste their time. Some guy invents Python and a
bunch of hackers make libraries for it. Sure, they rush,
they miss fundamentals, they make 1-year-solutions that
represent 10-year-problems. They miss the big
opportunities. Meanwhile the Hackers struggle to open
sockets in more than one implementation (since sockets
weren't all that important when CL was written) and wonder
how it came to pass that the Right Thing Design of portable
filenames doesn't quite work.
Worse is better?
I say: go back to the roots. CL emerged out of a bunch of
implementations that a huge fraction of the user community Owned --
could and did hack at all levels. Casual interest in standards, as a
purely informal and practical matter, would have been celebrated by
those guys. Obsession with them, as exhibited on this list, would
have been called "Facism".
So screw it. Hit the degausse button on the community lisp mindset.
Screw the idea that c.l.s. is a place to kill some time during your
day, with verbal fireworks or weak allusions to the War of the Roses
or Jonathan Swift -- again: did you _see_ those survey results? Put
aside the mythology of the Importance of Standards. Let's get back to
hacking.
Me? I'm now about 1/5 of the way through a new lisp implementation.
It's almost 1000 lines, now. It has something to piss off everyone --
it's not quite CL and it's not quite Scheme. From the Must Respect
Standards perspective, it's a dumb, dumb, dumb idea.
It's also, intially, going to be good and slow. After fscking around
for a while with "the most sophisticated GC I could think of" and "the
fanciest tagging system I could think of" etc.... I came to the
conclusion that three things matter most, as a practical matter:
1) Consider the abstractions in the implementation very
carefully -- so that fancy tagging or fancy GC can be
added later.
2) Make it very C friendly, so that hackers can extend it
quickly and easily at a low level.
3) Make it free software, so that hackers can Own it.
See you in a few weeks, knock on wood.
-t
[ a couple of tangential points, I'm afraid ]
····@emf.emf.net (Tom Lord) writes:
> "Failed dream" _is_ too strong. "Niche dream" is better. You
> saw the informal survey results, right? Very strong trend
> towards "No, I don't use Lisp on my job but I'm trying to work on
> that." or even just "No, I don't use lisp on my job. I wish!"
"niche" is also a loaded and deceiving word. all the jobs worth
taking are "niche", period. the "non-niche" jobs consist mostly of
banging rocks together (a.k.a. "using industry-standard components to
build enterprise applications"), the rest of time being devoted to
fascinating (ot not) workplace politics. it's not a coincidence that
smart people generally prefer building components to using them.
> Me? I'm now about 1/5 of the way through a new lisp implementation.
> It's almost 1000 lines, now. It has something to piss off everyone
> -- it's not quite CL and it's not quite Scheme. From the Must
> Respect Standards perspective, it's a dumb, dumb, dumb idea.
>
> It's also, intially, going to be good and slow.
Tom? I'm sorry to say what I'm going to say, but it will always be
good and slow. most probably you'll abandon it in a year or two,
tops.
--
Tools that are no good require more skill.
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <d6egveqi.fsf@comcast.net>
Eli Barzilay <···@barzilay.org> writes:
> ---but---
>
> But all of this is still unrelated to any result of the (eq (foo)
> (foo)) example, since that could easily be added to R5RS as is. The
> simple way to do that would be to say that whatever is the
> representation of the syntax inside the quote, it is the exact same
> one that is returned on every evaluation of the quote form.
There is actually some difficulty here, though, and it is why the
authors declined to specify what (eq (foo) (foo)) returns. The first
difficulty is whether `splitting' and `coalescing' of quoted objects
is allowed. Common Lisp specifically allows coalescing, but prohibits
splitting. The semantic difficulty with that is that something that
is false (eq '(a b c) '(a b c)) may become true after being compiled.
If you think that compiled code should behave exactly like interpreted
code in all respects, this is a problem.
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <he3svfag.fsf@comcast.net>
···@jpl.nasa.gov (Erann Gat) writes:
> When I was a graduate student I did my master's thesis on something called
> "the problem of referential transparency".
> knows(Mary, phone-of(Bill))
> phone-of(Bill) = phone-of(John)
>
> This problem has for unfathomable reasons attracted the attention of
> philosophers for a hundred years.
That's because they so frequently get it wrong. If you could go back
in time and give these philosophers a course in computing, imagine how
much simpler (and understandable) philosophy would be.
> The hairy end of the business is not what quote means, but rather what it
> means to "return X". Does it mean X *itself*, or merely something that
> looks like X? If John's phone number is the same as Bill's phone number,
> are they really *the same thing*, or are they *two different things that
> just happen to look the same*? (This is just rehashing the point that
> Kent made about respecting identity.)
>
> When CL says quote "returns X" it means that it returns X *itself*. When
> Scheme says quote "returns X" it means that it returns something that just
> happens to look like X. But the *reason* that Scheme says this is not
> because it makes conscious choice of these semantics over other semantics,
> it is because the object X *does not exist as a concept* in the extant
> presentation of Scheme's semantics. Scheme programs are strings of
> characters, not because (eq? (foo) (foo)) can return #F, but because
> that's just what the Scheme standard says they are.
(defun phone-of (x)
(ecase x
(john '(5 5 5 3 3 4 7))
(bill '(5 5 5 3 3 4 7))))
(eq (phone-of 'john) (phone-of 'bill)) => ???
> ---
> The symbol "=>" used in program examples should be read "evaluates to."
> For example,
>
> (* 5 8) ==> 40
>
> means that the expression (* 5 8) evaluates to the object 40 . Or, more
> precisely: the expression given by the sequence of characters " (* 5 8) "
> evaluates, in the initial environment, to an object that may be
> represented externally by the sequence of characters " 40 ".
> ---
>
> Note the reference to "the expression given BY THE SEQUENCE OF
> CHARACTERS". Scheme expressions are sequences of characters, not lists.
You're interpreting this incorrectly. The `GIVEN BY' doesn't mean
`THAT IS', but rather `THAT IS THE EXTERNAL REPRESENTATION OF'. This
is because you cannot print literal lisp objects, you can only print
visually recognizable glyphs. Similarly, a machine must have some
mechanism for parsing objects from some external representation
(usually a sequence of small integers).
> That is why the semantics of QUOTE in Scheme are:
>
> "`(quote <datum>)' evaluates to <datum>. <Datum> may be any EXTERNAL
> REPRESENTATION of a Scheme object." (Emphasis added.)
As I pointed out in a previous post, this sentence is wrong. If
<datum> were simply a string of characters, then (quote <datum>) would
return a string. The READ procedure would return a string. The bulk
of the report could be omitted because there would be no numbers,
pairs, vectors, closures, procedures, etc. because those are all
disjoint from strings, and all <datum> is strings. It is clearly an
indefensible position.
In article <············@comcast.net>, ·············@comcast.net wrote:
> > ---
> > The symbol "=>" used in program examples should be read "evaluates to."
> > For example,
> >
> > (* 5 8) ==> 40
> >
> > means that the expression (* 5 8) evaluates to the object 40 . Or, more
> > precisely: the expression given by the sequence of characters " (* 5 8) "
> > evaluates, in the initial environment, to an object that may be
> > represented externally by the sequence of characters " 40 ".
> > ---
> >
> > Note the reference to "the expression given BY THE SEQUENCE OF
> > CHARACTERS". Scheme expressions are sequences of characters, not lists.
>
> You're interpreting this incorrectly. The `GIVEN BY' doesn't mean
> `THAT IS', but rather `THAT IS THE EXTERNAL REPRESENTATION OF'.
No, I don't think so. Because lists exist as first-class entities in
Scheme the writers of the Scheme standard could have chosen to speak
directly about "forms" or some equivalent term for the concept, but they
didn't.
> > That is why the semantics of QUOTE in Scheme are:
> >
> > "`(quote <datum>)' evaluates to <datum>. <Datum> may be any EXTERNAL
> > REPRESENTATION of a Scheme object." (Emphasis added.)
>
> As I pointed out in a previous post, this sentence is wrong.
Sorry, standards are by definition never wrong. They may be internally
inconsistent or otherwise broken, but they are never wrong.
E.
I haven't been following this thread because I think its subject matter
is ridiculous. Nonetheless I happened to read this particular message
out of context, and decided to respond. I do not promise to read any
followups.
Erann Gat wrote:
> In article <············@comcast.net>, ·············@comcast.net wrote:
>
> > > ---
> > > The symbol "=>" used in program examples should be read "evaluates to."
> > > For example,
> > >
> > > (* 5 8) ==> 40
> > >
> > > means that the expression (* 5 8) evaluates to the object 40 . Or, more
> > > precisely: the expression given by the sequence of characters " (* 5 8) "
> > > evaluates, in the initial environment, to an object that may be
> > > represented externally by the sequence of characters " 40 ".
> > > ---
> > >
> > > Note the reference to "the expression given BY THE SEQUENCE OF
> > > CHARACTERS". Scheme expressions are sequences of characters, not lists.
> >
> > You're interpreting this incorrectly. The `GIVEN BY' doesn't mean
> > `THAT IS', but rather `THAT IS THE EXTERNAL REPRESENTATION OF'.
>
> No, I don't think so. Because lists exist as first-class entities in
> Scheme the writers of the Scheme standard could have chosen to speak
> directly about "forms" or some equivalent term for the concept, but they
> didn't.
As one of the writers of the Scheme standard, I agree with prunesquallor
on this.
> > > That is why the semantics of QUOTE in Scheme are:
> > >
> > > "`(quote <datum>)' evaluates to <datum>. <Datum> may be any EXTERNAL
> > > REPRESENTATION of a Scheme object." (Emphasis added.)
> >
> > As I pointed out in a previous post, this sentence is wrong.
>
> Sorry, standards are by definition never wrong. They may be internally
> inconsistent or otherwise broken, but they are never wrong.
Slightly broken, then. The standard says "external representation"
there in order to restrict the literal expressions to yield values
that have an external representation. The <datum> that follows the
<quote> is syntax; the <datum> to which the literal expression
evaluates is a value, not syntax. The editors considered more
correct language here, but decided that the slightly broken language
would be clearer and less pedantic.
At the time this was written, BTW, it was not clear whether Common
Lisp was intended to allow absolutely all values to be quoted.
There are interesting interactions with COMPILE-FILE when the quoted
value is a closure, for example. X3J13 gave serious consideration to
allowing implementations to make copies of quoted constants (see
http://www.lispworks.com/reference/HyperSpec/Issues/iss282_w.htm).
IMO, any argument about the fundamental nature of Common Lisp that
depends upon the rather arbitrary resolution of this issue must be
silly.
Will
In article <····························@posting.google.com>,
··········@verizon.net (William D Clinger) wrote:
> As one of the writers of the Scheme standard...
Hm, a voice from the heavens. I am reminded of a passage from
http://www.us-israel.org/jsource/loc/Talmud.html:
The spirit of the Talmudic process is expressed in a tale in tractate Baba
Meziah. Rabbi Eliezer, a proponent of unchanging tradition--"a well-lined
cistern that doesn't lose a drop," as his teacher characterized him--was
engaged in a legal disputation with his colleagues. "He brought all the
reasons in the world," but the majority would not accept his view. Said
Rabbi Eliezer, "If the law is as I hold it to be, let this tree prove it,"
and the tree uprooted itself a hundred amma, but they said, "Proof cannot
be brought from a tree." Rabbi Eliezer persisted, saying, "Let these
waters determine it," and the waters began to flow backwards, but his
colleagues responded that waters cannot determine the law. Once again
Rabbi Eliezer tried, asking the walls of the study house to support him.
They began to totter, whereupon the spokesman for the majority, Rabbi
Joshua, admonished them, "when rabbis are engaged in legal
discussion what right have ye to interfere!" So the walls did not
fall in respect for Rabbi Joshua, nor did they return to their upright
position, in respect for Rabbi Eliezer-and "they remain thus to this day!"
But Rabbi Eliezer would not surrender and cried out: "Let Heaven decide."
A voice was heard from Heaven saying: "Why do ye dispute with Rabbi
Eliezer; the law is always as he says it to be." Whereupon Rabbi
Joshua arose and proclaimed, quoting Scripture, "It is not in Heaven!"
Rabbi Jeremiah explained, "The Law was given at Sinai and we no longer
give heed to heavenly voices, for in that Law it is stated: 'One follows
the majority."' God's truth, divine law, is not determined by
miracles or heavenly voices, but by the collegium of rabbis, men learned
in the law, committed to the law and expert in its application to the life
of the pious community.
;-)
> The standard says "external representation"
> there in order to restrict the literal expressions to yield values
> that have an external representation. The <datum> that follows the
> <quote> is syntax; the <datum> to which the literal expression
> evaluates is a value, not syntax.
Yes, that's consistent with my position.
> IMO, any argument about the fundamental nature of Common Lisp that
> depends upon the rather arbitrary resolution of this issue must be
> silly.
So is that.
E.
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <znhkt7k7.fsf@comcast.net>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <············@comcast.net>, ·············@comcast.net wrote:
>
>> > ---
>> > The symbol "=>" used in program examples should be read "evaluates to."
>> > For example,
>> >
>> > (* 5 8) ==> 40
>> >
>> > means that the expression (* 5 8) evaluates to the object 40 . Or, more
>> > precisely: the expression given by the sequence of characters " (* 5 8) "
>> > evaluates, in the initial environment, to an object that may be
>> > represented externally by the sequence of characters " 40 ".
>> > ---
>> >
>> > Note the reference to "the expression given BY THE SEQUENCE OF
>> > CHARACTERS". Scheme expressions are sequences of characters, not lists.
>>
>> You're interpreting this incorrectly. The `GIVEN BY' doesn't mean
>> `THAT IS', but rather `THAT IS THE EXTERNAL REPRESENTATION OF'.
>
> No, I don't think so. Because lists exist as first-class entities in
> Scheme the writers of the Scheme standard could have chosen to speak
> directly about "forms" or some equivalent term for the concept, but they
> didn't.
Lists won't exist as first class entities if all <datum> is strings.
List is a subset of <datum>.
>> > That is why the semantics of QUOTE in Scheme are:
>> >
>> > "`(quote <datum>)' evaluates to <datum>. <Datum> may be any EXTERNAL
>> > REPRESENTATION of a Scheme object." (Emphasis added.)
>>
>> As I pointed out in a previous post, this sentence is wrong.
>
> Sorry, standards are by definition never wrong. They may be internally
> inconsistent or otherwise broken, but they are never wrong.
I never said the standard was wrong, I said that sentence was.
·············@comcast.net writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > The hairy end of the business is not what quote means, but rather what it
> > means to "return X". Does it mean X *itself*, or merely something that
> > looks like X? If John's phone number is the same as Bill's phone number,
> > are they really *the same thing*, or are they *two different things that
> > just happen to look the same*? (This is just rehashing the point that
> > Kent made about respecting identity.)
> >
> > When CL says quote "returns X" it means that it returns X *itself*. When
> > Scheme says quote "returns X" it means that it returns something that just
> > happens to look like X. But the *reason* that Scheme says this is not
> > because it makes conscious choice of these semantics over other semantics,
> > it is because the object X *does not exist as a concept* in the extant
> > presentation of Scheme's semantics. Scheme programs are strings of
> > characters, not because (eq? (foo) (foo)) can return #F, but because
> > that's just what the Scheme standard says they are.
>
> (defun phone-of (x)
> (ecase x
> (john '(5 5 5 3 3 4 7))
> (bill '(5 5 5 3 3 4 7))))
>
> (eq (phone-of 'john) (phone-of 'bill)) => ???
Actually, unless I'm misremembering [I didn't do an extensive search of
documents on this one, so someone who likes doing such things can
double-check me], this is more well-defined than you may think. That is,
If you do
(setq *foo* '(5 5 5 3 3 4 7)) ;give the object an identity
(eval '(defun phone-of (x)
(ecase x
(john '#.*foo*)
(bill '#.*foo*))))
in a Listener, I don't think the implementation has any choice but to
return T for (eq (phone-of 'john) (phone-of 'bill)). Further, even
if you do
(compile 'phone-of)
I don't think it can change this. I think it can only change it if you
use the file compiler, and that is not an issue of the compilation
semantics, that's an issue of the limitations of externalization. There
isn't enough information in the object to know whether the fact of the
constant list being the same is an accidental effect or an intentional
effect. The file compiler is given license, not when compiling but when
saving/loading, to achieve a weaker standard of identity than one might
wish if there were a single unified CORBA-like address space throughout the
universe. We don't create -- what are they called? -- IORs? -- for every
single cons cell. If we did, we could perhaps guarantee true object
identity _even across images_. However, we do care enough about object
identity that we carefully detail what will happen to object identity
when you do go through this externalization process, which is again
more than Scheme does, and the mere fact of that again shows our
community's emphasis on the idea that "identity matters".
One way of looking at file compilation is to say that calling compile-file
is an implicit declaration that you are not caring about this level of
identity; surely although the language cares, not every program is allowed
to care, so in a sense, the weaker semantics of file compilation (that is,
of both "compilation" + "externalization", is something that is acceptable
to most people.
The reason you don't know about your original form (with the two QUOTE
expressions) is not a weakness in QUOTE, but an issue in the externalization
+ load operations that makes it unclear whether you meant the same or
different quoted expression. But once you know the identity of that object,
it is not subsequently violated, other than by externalization.
Incidentally, it turned out that people later got nervous about QUOTE
providing this service, and we later made some changes to add LOAD-TIME-VALUE
to make this more "apparent". I recommend not doing the trick I showed
above when you really care about object identity. Don't use
'#.*foo*
but instead use (load-time-value *foo*). This both makes your intent
more apparent and leaves things free for the compile+externalization
semantics to be brought more in line with the eval/compile semantics.
Note that this is the part I didn't research--I think we might have
started along that path already, but I'm not sure, and I don't remember
how far we got. LOAD-TIME-VALUE is, effectively, a deferred-quote,
that says it won't know what the value to use is until load time.
I think it's vaguely like an "own variable" in Algol, only anonymous.
My real point is not to say that quote works this way or doesn't, but
rather to say that "if identity is something you care about, there is
ample ability to assure that you can get that degree of expression without
sacrificing efficiency".
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <smnct745.fsf@comcast.net>
Kent M Pitman <······@world.std.com> writes:
> ·············@comcast.net writes:
>
>> (defun phone-of (x)
>> (ecase x
>> (john '(5 5 5 3 3 4 7))
>> (bill '(5 5 5 3 3 4 7))))
>>
>> (eq (phone-of 'john) (phone-of 'bill)) => ???
> The reason you don't know about your original form (with the two QUOTE
> expressions) is not a weakness in QUOTE, but an issue in the externalization
> + load operations that makes it unclear whether you meant the same or
> different quoted expression. But once you know the identity of that object,
> it is not subsequently violated, other than by externalization.
Well..., the point is that it *could* return false when interpreted
and then true when compiled.
·············@comcast.net writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > ·············@comcast.net writes:
> >
> >> (defun phone-of (x)
> >> (ecase x
> >> (john '(5 5 5 3 3 4 7))
> >> (bill '(5 5 5 3 3 4 7))))
> >>
> >> (eq (phone-of 'john) (phone-of 'bill)) => ???
>
>
> > The reason you don't know about your original form (with the two QUOTE
> > expressions) is not a weakness in QUOTE, but an issue in the externalization
> > + load operations that makes it unclear whether you meant the same or
> > different quoted expression. But once you know the identity of that object,
> > it is not subsequently violated, other than by externalization.
>
> Well..., the point is that it *could* return false when interpreted
> and then true when compiled.
No.
If that is your point, it is a "false point".
Please go back and re-read what I wrote so I don't have to repeat it
in detail.
The issue is NOT compilation, it is externalization.
Ok, I did the literature search I didn't do the last time...
From EVAL's dictionary entry:
Constants appearing in code processed by EVAL are not copied nor
coalesced. The code resulting from the execution of EVAL references
objects that are EQL to the corresponding objects in the source code.
From COMPILE's dictionary entry:
Literal objects appearing in code processed by the compile function
are neither copied nor coalesced. The code resulting from the
execution of COMPILE references objects that are EQL to the
corresponding objects in the source code.
From 3.2.4 Literal Objects in Compiled Code:
The constraints on literal objects described in this section apply
only to COMPILE-FILE; EVAL and COMPILE do not copy or coalesce
constants.
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <d6ef91i5.fsf@comcast.net>
Kent M Pitman <······@world.std.com> writes:
> ·············@comcast.net writes:
>
>> Kent M Pitman <······@world.std.com> writes:
>>
>> > ·············@comcast.net writes:
>> >
>> >> (defun phone-of (x)
>> >> (ecase x
>> >> (john '(5 5 5 3 3 4 7))
>> >> (bill '(5 5 5 3 3 4 7))))
>> >>
>> >> (eq (phone-of 'john) (phone-of 'bill)) => ???
>>
>>
>> > The reason you don't know about your original form (with the two QUOTE
>> > expressions) is not a weakness in QUOTE, but an issue in the externalization
>> > + load operations that makes it unclear whether you meant the same or
>> > different quoted expression. But once you know the identity of that object,
>> > it is not subsequently violated, other than by externalization.
>>
>> Well..., the point is that it *could* return false when interpreted
>> and then true when compiled.
>
> No.
>
> If that is your point, it is a "false point".
>
> Please go back and re-read what I wrote so I don't have to repeat it
> in detail.
>
> The issue is NOT compilation, it is externalization.
Whoops! I meant `compiled to a file'.
·············@comcast.net writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > ·············@comcast.net writes: [...]
> > > Well..., the point is that it *could* return false
> > > when interpreted and then true when compiled.
> >
> > No. [...] The issue is NOT compilation, it is externalization.
>
> Whoops! I meant `compiled to a file'.
I figured this was what you meant. But my point is that this is not a
compilation issue. It is the "to a file" not the "compiled" part that
is causing the problem for you.
And since there is not an "interpreted to a file", there is no way to
make an apples-to-apples comparison, but the closest analogy would be
to say that you simply did some PRINT/READ thing and again I think you'd
find you were losing information. That is, PRINT/READ just do a different
kind of "externalization" than the compiler does, but they are also,
ultimately, information-losing. They try hard to retain a lot of info,
and even harder when you have *PRINT-READABLY* set to T, but even then,
they tend to retain only EQUAL (approximately "looks the same") identity,
and not EQL. Turning on *PRINT-CIRCLE* also helps, but again the sharing
table used here spans only a single call to PRINT, and...
- - -
The core of this issue is that the compilation model for CL is defined
in terms of objects already extant in the Lisp address space, exactly
because they don't take on a proper identity until they are.
File compilation is an accomodation to the fact that most people put
programs in files, with a voluntary loss of some identity information.
However, even then, unlike most languages, top level forms in a file are
managed in a certain relatively well-defined way, with much more control
than most languages have as to the time of evaluation. [Note that details
like EVAL-WHEN are likewise missing from Scheme.] Consequently, were
you to need to force the more rigorous semantics identity-based semantics
on parts of a file program, you could do [in a file]:
(eval `(...))
or (compile `(...))
in order to first construct an object of your choice using the backquote
expression [or some such other constructor expression] at load time,
and then to evaluate or compile the result using proper identity preservation
after you, under program control, had established the identity you wanted
to preserve.
... although in many cases just using LOAD-TIME-VALUE would also suffice,
even though the transformations between these two paradigms are hard to
express in mechanical terms.
- - -
The ultimate problem is that identity, not just in Lisp but in the
Universe, is really _quite_ complex to reconstruct, and it's vastly
easier to understand when you don't go, as Star Trek would say,
deconstructing people into their component atoms and then trying to
reconstruct them again. Leonard McCoy had good reason to be concerned
about this process, and what it might do to his soul, since there
probably "wasn't" a clear spec for where the soul was stored and how
it shared with other objects even in the 23rd century.
My goal, speaking with my philosopher's hat on, is to reduce a problem
to an already-known "philosophically hard" problem, just as a
mathemetician would reduce an efficiency issue to a "mathematically
hard" problem. At that point, there is an equivalence set of problems
that will all be solved when someone solves the canonical problem for
that set. And in this case, I claim, the problem of externalized
identity is a problem of the Universe, not a problem of Lisp. And so
once I've seen that Lisp has run up against it, I can rest easy because
I know that no matter what we do, we can't fix that. However, the silver
lining is that realizing this is the problem, we already know what the
workaround is: don't externalize.
And so since CL doesn't externalize for its core semantics, while
Scheme does, I claim there is a fundamentally "better definedness"
about CL than Scheme if you believe identity per se is a core concept.
Of course, if you think identity of the program doesn't matter, as I
perceive Will does, then none of this matters to you. But you should
not confuse this with thinking none of this matters to anyone. _That_
just means not everyone has the same priorities, but that's the whole
thing that started this discussion--to see why differences in
priorities led to different design. So you should feel enlightened.
On 05 Sep 2003 05:55:31 -0400, Kent M Pitman <······@world.std.com>
wrote:
>The core of this issue is that the compilation model for CL is defined
>in terms of objects already extant in the Lisp address space, exactly
>because they don't take on a proper identity until they are.
This is interesting; my view is that the QUOTE issue should be
resolved by giving lists value rather than reference semantics.
("Should" in the sense of "that's how I would do it if I were starting
from scratch", not in the sense of "we should change the Common Lisp
and Scheme standards to do it" - of course I realize it's far too late
to do that.)
>The ultimate problem is that identity, not just in Lisp but in the
>Universe, is really _quite_ complex to reconstruct, and it's vastly
>easier to understand when you don't go, as Star Trek would say,
>deconstructing people into their component atoms and then trying to
>reconstruct them again. Leonard McCoy had good reason to be concerned
>about this process, and what it might do to his soul, since there
>probably "wasn't" a clear spec for where the soul was stored and how
>it shared with other objects even in the 23rd century.
And I also think the "take me apart, take me apart, what a way to
roam" model of teleportation presents no philosophical problem
whatsoever, though it hadn't occurred to me that there might be a
connection between the two issues until Kent pointed it out.
So this is a data point to support Kent's view that this is a general
philosophical issue.
>So you should feel enlightened.
Actually I do ^.^
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
················@eircom.net (Russell Wallace) writes:
> On 05 Sep 2003 05:55:31 -0400, Kent M Pitman <······@world.std.com>
> wrote:
>
> >The core of this issue is that the compilation model for CL is defined
> >in terms of objects already extant in the Lisp address space, exactly
> >because they don't take on a proper identity until they are.
>
> This is interesting; my view is that the QUOTE issue should be
> resolved by giving lists value rather than reference semantics.
> ("Should" in the sense of "that's how I would do it if I were starting
> from scratch", not in the sense of "we should change the Common Lisp
> and Scheme standards to do it" - of course I realize it's far too late
> to do that.)
Oh, no. That would have surprising effects you may not be contemplating.
I really think you don't want to do it as much as you might think...
even hypothetically. :)
Informally, people use lists not only as ways of holding things but also
as "poor man's datastructures". That is, it's _extremely_ common to have
objects that should have a type but do not yet, and so people just pass
a list of related values and use SETF of FIRST, SECOND, etc. to manage
the "slots" of the object. When they have debugged their needs, they
promote it to something more elaborate. Or sometimes it's only used one
place and it's just not worth making a type out of at all--this happens
in cases of cascaded mapping or collection operations, where you're holding
onto something just long enough to accumulate or sort it. In any case,
were you to make lists have "value semantics" as you say but other objects
have "reference semantics", you would be forcing people to use something
more heavy-duty in terms of their data structure definition and really a
lot of users would be emailing you saying you had made it "a lot harder"
to program even though they might not be able to articulate what was bad
about what you'd done, nor defend what they'd lost as "acceptable". (That
is, a lot of people would be embarrassed to say that they had not used
DEFSTRUCT or DEFCLASS as perhaps they think they are intended to. But
really they are not always intended to (at least by me, and I think many
other Lisp language designers as well are similarly aware of this).)
Btw, I am familiar with the semantics you say. The MOO language does
this. (Only the datatype OBJ has reference semantics. OBJs have
persistent, unchanging, numbered pointers that, weirdly enough, you
can even refer to fairly reliably by raw number in your programs under
most conditions; though MOO programmers usually create symbolic
reference tricks to keep them from doing this, just in case they ever
want to port code to other MOOs, which may number objects
differently.) And, indeed, within MOO code, you can't use lists as
lightweight data structures, which is often quite annoying since
objects are such heavyweight alternatives... So I'm not just guessing
at the consequences.
(There are some other quirky consequences in MOO, too, which have to
do with the fact that methods are only definable on objects, not on
lists, and so the things that operate on lists tend to have really
lousy abstractions because no one wants to bother conjuring objects
instead, and it's too hard to bother having methods on lists because
you have to indirect through a third-party object. Well, I'm rambling
here, but it might amuse someone who has MOO familiarity.)
> >The ultimate problem is that identity, not just in Lisp but in the
> >Universe, is really _quite_ complex to reconstruct, and it's vastly
> >easier to understand when you don't go, as Star Trek would say,
> >deconstructing people into their component atoms and then trying to
> >reconstruct them again. Leonard McCoy had good reason to be concerned
> >about this process, and what it might do to his soul, since there
> >probably "wasn't" a clear spec for where the soul was stored and how
> >it shared with other objects even in the 23rd century.
>
> And I also think the "take me apart, take me apart, what a way to
> roam" model of teleportation presents no philosophical problem
> whatsoever, though it hadn't occurred to me that there might be a
> connection between the two issues until Kent pointed it out.
>
> So this is a data point to support Kent's view that this is a general
> philosophical issue.
>
> >So you should feel enlightened.
>
> Actually I do ^.^
:)
On 05 Sep 2003 13:07:55 -0400, Kent M Pitman <······@world.std.com>
wrote:
>Informally, people use lists not only as ways of holding things but also
>as "poor man's datastructures".
Oh, I completely agree there should be a lightweight way to handle
aggregate data without going to the trouble of declaring a class or
whatever. I just disagree that mutable lists are a good way to do
this. Have you seen Python's 'dictionary' data type? That's the right
way to do it in my opinion.
>Btw, I am familiar with the semantics you say. The MOO language does
>this. (Only the datatype OBJ has reference semantics. OBJs have
>persistent, unchanging, numbered pointers that, weirdly enough, you
>can even refer to fairly reliably by raw number in your programs under
>most conditions; though MOO programmers usually create symbolic
>reference tricks to keep them from doing this, just in case they ever
>want to port code to other MOOs, which may number objects
>differently.) And, indeed, within MOO code, you can't use lists as
>lightweight data structures, which is often quite annoying since
>objects are such heavyweight alternatives... So I'm not just guessing
>at the consequences.
I've forgotten most of what little MOO code I knew, but what was
heavyweight about objects? I vaguely recall it being just a matter of
·@create foo', no mucking around with classes or anything.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
From: Christopher C. Stacy
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <uiso5rcyl.fsf@dtpq.com>
>>>>> On Sat, 06 Sep 2003 17:30:16 GMT, Russell Wallace ("Russell") writes:
Russell> On 05 Sep 2003 13:07:55 -0400, Kent M Pitman <······@world.std.com>
Russell> wrote:
>> Informally, people use lists not only as ways of holding things but also
>> as "poor man's datastructures".
Russell> Oh, I completely agree there should be a lightweight way to handle
Russell> aggregate data without going to the trouble of declaring a class or
Russell> whatever. I just disagree that mutable lists are a good way to do
Russell> this. Have you seen Python's 'dictionary' data type? That's the right
Russell> way to do it in my opinion.
I'm don't understand this suggestion, because Python's "dictionary"
type is a hash table, which I would not consider to be the same as a
list at all. CL has the same data type -- we call it a "hash table".
······@dtpq.com (Christopher C. Stacy) wrote in message news:<·············@dtpq.com>...
> I'm don't understand this suggestion, because Python's "dictionary"
> type is a hash table, which I would not consider to be the same as a
> list at all. CL has the same data type -- we call it a "hash table".
From a theoretical perspective, that's all well and good, but CL's
hashtables take rather more typing (on a keyboard) to use than
python's, and are thus simply less convenient.
More irritatingly, CL hashtables don't have a standard readable print
syntax - you end up with #<hashtable blah> on print, whereas in python
you get {key1: value1, key2: value2, key3: value3} on print, which can
subsequently be read back in in python.
Of course, the "xappings" example in cltl2 shows how to add such
syntax to CL, but it's not standard.
alists are obviously good enough for many purposes where hashtables
are used, as are structures (and both have defined literal syntaxes).
However, it would be nice for someone to decide that some syntax, e.g.
#X(:test eql (key1 value1) (key2 value2) (key3 value3)) where X is
some hitherto unused character was a syntax for hashtable literals.
The example given is not necessarily a particularly good suggestion
for such syntax, but hey.
In article <···························@posting.google.com>,
············@oceanfree.net (David Golden) wrote:
> ······@dtpq.com (Christopher C. Stacy) wrote in message
news:<·············@dtpq.com>...
> > I'm don't understand this suggestion, because Python's "dictionary"
> > type is a hash table, which I would not consider to be the same as a
> > list at all. CL has the same data type -- we call it a "hash table".
>
> From a theoretical perspective, that's all well and good, but CL's
> hashtables take rather more typing (on a keyboard) to use than
> python's, and are thus simply less convenient.
>
> More irritatingly, CL hashtables don't have a standard readable print
> syntax - you end up with #<hashtable blah> on print, whereas in python
> you get {key1: value1, key2: value2, key3: value3} on print, which can
> subsequently be read back in in python.
I use:
(defun \{-reader (stream char)
(declare (ignore char))
(let ( (h (make-hash-table))
(l (read-delimited-list #\} stream)) )
(loop for (k v) on l by #'cddr do (setf (@ h k) (eval v)))
h))
(set-macro-character #\{ '\{-reader)
(set-syntax-from-char #\} #\))
(defmethod print-object ((h hash-table) stream)
(princ #\{ stream)
(loop for k being the hash-keys of h do
(format stream "~S ~S " k (gethash k h)))
(princ #\} stream))
? { 1 2 3 4}
{1 2 3 4 }
? (gethash 1 *)
2
T
?
E.
············@oceanfree.net (David Golden) writes:
> ······@dtpq.com (Christopher C. Stacy) wrote in message news:<·············@dtpq.com>...
> > I'm don't understand this suggestion, because Python's "dictionary"
> > type is a hash table, which I would not consider to be the same as a
> > list at all. CL has the same data type -- we call it a "hash table".
>
> From a theoretical perspective, that's all well and good, but CL's
> hashtables take rather more typing (on a keyboard) to use than
> python's, and are thus simply less convenient.
>
> More irritatingly, CL hashtables don't have a standard readable print
> syntax - you end up with #<hashtable blah> on print, whereas in python
> you get {key1: value1, key2: value2, key3: value3} on print, which can
> subsequently be read back in in python.
It's not terribly expensive to extend CL to make this work. I have a type
TABLE I use in my own work that has a read/print syntax and is just a struct
with a single cell that is a hash-table. Yes, that's some extra overhead.
But it's small O(1) additional speed and space.
I do agree it would be nice to have hash tables just print better naturally.
No change to standard required.
From: Christopher C. Stacy
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <uk78lnvn0.fsf@dtpq.com>
>>>>> On 06 Sep 2003 22:00:48 -0400, Kent M Pitman ("Kent") writes:
Kent> I do agree it would be nice to have hash tables just print
Kent> better naturally. No change to standard required.
I used DESCRIBE when I want that, but how the quality of the
resulting print-out is implementation dependant.
Of course, in the good old days, when Lisp Listeners were based
on a dynamic presentation interface (like CLIM), one could just
click on a printed #<HASHTABLE 6942> to get it to do DESCRIBE.
It's nice to have PRINT-SELF, but in these cases, that's really about
customizing the development environment (as opposed to "serialization").
Maybe all that people really want are better development environments
(like the ones we had 15 years ago). Maybe some even have this (but
I've tried 5 out of the top 6, and they don't...)
······@dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 06 Sep 2003 22:00:48 -0400, Kent M Pitman ("Kent") writes:
> Kent> I do agree it would be nice to have hash tables just print
> Kent> better naturally. No change to standard required.
>
> I used DESCRIBE when I want that, but how the quality of the
> resulting print-out is implementation dependant.
You use DESCRIBE to save objects containing hash tables to a file
and later reload them? Cool...
From: Christopher C. Stacy
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <uiso3ol2b.fsf@dtpq.com>
>>>>> On 07 Sep 2003 18:14:06 -0400, Kent M Pitman ("Kent") writes:
Kent> ······@dtpq.com (Christopher C. Stacy) writes:
>> >>>>> On 06 Sep 2003 22:00:48 -0400, Kent M Pitman ("Kent") writes:
Kent> I do agree it would be nice to have hash tables just print
Kent> better naturally. No change to standard required.
>>
>> I used DESCRIBE when I want that, but how the quality of the
>> resulting print-out is implementation dependant.
Kent> You use DESCRIBE to save objects containing hash tables to a file
Kent> and later reload them? Cool...
No, I was referring to the where David Golden seemed to be talking
about how it's nice to see them print out, so you can tell what's in them.
That sounded like he was talking about interactive debugging, because
he was saying how "CL's hashtables take rather more typing (on a keyboard)
to use than python's, and are thus simply less convenient."
I'm don't buy the argument that hash-tables are better than lists
as generic undefined data structures on the basis of them being:
(a) "more lightweight" (they're not) or
(b) that in Python they have a nice typein/readin syntax.
In my mind, that decision is rather about how relatively easy the code
will be to convert to the real data type later, and the psychological
aspects of having deciding on a structured type and the slot names.
Other issues are cost (consing, rehashing, access pattern) and
whether or not the data really mnight be conceivably be accessed
as an ordered list or a set.
The amount of typing just doesn't enter into it for me, and my first love
was APL (which was also all about data representation and algorithms).
Personally, I don't find myself using lists as placeholder data structures.
I tend to have things mapped out well enough beforehand to know that I
will want a list or a hashtable or a structure, and I have the structure's
slot names in mind. Even when fiddling around, thinking out loud by coding,
I wouldn't use a hashtable in place of a structure. I like having the
slot names localized in one place (DEFCLASS/DEFSTRUCT), where I can see
what I've done so far and what global string-replacements need to be done.
I can't imagine traipsing randomly all over the code looking at all the
GETHASH references and hoping to find the ones that happen to match
slot names that I was making up as I went along. (And, of course,
finding all the functional access points is easier: only the slot
accessor names need to be located, not every call to GETHASH where
I might have dynamically passed in some "slot" name!)
Whether hash tables should have a nice read/print syntax seems wholly
unrelated to me. If you're talking about an external storage or
comunication representation, then who cares if it takes a few extra
characters? You're probably going to need write a macro call anyway:
I hardly ever PRINT/READ data that's like bare lists out of files.
By the time I get that far, the data input files are full of calls
to DEFFROB and MAKE-THINGAMAJIG, and dealing with identity issues.
It might be nice to have a syntax for hash tables, but I don't think
it should be part of the langauge standard, because that would impact
the readtable space. It would break old code, and would also preclude
future improvements that might want that same rare syntax. Even with
close to 20 years of general experience with how people like to use
the advanced reader facilities, there's zero experience with this
specific feature. It would be hetter if people just thrashed out ideas
for such a syntax in some forum like this one. Then the users or vendors
could write libraries that provided the feature. People could decide for
themselves how relatively useful the feature is, compared to conflicting
syntax features they might already be using. If it turned out six years
from now to be such a great idea, people will all be using it. But maybe
over that time some other, related, better, conflicting ideas will be
thought up as a result of the hashtable syntax experience.
If it's a library, we can just continue and adapt.
By contrast, putting a thing into the language standard is exactly how one
goes about killing innovation on a particular point. In Lisp and in other
languages, most features can be added in libraries. But other languages
lack the dynamic extensible features of Lisp, so they need to put any
core language extensions into their core standard. Lisp has the luxury
of not requiring that, leaving it more open to this kind of experimentation.
Let's not all be rushing out all the time to try to bake a mud pie;
you'll find that the later frostings you'll be wanting won't anneal
as well as they would to a nice yummy ball of mud.
From: Christopher C. Stacy
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <uad9hr02h.fsf@dtpq.com>
You should probably just stick to Python, which is better.
On Sat, 06 Sep 2003 23:04:06 GMT, ······@dtpq.com (Christopher C.
Stacy) wrote:
>You should probably just stick to Python, which is better.
Python doesn't suit my requirements. This doesn't mean one can't snarf
its idea of printable hash tables :) (But as another poster pointed
out, one can implement this anyway in Lisp - which makes mutable lists
even less necessary.)
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
On Sat, 06 Sep 2003 18:25:37 GMT, ······@dtpq.com (Christopher C.
Stacy) wrote:
>I'm don't understand this suggestion, because Python's "dictionary"
>type is a hash table, which I would not consider to be the same as a
>list at all. CL has the same data type -- we call it a "hash table".
Well yes, it's not the same as a list - on the contrary, for the
particular purpose Kent suggested (acting as a lightweight aggregate
data type) it's better. Therefore lists shouldn't be used for this,
therefore this use is not a good argument for making lists mutable.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
From: Christopher C. Stacy
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <uekytr8cf.fsf@dtpq.com>
>>>>> On Sat, 06 Sep 2003 18:32:42 GMT, Russell Wallace ("Russell") writes:
Russell> On Sat, 06 Sep 2003 18:25:37 GMT, ······@dtpq.com (Christopher C.
Russell> Stacy) wrote:
>> I'm don't understand this suggestion, because Python's "dictionary"
>> type is a hash table, which I would not consider to be the same as a
>> list at all. CL has the same data type -- we call it a "hash table".
Russell> Well yes, it's not the same as a list - on the contrary, for the
Russell> particular purpose Kent suggested (acting as a lightweight aggregate
Russell> data type) it's better. Therefore lists shouldn't be used for this,
Russell> therefore this use is not a good argument for making lists mutable.
I haven't heard why it's "better".
On Sat, 06 Sep 2003 20:05:20 GMT, ······@dtpq.com (Christopher C.
Stacy) wrote:
>>>>>> On Sat, 06 Sep 2003 18:32:42 GMT, Russell Wallace ("Russell") writes:
>
> Russell> Well yes, it's not the same as a list - on the contrary, for the
> Russell> particular purpose Kent suggested (acting as a lightweight aggregate
> Russell> data type) it's better. Therefore lists shouldn't be used for this,
> Russell> therefore this use is not a good argument for making lists mutable.
>
>I haven't heard why it's "better".
For one thing it makes code a lot more readable to access things by
named keys instead of as FIRST, SECOND etc.
Also, hash tables are consistent about having reference semantics, as
opposed to mutable lists where nonempty lists have reference semantics
but '() has value semantics after all. (So my suggestion that lists
should always have value semantics can also be interpreted as a
suggestion that lists should be consistent.)
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
················@eircom.net (Russell Wallace) writes:
> On Sat, 06 Sep 2003 20:05:20 GMT, ······@dtpq.com (Christopher C.
> Stacy) wrote:
>
> >>>>>> On Sat, 06 Sep 2003 18:32:42 GMT, Russell Wallace ("Russell") writes:
> >
> > Russell> Well yes, it's not the same as a list - on the contrary,
> > Russell> for the particular purpose Kent suggested (acting as a
> > Russell> lightweight aggregate data type) it's better. Therefore
> > Russell> lists shouldn't be used for this, therefore this use is
> > Russell> not a good argument for making lists mutable.
> >
> >I haven't heard why it's "better".
>
> For one thing it makes code a lot more readable to access things by
> named keys instead of as FIRST, SECOND etc.
I posted already in another post saying why this is actually undesirable
in early, exploratory programming.
> Also, hash tables are consistent about having reference semantics, as
> opposed to mutable lists where nonempty lists have reference semantics
> but '() has value semantics after all. (So my suggestion that lists
> should always have value semantics can also be interpreted as a
> suggestion that lists should be consistent.)
I don't follow this at all. It's not non-empty lists but conses that
have what you call reference semantics, but more precisely it's not reference
semantics, it's "merely a place to put things at all" that have this
property.
Would you also make arrays value-only because non-adjustable 0-length
arrays, like #(), have what you (I think erroneously) call "value semantics"?
On 06 Sep 2003 21:58:52 -0400, Kent M Pitman <······@world.std.com>
wrote:
>I don't follow this at all. It's not non-empty lists but conses that
>have what you call reference semantics
Exactly. I think lists shouldn't be made of conses - or rather, by all
means implement them this way if it's convenient, but this should be
an implementation detail, it shouldn't show up in the language
semantics.
>but more precisely it's not reference
>semantics, it's "merely a place to put things at all" that have this
>property.
Different words, same idea.
>Would you also make arrays value-only because non-adjustable 0-length
>arrays, like #(), have what you (I think erroneously) call "value semantics"?
No, arrays need to be mutable because this is a very common and
important way of using them. I would make all arrays adjustable, but
that's another thing.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
················@eircom.net (Russell Wallace) writes:
...
> >but more precisely it's not reference
> >semantics, it's "merely a place to put things at all" that have this
> >property.
>
> Different words, same idea.
No, not at all. If (make-array 3) makes something with reference semantics
then so does (make-array 0). It's not like zero-length arrays are
implemented differently than 3-length ones. They are just not adjustable.
Incidentally, one problem with your odd notion of "value semantics" and
"reference semantics" is that UNINTERN can change the "semantics" of a data
structure (by making it suddenly impossible to store stuff in, and causing
you to think that "it's now got only value semantics" while I think (in
your apparent parlance) "it's still got reference semantics, just no place
to put anything". IMO, all objects in CL, even NIL, have reference semantics.
I wrote a longer post on this subject earlier, which somehow got lost.
Pity. It had lots of blood and gore in it, like is always so successful
in movie theaters these days. I'm just sure it would have gotten everyone's
attention...
On 07 Sep 2003 18:19:53 -0400, Kent M Pitman <······@world.std.com>
wrote:
>No, not at all. If (make-array 3) makes something with reference semantics
>then so does (make-array 0). It's not like zero-length arrays are
>implemented differently than 3-length ones. They are just not adjustable.
I could quibble about this, but if I did I could be correctly accused
of abstruse nitpicking, so I'll say I'm close enough to agreeing with
you for practical purposes, and move on :)
>Incidentally, one problem with your odd notion of "value semantics" and
>"reference semantics" is that UNINTERN can change the "semantics" of a data
>structure (by making it suddenly impossible to store stuff in, and causing
>you to think that "it's now got only value semantics" while I think (in
>your apparent parlance) "it's still got reference semantics, just no place
>to put anything".
Well, since you bring up UNINTERN, this is probably a good time for me
to say that I don't think symbols and strings should be different
things :)
>IMO, all objects in CL, even NIL, have reference semantics.
What about strings and numbers? Everything else does, I agree - my
argument is merely that they shouldn't :)
>I wrote a longer post on this subject earlier, which somehow got lost.
>Pity. It had lots of blood and gore in it, like is always so successful
>in movie theaters these days. I'm just sure it would have gotten everyone's
>attention...
That's a pity, don't suppose your newsreader saves a copy of outgoing
posts anywhere?
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
················@eircom.net (Russell Wallace) writes:
> Well, since you bring up UNINTERN, this is probably a good time for me
> to say that I don't think symbols and strings should be different
> things :)
And this is probably a good time to say that this means that you can't
write a text editor efficiently. Keyword symbols are mostly what Java calls
"canonical strings". Packaged symbols are a way of namespacing canonical
strings. But you can't have efficient string code if you think that strings
and symbols are the same. Maclisp used to do this. We had only
'|....|
for referring to strings, and this meant we had to seek out other datatypes
for efficiently managing text. That's silly. Strings were created to BE
text.
In any case, I surely think this is far afield from Scheme vs CL,
since this is something the languages agree upon.
> >IMO, all objects in CL, even NIL, have reference semantics.
>
> What about strings and numbers? Everything else does, I agree - my
> argument is merely that they shouldn't :)
Strings and numbers potentially do, too. Just no accessors that would
reveal it. An implementation is not precluded from offering such operators.
You should see the fun we used to have in Maclisp with rplaca and rplacd
on fixnums. Drew McDermott fussed loudly when in T (Yale Scheme) we didn't
let him have similar fun...
> >I wrote a longer post on this subject earlier, which somehow got lost.
> >Pity. It had lots of blood and gore in it, like is always so successful
> >in movie theaters these days. I'm just sure it would have gotten everyone's
> >attention...
>
> That's a pity, don't suppose your newsreader saves a copy of outgoing
> posts anywhere?
I saved it to disk on a computer across the state. When I'm back over there,
I'll see if I can find it.
On 08 Sep 2003 11:13:25 -0400, Kent M Pitman <······@world.std.com>
wrote:
>And this is probably a good time to say that this means that you can't
>write a text editor efficiently. Keyword symbols are mostly what Java calls
>"canonical strings". Packaged symbols are a way of namespacing canonical
>strings. But you can't have efficient string code if you think that strings
>and symbols are the same.
What sort of inefficiency are you thinking of? At first glance, as far
as I can see, it's just a matter of the implementation doing a few
unnecessary hash calculations on strings, not of turning an O(N)
algorithm into an O(N^2) one, but perhaps I'm missing something.
While I'm at it, let me add something you'll figure is even crazier:
as far as I can see, there's no reason why the language semantics (as
opposed to the implementation's internal workings) should distinguish
between strings and numbers.
>In any case, I surely think this is far afield from Scheme vs CL,
>since this is something the languages agree upon.
Think of it this way: I'm trying to bring about a feeling of peace and
brotherly love between the Common Lisp and Scheme communities by
giving them a common enemy to gang up on ^.~
>Strings and numbers potentially do, too. Just no accessors that would
>reveal it. An implementation is not precluded from offering such operators.
>You should see the fun we used to have in Maclisp with rplaca and rplacd
>on fixnums. Drew McDermott fussed loudly when in T (Yale Scheme) we didn't
>let him have similar fun...
lol!
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
················@eircom.net (Russell Wallace) writes:
> On 08 Sep 2003 11:13:25 -0400, Kent M Pitman <······@world.std.com>
> wrote:
>
> >And this is probably a good time to say that this means that you can't
> >write a text editor efficiently. Keyword symbols are mostly what Java calls
> >"canonical strings". Packaged symbols are a way of namespacing canonical
> >strings. But you can't have efficient string code if you think that strings
> >and symbols are the same.
>
> What sort of inefficiency are you thinking of? At first glance, as far
> as I can see, it's just a matter of the implementation doing a few
> unnecessary hash calculations on strings, not of turning an O(N)
> algorithm into an O(N^2) one, but perhaps I'm missing something.
(SETF (CHAR STRING 347) #\x)
> While I'm at it, let me add something you'll figure is even crazier:
> as far as I can see, there's no reason why the language semantics (as
> opposed to the implementation's internal workings) should distinguish
> between strings and numbers.
You want HyperTalk. It didn't make this distinction. (Note that this has
weird consequences on things like length("06") vs length("06"+1), btw. But
they bit the bullet and accepted them.) I'm not sure how they managed it
internally, but I have to believe there was a huge performance penalty
either in storage (keeping two representations together) or in speed
(converting back and forth on demand). Certainly HyperCard ran amazingly
slowly. I wrote a Yahtzee-like program in it, which is little more than
something that added up a dozen or two numbers (something even a 68000-class
computer, such as the early MacPlus and SE should have been able to do in
finite time), and it ran so slowly that a huge amount of the programming
ended up being oriented toward making sure it kept intermediate results and
only added up 5 or 10 numbers at once and not all dozen or two... Part of
this I attribute to what seemed like an almost O(n^3) access strategy for
what CL calls "places", which speed is mostly due to the fact that the
language was mostly running interpreted, but maybe partly the reason it ran
interpreted was how hard it was to compile it given the representation
choices. I don't know. So, indirectly, some of it may have come due to bad
number representations. It wasn't until the Quadra or so that this very
simple-minded program seemed to run tolerably fast, which was a little on
the ridiculous side.
> >In any case, I surely think this is far afield from Scheme vs CL,
> >since this is something the languages agree upon.
>
> Think of it this way: I'm trying to bring about a feeling of peace and
> brotherly love between the Common Lisp and Scheme communities by
> giving them a common enemy to gang up on ^.~
Heh.
Actually, during the design of T (Yale Scheme), Jonathan Rees and I
did indeed spend several weeks examining each and every Lisp data
structure and asking "does this really need to be here? is it cast
right?" and the question "are strings and symbols really distinct"
came up, but we concluded that symbols were really about naming more
than about stringness, that is, were about having fixed tokens that
could be used as canonical identifiers, and that strings were
something legitimately unrelated. (We did some work to make strings
have both char and chdr, so that you could operate on them more like
lists, using a veneer abstraction over a "byte pointer" in order to
get a single-object locus to a string+index instead of what Lisp
normally does with strings, having two use a string and a separated
fixnum. But that has nothing to do with the symbol/string
distinction... that was an independent issue we came up with once we
(re)separated the two and started considering the legitimate
operations on strings. There was no point to being able to chdr a
symbol.) As to the issue of what symbols were about, we concluded
differently that the choice of strings as the basis for identifiers
was accidental, and that in some sense any object might serve as a
canonical identifier. Consider:
(lambda (1 2) (+ (var 1) (var 2)))
or
(lambda ((thing 1) (thing 2))
(+ (var (thing 1)) (var (thing 2))))
That is, that
(lambda (foo bar) (+ foo bar))
is really just shorthand for
(lambda (foo bar) (+ (var foo) (var bar)))
and that the reason you can write it in the shorthand form is that it
happens that symbols are not already in use for something in the language.
The other thing, of course, is that symbols are good keys in a hash
table lookup, and again that's because of their uniqueness, not their
spelling. It's all about pointers. And again, everything has pointers,
so strings are not especially more symbol-like than anything else.
Anything with identity would be. What makes symbols different than
strings is that they are strings that have been run throuhg a hash table
in order to produce a canonical pointer. But if you put other objcts
through the same hash table, you'd get something just as good. Strings
are the (accidental) key to the hash table (package), not the output of
the hash table. The useful thing about symbols is not the key you used
in the lookup, it's the pointer you got after the lookup.
So, IMO, you're barking up the wrong tree here... even hypothetically.
I'm confident that if you proposed this for real, it'd be shouted down
by people just on incompatibility grounds. But I'm trying to convince
you, just because I think it's true, that even without compatibility
issues, your desire to revise this is just short-sighted.
On 08 Sep 2003 13:48:35 -0400, Kent M Pitman <······@world.std.com>
wrote:
>(SETF (CHAR STRING 347) #\x)
What does that do, exactly? And are you proposing keeping an entire
document in the form of a single string?
>You want HyperTalk. It didn't make this distinction. (Note that this has
>weird consequences on things like length("06") vs length("06"+1), btw. But
>they bit the bullet and accepted them.) I'm not sure how they managed it
>internally, but I have to believe there was a huge performance penalty
>either in storage (keeping two representations together) or in speed
>(converting back and forth on demand).
As far as I can see, the performance penalty should be negligible even
on the 68000-class machines you mention, let alone on today's that are
a thousand times more powerful. You're talking a few clock cycles
penalty every time you want to access the decimal representation of a
number, and this isn't done very often.
(If you say Hypercard was slow I'll take your word for it of course,
but I don't believe the unification of numbers and strings _required_
it to be slow.)
>Actually, during the design of T (Yale Scheme), Jonathan Rees and I
>did indeed spend several weeks examining each and every Lisp data
>structure and asking "does this really need to be here? is it cast
>right?" and the question "are strings and symbols really distinct"
>came up, but we concluded that symbols were really about naming more
>than about stringness, that is, were about having fixed tokens that
>could be used as canonical identifiers, and that strings were
>something legitimately unrelated. (We did some work to make strings
>have both char and chdr, so that you could operate on them more like
>lists, using a veneer abstraction over a "byte pointer" in order to
>get a single-object locus to a string+index instead of what Lisp
>normally does with strings, having two use a string and a separated
>fixnum. But that has nothing to do with the symbol/string
>distinction... that was an independent issue we came up with once we
>(re)separated the two and started considering the legitimate
>operations on strings. There was no point to being able to chdr a
>symbol.)
I'm afraid I don't understand how any of that provides a reason for
making symbols and strings different types, can you rephrase?
>As to the issue of what symbols were about, we concluded
>differently that the choice of strings as the basis for identifiers
>was accidental, and that in some sense any object might serve as a
>canonical identifier. Consider:
> (lambda (1 2) (+ (var 1) (var 2)))
>or
> (lambda ((thing 1) (thing 2))
I agree, I think those ought to work :)
>The other thing, of course, is that symbols are good keys in a hash
>table lookup, and again that's because of their uniqueness, not their
>spelling. It's all about pointers. And again, everything has pointers,
And again, I think symbols/strings/numbers/lists (oh, here's a bit
more craziness, I think semantically symbols/strings/numbers should be
lists of characters :)) should have value semantics, and the pointers
should be completely hidden behind the scenes.
>I'm confident that if you proposed this for real, it'd be shouted down
>by people just on incompatibility grounds.
*shocked look* You reckon? I mean, you're not just saying that, you
really think the Common Lisp and Scheme vendors wouldn't be
enthusiastic about changing the languages according to my suggestions?
And I was so looking forward to it, too!
(Add a liberal sprinkling of emoticons :))
>But I'm trying to convince
>you, just because I think it's true, that even without compatibility
>issues, your desire to revise this is just short-sighted.
Same way I'm trying to convince you my proposals would be the Right
Way, if we didn't have to worry about backwards compatibility, just
because I think it's true - well, that and because it's an interesting
conversation ^.^
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
················@eircom.net (Russell Wallace) writes:
> On 08 Sep 2003 13:48:35 -0400, Kent M Pitman <······@world.std.com>
> wrote:
>
> >(SETF (CHAR STRING 347) #\x)
>
> What does that do, exactly? And are you proposing keeping an entire
> document in the form of a single string?
I'm saying it's sometimes done. But even if it's just a single line
of a document, it's inefficient to have to cons (or look up) a whole
new line just to change a letter.
> >Actually, during the design of T (Yale Scheme), Jonathan Rees and I
> >did indeed spend several weeks examining each and every Lisp data
> >structure and asking "does this really need to be here? is it cast
> >right?" and the question "are strings and symbols really distinct"
> >came up, but we concluded that symbols were really about naming more
> >than about stringness, that is, were about having fixed tokens that
> >could be used as canonical identifiers, and that strings were
> >something legitimately unrelated. (We did some work to make strings
> >have both char and chdr, so that you could operate on them more like
> >lists, using a veneer abstraction over a "byte pointer" in order to
> >get a single-object locus to a string+index instead of what Lisp
> >normally does with strings, having two use a string and a separated
> >fixnum. But that has nothing to do with the symbol/string
> >distinction... that was an independent issue we came up with once we
> >(re)separated the two and started considering the legitimate
> >operations on strings. There was no point to being able to chdr a
> >symbol.)
>
> I'm afraid I don't understand how any of that provides a reason for
> making symbols and strings different types, can you rephrase?
I don't have time. It's not that important to me.
Good luck with what I wrote. Sorry.
On 08 Sep 2003 14:20:12 -0400, Kent M Pitman <······@world.std.com>
wrote:
>················@eircom.net (Russell Wallace) writes:
>
>> What does that do, exactly? And are you proposing keeping an entire
>> document in the form of a single string?
>
>I'm saying it's sometimes done.
I don't think it's generally done in pure form. Load a 100 megabyte
document and start typing at the beginning - the entire 100 megabytes
will have to be moved for every keystroke; this will incur noticeable
delays; you need to at least use the variant that maintains a gap in
the data.
>But even if it's just a single line
>of a document, it's inefficient to have to cons (or look up) a whole
>new line just to change a letter.
In this case it doesn't matter, the delay will be well below the
limits of perception in any event.
In either event though, my proposed system doesn't preclude the use of
arrays of characters - so you still have both immutable and mutable
strings (lists and arrays). Since you need both lists and arrays
anyway, this is the most parsimonious way to cover all the
requirements ^.^
>> I'm afraid I don't understand how any of that provides a reason for
>> making symbols and strings different types, can you rephrase?
>
>I don't have time. It's not that important to me.
>Good luck with what I wrote. Sorry.
Fair enough, thanks for trying.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
Kent M Pitman <······@world.std.com> wrote:
+---------------
| Consider:
| (lambda (1 2) (+ (var 1) (var 2)))
| or
| (lambda ((thing 1) (thing 2))
| (+ (var (thing 1)) (var (thing 2))))
+---------------
Heh! Funny you should mention. The most successful (so far) of
my many attempts at coming up with a usable reader macro shorthand
for LAMBDA provides implicitly-declared parameters with names of
$1, $2, &c., like a shell script. [The choice of "#$" as the reader
macro is supposed to be a reminder of that.] It's too ugly and
non-standard for code you might ever want to release to others,
but on the other hand it's sometimes kinda convenient if you're
just messing around interactively:
> (mapcar #$(* $1 3) '(1 8 4 2))
(3 24 12 6)
> (mapcar #$(cons $2 (1+ $1)) '(1 8 4 2) '(bill joe sally ted))
((BILL . 2) (JOE . 9) (SALLY . 5) (TED . 3))
> (remove-if #$(char= #\L (char (symbol-name $1) 2))
'(bill joe sally ted))
(JOE TED)
>
-Rob
p.s. Another flavor I tried, but never found as convenient
[since you still have to type the whole parameter list] was:
> (mapcar #[(x y) (cons y (1+ x))] '(1 8 4 2) '(bill joe sally ted))
((BILL . 2) (JOE . 9) (SALLY . 5) (TED . 3))
>
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Kalle Olavi Niemitalo
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <87wucj6ep5.fsf@Astalo.kon.iki.fi>
Kent M Pitman <······@world.std.com> writes: > IMO, all objects
in CL, even NIL, have reference semantics.
NIL is mutable as well: consider the property list.
················@eircom.net (Russell Wallace) writes:
> On Sat, 06 Sep 2003 18:25:37 GMT, ······@dtpq.com (Christopher C.
> Stacy) wrote:
>
> >I'm don't understand this suggestion, because Python's "dictionary"
> >type is a hash table, which I would not consider to be the same as a
> >list at all. CL has the same data type -- we call it a "hash table".
>
> Well yes, it's not the same as a list - on the contrary, for the
> particular purpose Kent suggested (acting as a lightweight aggregate
> data type) it's better. Therefore lists shouldn't be used for this,
> therefore this use is not a good argument for making lists mutable.
No, it's not. As someone reminded me of in private email today
(following up on this same discussion), part of what makes the lightweight
data structure of a list compelling is that in the early stages, you only
know that you need certain data but you often haven't gotten to naming the
reason why you needed it. So it's quite subtlely more powerful than it
seems because a hash table kind of requires you to name the key, and you
might either have a hard time naming that, or having hastily named it,
you might pigeon hole your thoughts about the use of the data while you
should be studying your uses without worrying about the name. Indexed
data structures are exactly the right thing here.
You might make a weak argument for arrays (as opposed to an argument
for weak arrays, heh), but both arrays and hash tables are also both
memory-wise and access-wise more storage overhead (in both space and
time) than is needed for accessing what is typically 1 or 2 or
sometimes 3-5 elements. So I stand by lists again even on this criterion.
You could also say that hash tables could be accessed by index as a
convention, but that seems mostly silly to me unless your language had
no difference between a numbered table and a keyed table, and if it didn't
have such a distinction, then you'd have destroyed again the opportunity
to make one of them heavy-weight/mutable and one light-weight/immutable.
On 06 Sep 2003 21:56:10 -0400, Kent M Pitman <······@world.std.com>
wrote:
>No, it's not. As someone reminded me of in private email today
>(following up on this same discussion), part of what makes the lightweight
>data structure of a list compelling is that in the early stages, you only
>know that you need certain data but you often haven't gotten to naming the
>reason why you needed it.
I find some sort of preliminary guess at the name is always better
than using an arbitrary number, because it provides a big increase in
clarity (which I find important even for exploratory programming), at
an insignificant cost in effort. Plus it's likely to be more unique
than FIRST/SECOND/etc and therefore less work to change later when I
come up with a better name. Plus in the case where I don't have time
to go back and clean up later even though I should (and let's face it,
that's unfortunately not a particularly rare occurrence), leaving the
preliminary guess at the name as is, is much more acceptable than
leaving FIRST/SECOND/etc.
I suppose this comes down to different styles though, and if your
style works for you, great. However, hash tables trivially support
your style (just use FIRST, SECOND etc as the keys) whereas lists
don't support mine.
>You could also say that hash tables could be accessed by index as a
>convention, but that seems mostly silly to me unless your language had
>no difference between a numbered table and a keyed table, and if it didn't
>have such a distinction, then you'd have destroyed again the opportunity
>to make one of them heavy-weight/mutable and one light-weight/immutable.
I don't understand you here - I think hash tables and arrays in
mutable form should both be supported, because there are very common
and important programming styles that make use of them. I think they
should both be distinct from lists (as they are in Common Lisp anyway
IIRC - so if you have mutable arrays, why do you need lists to be
mutable?). I think whether hash tables and arrays (both mutable)
should be distinct from each other is a separate question altogether
(and I can see valid arguments for both ways).
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
On Sun, Sep 07, 2003 at 11:43:02AM +0000, Russell Wallace wrote:
> I suppose this comes down to different styles though, and if your
> style works for you, great. However, hash tables trivially support
> your style (just use FIRST, SECOND etc as the keys) whereas lists
> don't support mine.
What's wrong with a-lists or p-lists? I find p-lists to be very
convenient, with GETF and (SETF GETF).
> I think [hashtables and arrays] should both be distinct from lists (as
> they are in Common Lisp anyway IIRC - so if you have mutable arrays,
> why do you need lists to be mutable?).
Single-dimension arrays (vectors) and lists are grouped under the
sequence type, so they aren't completely distinct. But I don't see any
reason that lists should be immutable in the fact that arrays are
mutable. Lisp isn't terribly concerned with immutability for the sake
of immutability, IMO.
> "Sore wa himitsu desu."
Nani himitsu desu ka?
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
On Sun, 7 Sep 2003 16:32:07 -0400, Matthew Danish
<·······@andrew.cmu.edu> wrote:
>Single-dimension arrays (vectors) and lists are grouped under the
>sequence type, so they aren't completely distinct. But I don't see any
>reason that lists should be immutable in the fact that arrays are
>mutable. Lisp isn't terribly concerned with immutability for the sake
>of immutability, IMO.
Well, I think lists should be immutable because this gives cleaner
semantics, and because mutable lists don't do anything arrays and hash
tables can't do better.
>Nani himitsu desu ka?
Translation, please? ^.^ (I don't actually speak more than the few
words of Japanese I've picked up from watching subtitled anime; my
current signature is a quote from 'Slayers Next'.)
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
················@eircom.net (Russell Wallace) writes:
> On Sun, 7 Sep 2003 16:32:07 -0400, Matthew Danish
> <·······@andrew.cmu.edu> wrote:
>
> >Single-dimension arrays (vectors) and lists are grouped under the
> >sequence type, so they aren't completely distinct. But I don't see any
> >reason that lists should be immutable in the fact that arrays are
> >mutable. Lisp isn't terribly concerned with immutability for the sake
> >of immutability, IMO.
>
> Well, I think lists should be immutable because this gives cleaner
> semantics, and because mutable lists don't do anything arrays and hash
> tables can't do better.
Someone at the (then) Lab for Computer Science (not sure, maybe Pete
Szolovitz and the medical decision making group? Or something by Hal
Abelson? it wasn't something i used--just something i heard about),
did an embedded lisp language substrate that had unique conses under
an operation called UCONS. It had some weird consequences but got
used for some things, I'm not sure with what success. It's always
better to review history before repeating it. Something in my brain
is trying to relate it to the "Boxer" project [programming with "boxed
expressions", not some sort of violent slugfest], but I can't remember
if it was an implementation substrate for boxer or was unrelated.
From: Matthew Danish
Subject: translation [was Re: Why some people think that Scheme is not a Lisp]
Date:
Message-ID: <20030909013613.GU1454@mapcar.org>
On Mon, Sep 08, 2003 at 06:46:20AM +0000, Russell Wallace wrote:
> On Sun, 7 Sep 2003 16:32:07 -0400, Matthew Danish
> <·······@andrew.cmu.edu> wrote:
> >Nani himitsu desu ka?
> Translation, please?
With my pidgin Japanese, I think I managed to say ``What secret?''
Though perhaps I should've said ``Dore ga himitsu desu ka?'' (Which,
of these many things, is the secret?).
> "Sore wa himitsu desu."
``As for this thing (near me), it is a secret.''
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
················@eircom.net (Russell Wallace) writes:
> Well, I think lists should be immutable because this gives cleaner
> semantics, and because mutable lists don't do anything arrays and hash
> tables can't do better.
If arrays and hash tables can be used instead of mutable lists, then
they can be used instead of immutable lists too (just don't modify
them). So by your logic there's no need for lists at all?
--
Janis Dzerins
Common Lisp -- you get more than what you see.
On 10 Sep 2003 11:53:25 +0300, Janis Dzerins <·····@latnet.lv> wrote:
>If arrays and hash tables can be used instead of mutable lists, then
>they can be used instead of immutable lists too (just don't modify
>them). So by your logic there's no need for lists at all?
Except that to define arrays and hash tables, you need to have some
notion of values, and you can't use arrays and hash tables for this
without getting a circular definition. If you have immutable lists and
a finite alphabet of characters, you can define strings, symbols and
numbers in terms of these; as far as I can see, this gets you the
cleanest semantics while still providing all the important
capabilities.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
················@eircom.net (Russell Wallace) writes:
> On 10 Sep 2003 11:53:25 +0300, Janis Dzerins <·····@latnet.lv> wrote:
>
> >If arrays and hash tables can be used instead of mutable lists, then
> >they can be used instead of immutable lists too (just don't modify
> >them). So by your logic there's no need for lists at all?
>
> Except that to define arrays and hash tables, you need to have some
> notion of values, and you can't use arrays and hash tables for this
> without getting a circular definition.
Array and hashtable values are represented as lists or what? What's
the problem with these:
'(1 one 2 two 3 three)
#(1 one 2 two 3 three)
#{1 one 2 two 3 three}
In what way the second and third expression can't be expressed? I
think you still have not answered my question: do you claim that
there's no need for lists?
> If you have immutable lists and a finite alphabet of characters, you
> can define strings, symbols and numbers in terms of these; as far as
> I can see, this gets you the cleanest semantics while still
> providing all the important capabilities.
Numbers are lists of characters? What's the point of this kind of
"clean semantics"? Which capabilities are important and which are
not?
--
Janis Dzerins
Common Lisp -- you get more than what you see.
On Sun, 7 Sep 2003 16:32:07 -0400, Matthew Danish wrote:
>> "Sore wa himitsu desu."
> Nani himitsu desu ka?
That's a secret :-)
--
Just because we Lisp programmers are better than everyone else is no
excuse for us to be arrogant. -- Erann Gat
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
················@eircom.net (Russell Wallace) writes:
> I've forgotten most of what little MOO code I knew, but what was
> heavyweight about objects? I vaguely recall it being just a matter of
> ·@create foo', no mucking around with classes or anything.
Well, @create is an interactive interface. You mean create(). But the
problem is that the objects aren't auto-gc'd. They stay around and have
to be manually recycled . So if you're using them as low-tech temporary
interfaces, it's kind of a lot of overhead...
On 06 Sep 2003 21:49:53 -0400, Kent M Pitman <······@world.std.com>
wrote:
>Well, @create is an interactive interface. You mean create().
Right. Told you I'd forgotten most of what little I once knew of MOO
code :)
>But the
>problem is that the objects aren't auto-gc'd. They stay around and have
>to be manually recycled . So if you're using them as low-tech temporary
>interfaces, it's kind of a lot of overhead...
Oh, good point. Yeah, you definitely want a GC-able aggregate type.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <7k4n8bhv.fsf@comcast.net>
Kent M Pitman <······@world.std.com> writes:
> And so since CL doesn't externalize for its core semantics, while
> Scheme does, I claim there is a fundamentally "better definedness"
> about CL than Scheme if you believe identity per se is a core concept.
> Of course, if you think identity of the program doesn't matter, as I
> perceive Will does, then none of this matters to you. But you should
> not confuse this with thinking none of this matters to anyone. _That_
> just means not everyone has the same priorities, but that's the whole
> thing that started this discussion--to see why differences in
> priorities led to different design.
Actually, I believe that it *does* matter, but that there is no clear
solution (other than, perhaps, a global shared address space under
which nothing is externalized, ever). I believe that the Scheme
report authors were unable to come to a consensus about what was `the
right thing' in this matter, so they deliberately left it unspecified.
> So you should feel enlightened.
If only people would stop hitting me over the head with the `chinual.
·············@comcast.net writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > When I was a graduate student I did my master's thesis on something called
> > "the problem of referential transparency".
>
> > knows(Mary, phone-of(Bill))
> > phone-of(Bill) = phone-of(John)
> >
> > This problem has for unfathomable reasons attracted the attention of
> > philosophers for a hundred years.
>
> That's because they so frequently get it wrong. If you could go back
> in time and give these philosophers a course in computing, imagine how
> much simpler (and understandable) philosophy would be.
But if John and Bill are partners, then (until an eventual split-up),
(eq (phone-of 'bill) (phone-of 'john)) => T. We just don't have enough
information to judge if they are equivalent or just equal.
//Ingvar
--
(defun m (a b) (cond ((or a b) (cons (car a) (m b (cdr a)))) (t ())))
Erann Gat wrote:
> In article <···················@newsread2.news.atl.earthlink.net>,
> "Anton van Straaten" <·····@appsolutions.com> wrote:
>
> > The fact that Scheme's semantics differ from CL's in this respect
> > is not a consequence of the semantics of programs being defined
> > on lists.
>
> OK, I think I understand now why you believe this, but I still think
> you're wrong. (Actually, I know you're wrong.)
Perhaps with this post, I can shake the foundations of your knowledge. :)
> Let me tell you a story.
I enjoyed the story, thanks, and it does help to explain your position, well
enough that I think I can explain mine.
To summarize broadly, I think the reason you "know" I'm wrong, while I
persist in knowing I'm right, is that you're applying a theoretical &
logical notion of object equality to an operation, EQ?, which is explicitly
acknowledged by the Scheme spec to exist for performance reasons - a
concession to the reality of machines and implementations. From a
theoretical & logical point of view, EQ? should simply not exist.
You've pointed out that Scheme's EQ? behaves differently from CL's EQ, and
your theoretical predisposition understandably causes you to favor CL's EQ.
However, they represent different models of equality, and your postulate
about the "consequence" of "the semantics of programs being defined on
lists" assumes a model in which your idea of object equality and the meaning
of quoting holds. In your model, the "consequence" in question holds, of
course, but it doesn't necessarily hold in other models. I've essentially
been pointing out that yours is not the only possible model, and more
specifically, it's not the model that Scheme follows, and further, that the
Scheme model is not necessarily a consequence of whether its semantics are
defined on lists.
Earlier, I characterized my point by saying "It seems that a further
assumption may be being bundled into this statement, which is that "literal
data specified in a program denotes itself"". I seem to have been correct
in saying that: you do seem to be assuming that literal data *should* denote
itself (as opposed to something that "looks like" itself). I'm just saying
that this doesn't have to be the case, and Goedel, McCarthy and Gat's
insights about quoting and object equality notwithstanding, I'm saying that
EQ? is based on a notion of equality that makes concessions to issues that
fall outside the constraints imposed by theoretical & logical notions of
equality.
To get a bit more specific, in an imaginary Scheme (or Lisp) with semantics
defined on lists, this same equality design might still have been chosen,
for the same kinds of reasons (for example, to simplify procedure inlining
by compilers). Conversely, in actual Scheme, without semantics defined on
lists, the EQ semantics you consider desirable could have been defined, by
defining QUOTE, EQ and object identity appropriately.
You seem to argue against Scheme having made a conscious choice of the sort
I've just described:
> When CL says quote "returns X" it means that it returns X *itself*.
> When Scheme says quote "returns X" it means that it returns
> something that just happens to look like X. But the *reason*
> that Scheme says this is not because it makes conscious
> choice of these semantics over other semantics, it is because
> the object X *does not exist as a concept* in the extant
> presentation of Scheme's semantics.
However, I don't see why the object X couldn't *be defined as a concept* in
a semantics, without resorting to defining the semantics of programs on
lists. The reason that Scheme didn't do so may certainly relate to its
attitude towards the nature of programs, but it is not an inevitable
consequence of that.
> The (eq (foo) (foo)) example only serves to demonstrate that this design
> decision does in fact have practical consequences despite the fact that
> the syntax for Scheme code is a sub-language of the syntax for Scheme
> data. Other than that it is, as someone else said earlier, a red herring.
As you can tell by now, I still disagree that this is in fact a consequence
of the design decision in question. If it were a consequence, as I have
previously mentioned, I would consider it to represent a failure of the
Scheme spec's abstraction of the structure of programs.
Anton
In article <·····················@newsread2.news.atl.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
> To summarize broadly, I think the reason you "know" I'm wrong, while I
> persist in knowing I'm right, is that you're applying a theoretical &
> logical notion of
No, the reason I know you're wrong is that I'm not applying theoretical
and logical notions of anything. I'm talking about the meaning of the
Scheme standard, which is a natural language text.
> From a
> theoretical & logical point of view, EQ? should simply not exist.
Really? How else are you going to be able to tell if, given two bindings,
mutating the value of one will result in a change in the value in the
other?
> You've pointed out that Scheme's EQ? behaves differently from CL's EQ
No it doesn't. They both behave exactly the same. It's QUOTE that's different.
> I'm saying that
> EQ? is based on a notion of equality that makes concessions to issues that
> fall outside the constraints imposed by theoretical & logical notions of
> equality.
Yes, and I'm saying you're wrong. But I don't care enough to spend a
great deal more time trying to change your mind. So...
TTFN.
E.
Erann Gat wrote:
> "Anton van Straaten" <·····@appsolutions.com> wrote:
>
> > To summarize broadly, I think the reason you "know" I'm wrong, while I
> > persist in knowing I'm right, is that you're applying a theoretical &
> > logical notion of
>
> No, the reason I know you're wrong is that I'm not applying theoretical
> and logical notions of anything. I'm talking about the meaning of the
> Scheme standard, which is a natural language text.
The point I questioned has to do with you claim of "consquences" between one
feature and another in the standard. To address that, we have to talk about
alternative possibilities to find out whether the Scheme feature in question
is in fact a "consequence" of some other decision.
I'm saying you're applying a model with an assumption of a certain identity
behavior, but that this is only one possible model, no matter how appealing
it may be, and you can't apply it implicitly without acknowledging that
you're doing so. Once you acknowledge that you're applying this model, the
"consequence" you claim is no longer a consequence, it's only a consequence
in the presence of a specific model which Scheme doesn't necessarily adhere
to.
> > From a
> > theoretical & logical point of view, EQ? should simply not exist.
>
> Really? How else are you going to be able to tell if, given two bindings,
> mutating the value of one will result in a change in the value in the
> other?
I retract that, it was too strong and doesn't properly communicate my point
anyway. See below for clarification. The last paragraph is enough,
actually.
> > You've pointed out that Scheme's EQ? behaves differently from CL's EQ
>
> No it doesn't. They both behave exactly the same. It's QUOTE that's
different.
I meant that in the same way as you've been using "consequences": EQ?
behaves differently in the case of (eq? (foo) (foo)), as a consequence of
the QUOTE behavior. You're picking at the form of my argument in my latest
post, without addressing the real point.
> > I'm saying that
> > EQ? is based on a notion of equality that makes concessions to issues
that
> > fall outside the constraints imposed by theoretical & logical notions of
> > equality.
>
> Yes, and I'm saying you're wrong. But I don't care enough to spend a
> great deal more time trying to change your mind. So...
>
> TTFN.
Seems to me I was really close to pinning down the issue in question in a
way that you would understand. Oh well. I'll take another stab anyway.
I'll rephrase my quote above to say that "I'm saying that Scheme's notion of
object identity makes concessions to issues that fall outside the
constraints imposed by theoretical & logical notions of identity". Change
"theoretical & logical" to whatever you want to use as your justification
for QUOTE returning the quoted value "itself".
Regardless of how you phrase this, the point is that the QUOTE behavior you
want to *assume* leads to your seeing and describing a "consequence", where
there is no such consequence in the absence of that assumption.
More specifically, your assumption about how QUOTE should work when the
semantics of programs are defined on lists, doesn't necessarily apply if the
choice is made to e.g. allow compilers to inline procedures as they see fit.
Therefore, defining the semantics of programs on lists does not have the
consequence you've previously, and repeatedly, claimed.
Anton
Erann Gat <···@jpl.nasa.gov> wrote:
+---------------
| Let me tell you a story.
| When I was a graduate student I did my master's thesis on something called
| "the problem of referential transparency". It has to do with avoiding
| unwanted conclusions in AI systems based on formal logic. The classic
| example is, "Mary knows Bill's phone number" and "Bill's phone number is
| the same as John's phone number." From this one does not want to conclude
| that Mary knows John's phone number, but under standard formal logic this
| conclusion is unavoidable if one models these two statements as:
|
| knows(Mary, phone-of(Bill))
| phone-of(Bill) = phone-of(John)
+---------------
It seems obvious that those two statements are in fact *not* a
good model of the situation of interest. They should be instead:
knows(Mary, belongs-to(phone-of(Bill), Bill))
and:
phone-of(Bill) = phone-of(John)
While from those two you *can* conclude that:
knows(Mary, belongs-to(phone-of(John), Bill))
you cannot conclude that:
knows(Mary, belongs-to(phone-of(John), John))
nor:
knows(Mary, belongs-to(phone-of(Bill), John))
nor:
knows(Mary, phone-of(Bill) = phone-of(John))
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <······················@speakeasy.net>, ····@rpw3.org (Rob
Warnock) wrote:
> Erann Gat <···@jpl.nasa.gov> wrote:
> +---------------
> | Let me tell you a story.
> | When I was a graduate student I did my master's thesis on something called
> | "the problem of referential transparency". It has to do with avoiding
> | unwanted conclusions in AI systems based on formal logic. The classic
> | example is, "Mary knows Bill's phone number" and "Bill's phone number is
> | the same as John's phone number." From this one does not want to conclude
> | that Mary knows John's phone number, but under standard formal logic this
> | conclusion is unavoidable if one models these two statements as:
> |
> | knows(Mary, phone-of(Bill))
> | phone-of(Bill) = phone-of(John)
> +---------------
>
> It seems obvious...
You'd think, wouldn't you? You'd be amazed how adept philosophers are at
obfuscating simple issues.
E.
From: Kenny Tilton
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <3F59FEC7.2030701@nyc.rr.com>
Erann Gat wrote:
>>That's a nice description, which I agree with. In particular, you described
>>the causal relationship the right way around: "It is also quite clear that
>>the CL definition necessitates a list structure syntax containing Lisp
>>objects", not vice versa as Erann seemed (to me) to have been saying.
>
>
> Then you have clearly misunderstood what I have been saying (not that this
> is news) because what I have been saying is exactly the same thing that
> Matthew said (though he apprently said it better than I did).
>
> I'd be interested to know what I said that gave you the impression that I
> intended the opposite causality because that was never my intent.
What marvelous alchemy, and a breakthrough in the Art of Unending
Thread: agreement transformed into a source of ongoing debate.
I'm looking forward to this one.
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
·····················@nyc.rr.com...
>
> Erann Gat wrote:
> >>That's a nice description, which I agree with. In particular, you
described
> >>the causal relationship the right way around: "It is also quite clear
that
> >>the CL definition necessitates a list structure syntax containing Lisp
> >>objects", not vice versa as Erann seemed (to me) to have been saying.
> >
> >
> > Then you have clearly misunderstood what I have been saying (not that
this
> > is news) because what I have been saying is exactly the same thing that
> > Matthew said (though he apprently said it better than I did).
> >
> > I'd be interested to know what I said that gave you the impression that
I
> > intended the opposite causality because that was never my intent.
>
> What marvelous alchemy, and a breakthrough in the Art of Unending
> Thread: agreement transformed into a source of ongoing debate.
>
> I'm looking forward to this one.
>
Uncle!
The money is in the basement, my friends with the radio are in the attic -
please no more scheme is less filling VS Common Lisp tastes great
discussions.
-R. Scott McIntire
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <8yp5wqso.fsf@comcast.net>
Matthew Danish <·······@andrew.cmu.edu> writes:
> On Wed, Sep 03, 2003 at 01:19:45PM +0000, Anton van Straaten wrote:
>> I'm trying to point out that it's *not* a sufficient condition. The
>> appropriate specification for the semantics of QUOTE are also required, and
>> this seems to be the primary issue.
>
> CL:
>
> ``quote object => object
>
> object---an object; not evaluated.
>
> The quote special operator just returns object.''
>
>
> Scheme:
>
> ``syntax: quote <datum>
> syntax: '<datum>
> syntax: <constant>
>
> `(quote <datum>)' evaluates to <datum>. <Datum> may be any external
> representation of a Scheme object.''
>
> ``An important concept in Scheme (and Lisp) is that of the external
> representation of an object as a sequence of characters.[...]
> An external representation may be written in a program to obtain the
> corresponding object (see quote)''
I can see where people are getting confused. The first statement is
simply wrong, despite it being in the standard.
As shown in section 7, <datum> is a far richer structure than `a
sequence of characters'. If it *were* simply a sequence of
characters, then <datum> is identical to <string> (section 6.3.5).
But if all <datum> is <string>, then no <datum> is <pair>, <number>,
etc. etc. (because the types are required to be disjoint).
This would render the bulk of the standard meaningless because
there would only be the string type.
·············@comcast.net writes:
> > CL:
> >
> > ``quote object => object
> >
> > object---an object; not evaluated.
> >
> > The quote special operator just returns object.''
> >
> >
> > Scheme:
> >
> > ``syntax: quote <datum>
> > syntax: '<datum>
> > syntax: <constant>
> >
> > `(quote <datum>)' evaluates to <datum>. <Datum> may be any external
> > representation of a Scheme object.''
> >
> > ``An important concept in Scheme (and Lisp) is that of the external
> > representation of an object as a sequence of characters.[...]
> > An external representation may be written in a program to obtain the
> > corresponding object (see quote)''
>
> I can see where people are getting confused. The first statement is
> simply wrong, despite it being in the standard.
>
> As shown in section 7, <datum> is a far richer structure than `a
> sequence of characters'. If it *were* simply a sequence of
> characters, then <datum> is identical to <string> (section 6.3.5).
> But if all <datum> is <string>, then no <datum> is <pair>, <number>,
> etc. etc. (because the types are required to be disjoint).
> This would render the bulk of the standard meaningless because
> there would only be the string type.
Notwithstanding any of what you've said, the real issue here is that the
mapping from objects to printed representations is not 1 to 1. There are
objects in Scheme which share printed representation and there is no
explanation of how this is resolved.
Having sat on the authors committee for some years, I don't claim to
be empowered to speak for the authors but I feel qualified to render
at least one of possibly many points of view as to why this mapping
information is absent. My personal opinion is that the committee
did not spell this out because it feared bloat.
It's probably obvious just by looking, but I (at least) did not consider
length to be an issue in specifying Common Lisp. The spec definitely
grew in size by several hundred pages during my tenure, in part because of
the addition of CLOS, LOOP, and Conditions but perhaps also because I'm
just more verbose than some other people. I figured it was better to get
the specification written down and then worrying about tuning it.
The Scheme committee has always seemed to me to work backward of this, both
textually and technically. Textually in the sense that if we couldn't
express something concisely enough, I think we often just left it out.
I asked for specifications of porting behaviors and branch cuts and all
kinds of error conditions, and was told that this would bloat things too
much, just as an example. If one wants to compare CLTL and ANSI CL in terms
of "document quality" (as distinct from "presentational style" or
"overall functionality offered"), I think the key difference was that ANSI
CL reacted to the _clear_ request from its users that we not only make it
_look_ like things were portable but really try to refine that in the places
where there were known porting issues, either by explaining the porting
behavior or by what I always called "explicit vagueness" (saying in explicit
text that there was a looming portability issue not resolved by the standard
and left to the vendor or the user to resolve). We didn't fix all such
problems, but we did all that we could within the budget available.
I think in terms of document quality, in spite of the redudant and potentially
confusing/conflicting presence of a formal semantics, the Scheme spec (all
of them, actually) are at CLTL level, in the sense that they are more
concerned with the appearance of portability than the practice of portability.
I don't think Scheme ever (except at the vendor level, and partly via the
SRFI system, which appears to me to have been a desperate end-run by
practical-minded people to circumvent the language designers) got to the ANSI
CL level of "caring about portability". I suppose, as a personal opinion,
that's partly a subjective assessment, but ironically, it arises out of my
best attempt to be as objective as possible about the differences between
the two specifications.
Back to the original point, the CL specification uses objects, not text,
as the basis for its semantics exactly because it is possible to get past
the non-1-to-1 nature of text->object->text->object that Scheme confronts.
By defining things in terms of the objects, we get wholly around the messy
issue that it's hard to make printed representations for some objects;
the cost in doing it the other way around is that you don't allow the full
use of all objects in all cases because not all have reliable
print-read-print-read transformability.
Kent M Pitman wrote:
> I think in terms of document quality, in spite of the redudant and potentially
> confusing/conflicting presence of a formal semantics, the Scheme spec (all
> of them, actually) are at CLTL level, in the sense that they are more
> concerned with the appearance of portability than the practice of portability.
It might be worthwhile to note that in academia, portability is not
nearly as important as in industry. For academic purposes, a concise
description is more important than one that describes all corner cases.
The reason for some of the problems that arise during discussions about
CL vs. Scheme probably stem from the fact that these two languages serve
different purposes but that this is not recognized. The problems come up
as soon as practitioners judge Scheme, and academics CL, from their
respective perspectives.
For example, from an academic perspective, recursion is not only enough,
but furthermore has the nice property that you can prove properties
about algorithms that use recursion that you can't prove that easily
when using iteration. Vice versa, from a practitioners perspective, side
effects are not just convenient, but furthermore they allow one to model
real-world problems in much more direct way.
A language should only be judged by its own standard, i.e. does it
achieve the goals it was designed for. Probably both Common Lisp and
Scheme are excellent in this regard.
Pascal
P.S.: This doesn't mean that Scheme should not be used in industry and
CL should not be used in academia. A good language can transcend its
original goals.
Pascal Costanza <········@web.de> writes:
> The reason for some of the problems that arise during discussions
> about CL vs. Scheme probably stem from the fact that these two
> languages serve different purposes but that this is not
> recognized. The problems come up as soon as practitioners judge
> Scheme, and academics CL, from their respective perspectives.
> ...
> A language should only be judged by its own standard, i.e. does it
> achieve the goals it was designed for. Probably both Common Lisp and
> Scheme are excellent in this regard.
Well, I don't want to dive too deep here because I don't want to beat
too hard on the "detract from Scheme" bandwagon, but I think any claim
that Scheme is only for academics is disingenuous. Yet I also think a
lot of the language design can be shown to target academics with
unfairly heavy emphasis, that is, to the detriment of practitioners.
Vendors of Scheme took up the slack, but the result is not nearly as
consistent a language in practice as in theory. Consequently, I think
that any fair analysis on the basis of goals has to have a fixed set
of goals to compare to, and I find that the goals of Scheme are much
more slippery than the goals of CL. CL went out on a limb and said
who it was they were catering to and what they thought they needed to
accomplish; Scheme advocates escape the issue of portability by
appealing to the "academic nature" and then whine when one refers to
Scheme as "for academics, not practitioners". If it's for
practioners, I think it really is missing something and it's unfair
not to acknowledge this.
Kent M Pitman wrote:
> Consequently, I think
> that any fair analysis on the basis of goals has to have a fixed set
> of goals to compare to, and I find that the goals of Scheme are much
> more slippery than the goals of CL.
Sure. Research has slippery goals. Otherwise it wouldn't be research.
So no, I don't agree with the first part of your statement (wrt fixed
set of goals).
"If we knew what it was we were doing, it would not be called research,
would it?" - Albert Einstein
Pascal
From: Christopher C. Stacy
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <uu17tp2yt.fsf@dtpq.com>
>>>>> On Wed, 03 Sep 2003 23:38:21 +0200, Pascal Costanza ("Pascal") writes:
Pascal> For example, from an academic perspective, recursion is not only
Pascal> enough, but furthermore has the nice property that you can prove
Pascal> properties about algorithms that use recursion that you can't prove
Pascal> that easily when using iteration.
I thought the one of the points of SICP was that recursion is
equivalent to iteration. If you can't prove something in the
other notation, isn't that just a problem with the notation?
Christopher C. Stacy wrote:
>>>>>>On Wed, 03 Sep 2003 23:38:21 +0200, Pascal Costanza ("Pascal") writes:
>
> Pascal> For example, from an academic perspective, recursion is not only
> Pascal> enough, but furthermore has the nice property that you can prove
> Pascal> properties about algorithms that use recursion that you can't prove
> Pascal> that easily when using iteration.
>
> I thought the one of the points of SICP was that recursion is
> equivalent to iteration. If you can't prove something in the
> other notation, isn't that just a problem with the notation?
Common Lisp and Scheme are different in this regard. Common Lisp uses
side effects for iteration variables and Scheme uses parameter passing.
So in Scheme, iteration is indeed equivalent to iteration whereas in
Common Lisp it isn't.
See http://groups.google.com/groups?selm=3244459363713506%40naggum.no
for an example.
The important point here is about side effects. Side effects make things
harder to prove.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> Common Lisp and Scheme are different in this regard. Common Lisp uses side
> effects for iteration variables and Scheme uses parameter passing. So in
> Scheme, iteration is indeed equivalent to iteration whereas in Common Lisp it
> isn't.
>
> See http://groups.google.com/groups?selm=3244459363713506%40naggum.no for an
> example.
I recall this thread. There is an important point to remember: the iteration
style is not necessarily "inherent" to the nature of CL or Scheme. One can
write macros that express one language's iteration style in the other.
View the thread for details and discussion.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
The world rejoiced as Pascal Costanza <········@web.de> wrote:
> Christopher C. Stacy wrote:
>>>>>>>On Wed, 03 Sep 2003 23:38:21 +0200, Pascal Costanza ("Pascal") writes:
>> Pascal> For example, from an academic perspective, recursion is not
>> only
>> Pascal> enough, but furthermore has the nice property that you can prove
>> Pascal> properties about algorithms that use recursion that you can't prove
>> Pascal> that easily when using iteration.
>> I thought the one of the points of SICP was that recursion is
>> equivalent to iteration. If you can't prove something in the
>> other notation, isn't that just a problem with the notation?
>
> Common Lisp and Scheme are different in this regard. Common Lisp uses
> side effects for iteration variables and Scheme uses parameter
> passing. So in Scheme, iteration is indeed equivalent to iteration
> whereas in Common Lisp it isn't.
But this seems to me to miss the point of what SICP was teaching,
namely that iteration is equivalent to recursion.
What is unfortunate is that some people pick out of that the notion
that everyone should always express iteration via recursion, simply
because it is possible. (And because their only course on the subject
pointed them to look at it that way.)
What is also unfortunate is that the counterreaction seems to involve
a denial of the equivalence...
--
select 'cbbrowne' || ·@' || 'ntlug.org';
http://www3.sympatico.ca/cbbrowne/
I would rather be in the back of a car then a cdr.
-- Blackboard in 6.011 area
Christopher Browne <········@acm.org> writes:
> What is unfortunate is that some people pick out of that the notion
> that everyone should always express iteration via recursion, simply
> because it is possible. (And because their only course on the subject
> pointed them to look at it that way.)
>
> What is also unfortunate is that the counterreaction seems to involve
> a denial of the equivalence...
you have to take the language context into account. there are two
"equivalence metrics" involved here. one is the actual semantic
equivalence (which holds in Scheme and other languages with TCO, but
not in CL), and the other is the notational equivalence (which, if
true, would mean that recursion and iteration, as seen in program
source code, are equally "natural"). notational equivalence is fuzzy,
unscientific, and usually doesn't hold in any language. :)
--
Roses are red,
Violets are blue,
I'm schizophrenic...
And I am too.
> > What is unfortunate is that some people pick out of that the notion
> > that everyone should always express iteration via recursion, simply
> > because it is possible. (And because their only course on the subject
> > pointed them to look at it that way.)
It's not so much because its possible, but because its the blatently
correct solution. Since recursion can express everything iteration
can, without requiring additional primitives (function application is
already needed) iteration is superfuous. Eliminating another primitive
is a strong case for not having iteration in the language proper. Now,
expression something via an iteration is probably convenient very
often, but in a language with a proper macro system, you can wrap that
in a macro if you want to.
From: Paul F. Dietz
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <xiadnaDSjII6f8SiU-KYvA@dls.net>
Rayiner Hashem wrote:
> Eliminating another primitive
> is a strong case for not having iteration in the language proper.
Why as a user should I care whether a language feature can be
omitted from some irreduciably minimal core? I *want* the common idioms
that can be built on top of that core to be standardized, and it's
just fine with me if that means they're part of the language definition.
IMO, one of Common Lisp's problems is that it's *too small*. I want
more stuff standardized in the language (or, in a single set of standardized
libraries, which in practice amounts to the same thing), not less.
Paul
> Why as a user should I care whether a language feature can be
> omitted from some irreduciably minimal core?
A user might not, but a language designer should. So should a language
implementor, and anyone who works with tools (source browsers, IDEs,
etc) for that language.
> I *want* the common idioms
> that can be built on top of that core to be standardized
There is nothing to stop that if you have a minimal core.
, and it's
> just fine with me if that means they're part of the language definition.
This, however, is unnecessary.
> I want more stuff standardized in the language (or, in a single set of
> standardized libraries, which in practice amounts to the same thing)
The two scenarios do not amount to the same thing. The only thing in
the language standard should be stuff that absolutely needs
implementation support to be implemented effectively. This keeps the
language core lightweight, easier to implement, and allows for the
language standard to go long periods without updates. Now, a seperate
standard library can be defined which encompasses all of the useful
features that people use everyday: macros to add support for stuff
like iteration, exception handling, generators, etc, and libraries to
handle things like GUI, networking --- along the lines of the Java
class library. There are a few advantages to this model. It keeps the
language cleanly seperated from libraries, and also allows people to
more easily provide replacements for standard libraries. Having many
libraries available fosters competition between libraries for the best
implementation. The main advantage is that this model means that the
standard library can be updated independent of the language standard.
This avoids some silliness we've seen in the C++ world. C++ users have
to wait several years for the next standard for the Boost libraries
(which *really* belong in the standard library) to be standardized.
Also, this allows incompleteness in the standard library (again, in
C++, the functional aspects were added rather late, and the functional
library was incomplete) in a timely fashion.
Rayiner Hashem <·······@mindspring.com> wrote:
> > Why as a user should I care whether a language feature can be
> > omitted from some irreduciably minimal core?
> A user might not, but a language designer should. So should a language
> implementor, and anyone who works with tools (source browsers, IDEs,
> etc) for that language.
The language users pay the language implementors. If the implementor's
goal is not to please the language users, then something is wrong.
No user (except perhaps pure language research users) cares about an
irreducible core, so the question is whether having a standardized
feature is worth the extra time it takes to implement. For anything
that a lot of people in disparate coding worlds will want to build, I'd
say yes. For anything that *everyone* in a particular, common coding
world will want to build, the answer is also yes. In practice, serious
implementations have built many of the things that meet these criteria
even when they were not standardized. Which means that you then have a
bunch of different kinds of code out there doing essentially the same
thing that is not portable. If one of the choices were standardized,
then code that used it would be completely portable.
> > I *want* the common idioms
> > that can be built on top of that core to be standardized
> There is nothing to stop that if you have a minimal core.
But you're claiming that things which aren't in that minimal set should
be removed from the standard. That makes sense only if said features
are somewhat crufty or little used, or if your language spec is intended
as an academic gem, rather than as an industrial programming language.
> , and it's
> > just fine with me if that means they're part of the language definition.
> This, however, is unnecessary.
Without some kind of layered library standards, it most certainly is
necessary. When you put it in the standard (or a generally accepted
standardized library layer), implementors will implement to that
standard, and code using it will be portable. If you don't,
implementors will roll their own and nothing is portable.
> > I want more stuff standardized in the language (or, in a single set of
> > standardized libraries, which in practice amounts to the same thing)
> The two scenarios do not amount to the same thing. The only thing in
> the language standard should be stuff that absolutely needs
> implementation support to be implemented effectively. This keeps the
> language core lightweight, easier to implement, and allows for the
> language standard to go long periods without updates.
But you essentially have that in the Common Lisp Standard. Have you
read it through? It's clear that there is a core set of standards, and
then there are a number of separate sets of capabilities that could
mostly be built on top of that basic standard.
If someone really wanted to implement a non-ANSI, bare-common-lisp that
behaved very much like common lisp, but left out a ton of functions and
macros in the standard which did not require implementation support,
they could certainly use much of the existing standard document as a
specification.
Whether there is a market for such an implementation is another
question, but if there is, no one is stopping anyone from filling it
right now. AFAICT, except for a few young'ns who'd like to deliver
easy-packaged applications without having to hack resources together or
pay a reasonable price for commercial software, there is no such market.
Most people want more and better standard libraries for doing things
which either did not exist, or were not common when the original
standard was made.
Michael
Michael Sullivan <·······@bcect.com> wrote:
+---------------
| But you essentially have that in the Common Lisp Standard. Have you
| read it through? It's clear that there is a core set of standards, and
| then there are a number of separate sets of capabilities that could
| mostly be built on top of that basic standard.
|
| If someone really wanted to implement a non-ANSI, bare-common-lisp that
| behaved very much like common lisp, but left out a ton of functions and
| macros in the standard which did not require implementation support,
| they could certainly use much of the existing standard document as a
| specification.
+---------------
Just as a reminder: One could even legitimately call it "a subset
of Common Lisp" if it met the extremely minimal requirement given
in CLHS "1.7 Language Subsets":
For a language to be considered a subset, it must have the property
that any valid program in that language has equivalent semantics
and will run directly (with no extralingual pre-processing, and
no special compatibility packages) in any conforming implementation
of the full language.
I dare say that one could probably create a legitimate subset of Common
Lisp that was not much (if at all) bigger than an R5RS Scheme. This is
not intended as flame bait, but as a SWAG that one could write the spec
for such a thing in the same ~50 pages as the Scheme spec, even smaller
if one were permitted to refer to the ANSI Standard for things which
were exactly the same (e.g, the C[AD]*R functions come to mind) or the
same with some documented restrictions.
[Hmmm... Sounds like a candidate for a student semester project, eh?]
+---------------
| Whether there is a market for such an implementation is another
| question...
+---------------
Yes, er... well... indeed. That is actually the important question.
+---------------
| ...but if there is, no one is stopping anyone from filling it right now.
+---------------
Right. (See above.)
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> I dare say that one could probably create a legitimate subset of Common
> Lisp that was not much (if at all) bigger than an R5RS Scheme. This is
> not intended as flame bait, but as a SWAG that one could write the spec
> for such a thing in the same ~50 pages as the Scheme spec, even smaller
> if one were permitted to refer to the ANSI Standard for things which
> were exactly the same (e.g, the C[AD]*R functions come to mind) or the
> same with some documented restrictions.
I've actually engaged serious people on a discussion of this and it usually
comes down to that even those who are of a mind to try get saddened and
give up when they find that the number of lines of denotational semantics
will increase. (Sometimes I wonder if that's because a larger denotational
semantics is bad, or if it's just that they're like microcode--something
that's no fun to write and so you'd rather use one that's already there...
I don't speak either myself, and have never felt held back, except in
discussions like these where I have to speculate. I personaly find a
denotational semantics redundant and therefore a risk of error (due to
discrepancy); if I'm going ot have only one version, I want it to be
approachable by people. Others' MMV.
Kent M Pitman <······@world.std.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
| > ...as a SWAG [] one could write the spec for [a workable subset
| > of Common Lisp] in the same ~50 pages as the Scheme spec...
|
| I've actually engaged serious people on a discussion of this and it usually
| comes down to that even those who are of a mind to try get saddened and
| give up when they find that the number of lines of denotational semantics
| will increase. ... I personaly find a denotational semantics redundant...
+---------------
Ditto. In my hypothetical CL subset spec vs. Scheme spec comparison I
was counting only the core "human readable" part of the spec, not the
"Formal syntax and semantics" backend of the Scheme spec -- especially
since the "rules" of CL subsetting say that the semantics of whatever
is included in the subset must be the same as full CL, and therefore
a CL subset spec writer would presumably simply point to the ANSI spec
for that! [How's that for wiggling out of it?] ;-} ;-}
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Peter Seibel
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <m3y8x2djed.fsf@javamonkey.com>
"Paul F. Dietz" <·····@dls.net> writes:
> Rayiner Hashem wrote:
>
> > Eliminating another primitive is a strong case for not having
> > iteration in the language proper.
>
> Why as a user should I care whether a language feature can be
> omitted from some irreduciably minimal core? I *want* the common
> idioms that can be built on top of that core to be standardized, and
> it's just fine with me if that means they're part of the language
> definition.
>
> IMO, one of Common Lisp's problems is that it's *too small*. I want
> more stuff standardized in the language (or, in a single set of
> standardized libraries, which in practice amounts to the same
> thing), not less.
Admit it, Paul, you're just afraid you're going to run out of stuff to
test. ;-)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
On 6 Sep 2003 01:01:06 -0700, ·······@mindspring.com (Rayiner Hashem)
wrote:
>It's not so much because its possible, but because its the blatently
>correct solution. Since recursion can express everything iteration
>can, without requiring additional primitives (function application is
>already needed) iteration is superfuous. Eliminating another primitive
>is a strong case for not having iteration in the language proper.
That's fine as far as it goes, but consider that for the benefit of
not having WHILE as a primitive (a very modest benefit since you still
need IF, and WHILE isn't substantially more complex), the Scheme
committee ended up feeling they had to mandate an optimization in the
standard, which isn't very nice. So on the whole I'd say it's a net
loss in terms of simplicity of the core language.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
> committee ended up feeling they had to mandate an optimization in the
> standard, which isn't very nice. So on the whole I'd say it's a net
> loss in terms of simplicity of the core language.
That is more a fault of the Scheme standardization committe than
anything else. I think the optimization requirement shouldn't be in
the language standard at all. Conformant implementations could be
implemented without tail recursion support, but they'd be slow and
people would not use them for production software. That's fine,
because there are Scheme implementations that are slow that people
don't use for production software.
I think, however, the Scheme committe might be on to something. Modern
high level languages basically require optimizing compilers. For
example, modern C++ techniques would be unusable in real life without
compilers that did aggressve inlining and template folding. Developers
know that, and write their code assuming that the compiler will do
those things. Similarly, Lisp developers write their code assuming
that integers have a "fast-path" that uses tagged types to accelerate
arithmatic. It might be worth it to codify these assumed optimizations
(perhaps, in a document specific to each implementation) instead of
relying on developer experience to build up over time.
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <oexw6x93.fsf@comcast.net>
·······@mindspring.com (Rayiner Hashem) writes:
>> committee ended up feeling they had to mandate an optimization in the
>> standard, which isn't very nice. So on the whole I'd say it's a net
>> loss in terms of simplicity of the core language.
> That is more a fault of the Scheme standardization committe than
> anything else. I think the optimization requirement shouldn't be in
> the language standard at all. Conformant implementations could be
> implemented without tail recursion support, but they'd be slow and
> people would not use them for production software. That's fine,
> because there are Scheme implementations that are slow that people
> don't use for production software.
Tail recursion isn't about speed. The number of programs that run to
completion in a tail-recursive implementation is *larger* than than
the number that will run in a non-tail-recursive implementation.
There are valid Scheme programs that will not run in a
non-tail-recursive implementation.
> There are valid Scheme programs that will not run in a
> non-tail-recursive implementation.
That's true, but there are lots of valid Scheme programs that won't
run even on tail-recursive implementations. The Scheme standard
doesn't specify heap or stack size requirements, so if you cons to
much, even if your program is valid, your program won't run anyway. I
don't see how this is any different in quality, only in degree.
Rayiner Hashem wrote:
> > There are valid Scheme programs that will not run in a
> > non-tail-recursive implementation.
> That's true, but there are lots of valid Scheme programs that
> won't run even on tail-recursive implementations. The Scheme
> standard doesn't specify heap or stack size requirements, so
> if you cons to much, even if your program is valid, your program
> won't run anyway. I don't see how this is any different in quality,
> only in degree.
Without proper tail recursion, you can't reliably use continuation passing
style, for example. In the absence of proper tail recursion, enlarging the
heap or stack merely hides the problem with CPS, it doesn't fix it. That
seems like a difference in quality, to me. And that's just one example of
what proper tail recursion provides.
If there were a way to define a realizable spec such that arbitrary amounts
of consing would never run out of space, no doubt some languages would
specify that as a requirement. However, short of the development of
infinite storage media, that will always be an inherent limitation of
languages. In contrast, proper tail recursion is a case where certain kinds
of potentially infinite recursion *can* be supported, eliminating an entire
class of limitations on programs. Since this is both possible and useful,
it seems perfectly reasonable to specify it as a requirement.
From an earlier message:
> I think the optimization requirement shouldn't be in
> the language standard at all.
...
> I think, however, the Scheme committe might be on to something.
> Modern high level languages basically require optimizing compilers.
As I said in another post, proper tail recursion isn't really an
optimization, any more than automatic garbage collection is. It's a feature
which is required to ensure that a language designed for recursive
programming doesn't require an excessively large amount of space, in
circumstances when it really doesn't need that space - i.e., it provides
better-defined space complexity. Far from being an "optimization", it's a
feature which supports a wider variety of abstractions than would otherwise
be the case.
Anton
From: Duane Rettig
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <4wucjswoi.fsf@beta.franz.com>
"Anton van Straaten" <·····@appsolutions.com> writes:
> Rayiner Hashem wrote:
> > > There are valid Scheme programs that will not run in a
> > > non-tail-recursive implementation.
> > That's true, but there are lots of valid Scheme programs that
> > won't run even on tail-recursive implementations. The Scheme
> > standard doesn't specify heap or stack size requirements, so
> > if you cons to much, even if your program is valid, your program
> > won't run anyway. I don't see how this is any different in quality,
> > only in degree.
>
> Without proper tail recursion, you can't reliably use continuation passing
> style, for example. In the absence of proper tail recursion, enlarging the
> heap or stack merely hides the problem with CPS, it doesn't fix it. That
> seems like a difference in quality, to me. And that's just one example of
> what proper tail recursion provides.
>
> If there were a way to define a realizable spec such that arbitrary amounts
> of consing would never run out of space, no doubt some languages would
> specify that as a requirement. However, short of the development of
> infinite storage media, that will always be an inherent limitation of
> languages. In contrast, proper tail recursion is a case where certain kinds
> of potentially infinite recursion *can* be supported, eliminating an entire
> class of limitations on programs. Since this is both possible and useful,
> it seems perfectly reasonable to specify it as a requirement.
>
> From an earlier message:
> > I think the optimization requirement shouldn't be in
> > the language standard at all.
> ...
> > I think, however, the Scheme committe might be on to something.
> > Modern high level languages basically require optimizing compilers.
>
> As I said in another post, proper tail recursion isn't really an
> optimization, any more than automatic garbage collection is. It's a feature
> which is required to ensure that a language designed for recursive
> programming doesn't require an excessively large amount of space, in
> circumstances when it really doesn't need that space - i.e., it provides
> better-defined space complexity. Far from being an "optimization", it's a
> feature which supports a wider variety of abstractions than would otherwise
> be the case.
In these two articles, you've used the term "proper tail recursion" 4
times after Rayiner Hashem has used it once. It is clear, even though you
are posting on comp.lang.lisp, that you both are talking about Scheme because
of the context, and thus you are both really talking about "Proper Tail
Recursion" _as_ _defined_ by Scheme, rather than tail recursion which is
correct, as opposed to tail recursion which might be improper. Calling
Scheme's definition "Proper ..." has the effect calling any other style
of tail-call optimization/merging/elimination improper.
Having recently had a conversation on this newsgroup about this
same subject and having found out that even some Schemers don't like that
name, because it doesn't really describe the "safe-for-space" property
of what it really means, and due to its moralistic implications, I prefer
that you do not use that term here. Please see the article
http://groups.google.com/groups?q=g:thl2649401452d&dq=&hl=en&lr=&ie=UTF-8&selm=b84e9a9f.0304251247.534b2696%40posting.google.com
and use some other term, such as the "space efficient tail calls" which
William Clinger suggests, rather than "proper tail recursion". You might
also want to review some of the rest of that thread, in order to not have
to revisit already-covered ground.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> In these two articles, you've used the term "proper tail recursion"
> 4 times after Rayiner Hashem has used it once. It is clear, even
> though you are posting on comp.lang.lisp, that you both are talking
> about Scheme because of the context, and thus you are both
> really talking about "Proper Tail Recursion" _as_ _defined_ by
> Scheme, rather than tail recursion which is correct, as opposed
> to tail recursion which might be improper. Calling Scheme's
> definition "Proper ..." has the effect calling any other style of
> tail-call optimization/merging/elimination improper.
Thanks for the tip and the reference. Another thing that belongs in the
c.l.l. faq, perhaps.
Just to put the sub-discussion in context, it started with Russell Wallace
writing:
> the Scheme committee ended up feeling they had to mandate
> an optimization in the standard, which isn't very nice.
I was responding on that issue, first to Russell and later to Rayiner
Hashem. So I didn't think that there was any question about whether or not
Scheme was being discussed, or its definition of "proper tail recursion".
It was that definition which Russell originally referred to.
For the record, I believe the points I made apply to any reasonable
definition of "space efficient tail calls", and are an important
consideration for any language that intends to support a recursive
programming style. Note that I make no judgement about whether such a
requirement belongs in a language standard, only that it is a reasonable
requirement to impose, for certain kinds of languages.
Anton
Anton van Straaten wrote:
>
> If there were a way to define a realizable spec such that arbitrary amounts
> of consing would never run out of space, no doubt some languages would
> specify that as a requirement. However, short of the development of
> infinite storage media, that will always be an inherent limitation of
> languages. In contrast, proper tail recursion is a case where certain kinds
> of potentially infinite recursion *can* be supported, eliminating an entire
> class of limitations on programs.
Show me me a non-trivial example of a recursive algorithm which is infinite.
Wade
Wade Humeniuk wrote:
> Anton van Straaten wrote:
>
>
> >
> > If there were a way to define a realizable spec such that arbitrary
amounts
> > of consing would never run out of space, no doubt some languages would
> > specify that as a requirement. However, short of the development of
> > infinite storage media, that will always be an inherent limitation of
> > languages. In contrast, proper tail recursion is a case where certain
kinds
> > of potentially infinite recursion *can* be supported, eliminating an
entire
> > class of limitations on programs.
>
> Show me me a non-trivial example of a recursive algorithm which is
infinite.
Heh - I thought I might get in trouble for that. I think I hit on it better
in a paragraph further down, where I said "doesn't require an excessively
large amount of space, in circumstances when it really doesn't need that
space". Not exactly an elegant description, though - feel free to improve
on it.
Actually, when I said "potentially infinite", I was thinking in terms of
using recursion to express iteration, in which case you can write some very
trivial examples which are potentially infinite, e.g. the equivalent of an
endless loop - a REPL, a server port listener, etc. (assuming we accept a
notion of infinity bounded by the reliability of the host OS and hardware).
This would also arise when using recursive calls to implement a WHILE
primitive, as Russell Wallace originally mentioned.
I don't think any of this detracts from the point I was making, or if it
does, I'd need a hint as to why.
Anton
Anton van Straaten wrote:
>
> I don't think any of this detracts from the point I was making, or if it
> does, I'd need a hint as to why.
Cause I do not really think there is a non-trivial example of infinite
recursion. Any that come to my mind are just JUMPS in execution. If that
is the case then JUMPS are much more powerful (and dangerous) than both iteration and
recursion, and are obviously the more primitive form.
Wade
Wade Humeniuk wrote:
> Anton van Straaten wrote:
>
> >
> > I don't think any of this detracts from the point I was making, or if it
> > does, I'd need a hint as to why.
>
> Cause I do not really think there is a non-trivial example of infinite
> recursion. Any that come to my mind are just JUMPS in execution. If that
> is the case then JUMPS are much more powerful (and dangerous) than both
iteration and
> recursion, and are obviously the more primitive form.
Like I said, the word "infinite" was probably a bad choice of word, and
avoiding it doesn't affect what I was saying.
Re the triviality of infinite recursion - I originally mentioned that in the
context of space usage. As I mentioned, a simple endless tail-recursive
loop which passes state from one iteration to the next would use "infinite"
space in a language in which tail calls are not safe for space. This is
more than just a "jump" - it's a jump with parameters, i.e. a tail call.
If you dismiss that as an example of iteration, not recursion, remember that
the point was related to a core language which omitted iteration constructs
like WHILE. In a core language with WHILE, you could simply use WHILE for
my example.
Re jumps, while it's true that a pure jump, without parameters or other
context, is both more powerful and more dangerous than iteration or
recursion, it doesn't offer any benefits, in a high-level language, that
would outweigh its costs.
Recursion, otoh, implemented so that tail calls are space-safe, is useful in
its own right in a high-level language, and encompasses iteration, which is
why it makes sense as a primitive feature for a language core. Note that
without the space-safety feature, recursion *cannot* reliably encompass
iteration, which is part of the point here.
To summarize, a language with "hungry"[*] tail calls needs iteration
constructs in its core, since such constructs can't safely be implemented
otherwise; in addition, certain kinds of recursion may run out of space. A
language with space-safe tail calls doesn't need iteration constructs in its
core, since those constructs can be safely implemented on top of the core.
Anton
[*] Suggestions for more P.C. term welcomed.
Wade Humeniuk <········@nospamtelus.net> writes:
> Anton van Straaten wrote:
>
>
> > If there were a way to define a realizable spec such that
> > arbitrary amounts of consing would never run out of space, no
> > doubt some languages would specify that as a requirement.
> > However, short of the development of infinite storage media, that
> > will always be an inherent limitation of languages. In contrast,
> > proper tail recursion is a case where certain kinds of potentially
> > infinite recursion *can* be supported, eliminating an entire class
> > of limitations on programs.
>
> Show me me a non-trivial example of a recursive algorithm which is infinite.
(defun repl ()
(print (eval (read)))
(repl))
or
(defun web-socket-listener (socket)
(serve-one-client (listen-for-connection socket))
(web-socket-listener))
That is, loops are non-trivial.
From: Lars Brinkhoff
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <857k4j9647.fsf@junk.nocrew.org>
"Anton van Straaten" <·····@appsolutions.com> writes:
> As I said in another post, proper tail recursion isn't really an
> optimization, any more than automatic garbage collection is.
Is automatic garbage collection mandated by the Scheme standard?
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Lars Brinkhoff wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
> > As I said in another post, proper tail recursion isn't really an
> > optimization, any more than automatic garbage collection is.
>
> Is automatic garbage collection mandated by the Scheme standard?
No. It is mentioned as follows (1.1, Semantics):
"All objects created in the course of a Scheme computation, including
procedures and continuations, have unlimited extent. No Scheme object is
ever destroyed. The reason that implementations of Scheme do not (usually!)
run out of storage is that they are permitted to reclaim the storage
occupied by an object if they can prove that the object cannot possibly
matter to any future computation."
Note that I haven't been arguing whether or not space-safe tail calls should
or should not be madated by a standard, only that it is reasonable to
include it as a requirement in a standard for certain kinds of languages (in
contrast to the original statement to which I responded). I consider it
equally reasonable to include garbage collection as a requirement in some
languages, for similar reasons. Still, I also respect the notion of leaving
such choices up to an implementor.
Anton
Lars Brinkhoff wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>>As I said in another post, proper tail recursion isn't really an
>>optimization, any more than automatic garbage collection is.
> Is automatic garbage collection mandated by the Scheme standard?
No. It's perfectly ok to use machines with infinite memories.
All I could find in the standard on the subject of memory management
is the following (I guess you already knew):
1.1 Semantics
...
All objects created in the course of a Scheme computation, including
procedures and continuations, have unlimited extent. No Scheme object
is ever destroyed. The reason that implementations of Scheme do not
(usually!) run out of storage is that they are permitted to reclaim
the storage occupied by an object if they can prove that the object
cannot possibly matter to any future computation. Other languages in
which most objects have unlimited extent include APL and other Lisp
dialects.
...
<http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-4.html>
--
Jens Axel S�gaard
From: Joe Marshall
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <he3nnvll.fsf@ccs.neu.edu>
·······@mindspring.com (Rayiner Hashem) writes:
>> There are valid Scheme programs that will not run in a
>> non-tail-recursive implementation.
> That's true, but there are lots of valid Scheme programs that won't
> run even on tail-recursive implementations. The Scheme standard
> doesn't specify heap or stack size requirements, so if you cons to
> much, even if your program is valid, your program won't run anyway. I
> don't see how this is any different in quality, only in degree.
There are valid (and useful) Scheme programs that will run for an
indefinite amount of time on a system with a small heap and stack if
the implementation is tail-recursive, but would require an indefinite
amount of space if the implementation is not tail-recursive.
That is to say, there is an interesting class of Scheme programs that
cannot be run on a non-tail-recursive implementation no matter how
large the heap or stack size is, yet they run fine with a limited heap
and stack size on a tail-recursive implementation.
Or, given two scheme systems that differ only in whether they tail
recurse, and in particular have identical stack and heap sizes, the
one with tail recursion runs every program the other does, and then
some.
On Sun, 07 Sep 2003 22:37:29 GMT, ·············@comcast.net wrote:
>There are valid Scheme programs that will not run in a
>non-tail-recursive implementation.
There are also valid Scheme programs that won't run in an
implementation that doesn't support garbage collection, or numbers of
unbounded precision, or a heap size larger than one megabyte; IIRC the
standard doesn't mandate any of these. It seems to me the standard
committee wouldn't have felt it necessary to mandate tail call
optimization either, if they had included WHILE as a primitive. Since
WHILE is simpler than tail call optimization, this would have been a
better match for their goal of making the language definition simple.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
Russell Wallace wrote:
> On Sun, 07 Sep 2003 22:37:29 GMT, ·············@comcast.net wrote:
>
> >There are valid Scheme programs that will not run in a
> >non-tail-recursive implementation.
>
> There are also valid Scheme programs that won't run in an
> implementation that doesn't support garbage collection, or numbers of
> unbounded precision, or a heap size larger than one megabyte; IIRC the
> standard doesn't mandate any of these. It seems to me the standard
> committee wouldn't have felt it necessary to mandate tail call
> optimization either, if they had included WHILE as a primitive. Since
> WHILE is simpler than tail call optimization, this would have been a
> better match for their goal of making the language definition simple.
I think this would be a perfectly valid choice for a language standard, but
I don't think it's what the RnRS authors were after for Scheme. Including
WHILE as a primitive and omitting the space-efficient tail call requirement
would take care of iteration, more or less, but it would not address other
recursive cases.
Aside from the question of portability, I see the tail call requirement as a
philosophical statement of direction for the language - it's saying
"recursion and tail calls are important for Scheme, and implementations must
support them as fully as possible". This is an important part of Scheme's
support for functional programming. If the tail call requirement had been
omitted, iteration primitives would have had to be included; but iteration
primitives had been included, it doesn't follow that the tail call
requirement should or would have been omitted.
In my other posts, I've tried to give some sense of why that's the case.
Support for CPS is one example I gave of an application that's addressed by
the tail call requirement. In general, the argument that the tail call
requirement provides a better handle on space complexity is a pretty good
one, which I imagine the RnRS authors were well aware of.
Anton
Russell Wallace wrote:
> On Mon, 08 Sep 2003 07:40:59 GMT, "Anton van Straaten"
> <·····@appsolutions.com> wrote:
>
> >Aside from the question of portability, I see the tail call requirement
as a
> >philosophical statement of direction for the language - it's saying
> >"recursion and tail calls are important for Scheme, and implementations
must
> >support them as fully as possible". This is an important part of
Scheme's
> >support for functional programming.
>
> Perhaps you're right. But then if functional programming is that
> important, set-car! and set-cdr! shouldn't be in the language - which
> goes back to my point in a previous subthread :)
I don't recall your other point, but Scheme isn't supposed to be *purely*
functional, either - according to the first paragraph of R5RS, "A wide
variety of programming paradigms, including imperative, functional, and
message passing styles, find convenient expression in Scheme."
There are Scheme subsets that are purely functional, typically for research
purposes. I think some serious but impure[*] functional fans might have
preferred to see Scheme use something like the ref cells in SML, in which
case set!, set-car! and set-cdr! could all be replaced by a cell mutator.
Anton
[*]not a moral judgement
Russell Wallace wrote:
> On Sun, 07 Sep 2003 22:37:29 GMT, ·············@comcast.net wrote:
>>There are valid Scheme programs that will not run in a
>>non-tail-recursive implementation.
> There are also valid Scheme programs that won't run in an
> implementation that doesn't support garbage collection, or numbers of
> unbounded precision, or a heap size larger than one megabyte; IIRC the
> standard doesn't mandate any of these. It seems to me the standard
> committee wouldn't have felt it necessary to mandate tail call
> optimization either, if they had included WHILE as a primitive. Since
> WHILE is simpler than tail call optimization, this would have been a
> better match for their goal of making the language definition simple.
Sure. But I think that's an simplification of their goals.
The first sentence in the standard is:
Programming languages should be designed not by piling feature on top
of feature, but by removing the weaknesses and restrictions that make
additional features appear necessary.
Thus it's not "simplicity at all costs" - but "simplicity through
few powerful constructs".
The standard example of space-efficient tail recursion is indeed loops,
but there are other uses, which is not rewritten as easily.
Here is nice, small concrete example of copying a binary tree:
<http://groups.google.com/groups?selm=b84e9a9f.0304240854.33822415%40posting.google.com&output=gplain>
--
Jens Axel S�gaard
From: Joe Marshall
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <d6ebnvas.fsf@ccs.neu.edu>
················@eircom.net (Russell Wallace) writes:
> On Sun, 07 Sep 2003 22:37:29 GMT, ·············@comcast.net wrote:
>
>>There are valid Scheme programs that will not run in a
>>non-tail-recursive implementation.
>
> There are also valid Scheme programs that won't run in an
> implementation that doesn't support garbage collection, or numbers of
> unbounded precision, or a heap size larger than one megabyte; IIRC the
> standard doesn't mandate any of these.
True. If we avoid using numbers, then numbers of unbounded precision
doesn't matter. If we avoid consing, then gc doesn't matter (nor does
memory limits).
If we avoid function calls, then tail-recursion doesn't matter.
But while it is trivial to avoid using numbers and possible to avoid
consing, it is literally impossible to write non-trivial code in
scheme without function calls. Given two scheme implementations that
are identical except for tail-recursion, the tail recursive one runs
more programs.
> committee ended up feeling they had to mandate an optimization in the
> standard, which isn't very nice. So on the whole I'd say it's a net
> loss in terms of simplicity of the core language.
That is more a fault of the Scheme standardization committe than
anything else. I think the optimization requirement shouldn't be in
the language standard at all. Conformant implementations could be
implemented without tail recursion support, but they'd be slow and
people would not use them for production software. That's fine,
because there are Scheme implementations that are slow that people
don't use for production software.
I think, however, the Scheme committe might be on to something. Modern
high level languages basically require optimizing compilers. For
example, modern C++ techniques would be unusable in real life without
compilers that did aggressve inlining and template folding. Developers
know that, and write their code assuming that the compiler will do
those things. Similarly, Lisp developers write their code assuming
that integers have a "fast-path" that uses tagged types to accelerate
arithmatic. It might be worth it to codify these assumed optimizations
(perhaps, in a document specific to each implementation) instead of
relying on developer experience to build up over time.
Russell Wallace wrote:
> On 6 Sep 2003 01:01:06 -0700, ·······@mindspring.com (Rayiner Hashem)
> wrote:
>
> >It's not so much because its possible, but because its the blatently
> >correct solution. Since recursion can express everything iteration
> >can, without requiring additional primitives (function application is
> >already needed) iteration is superfuous. Eliminating another primitive
> >is a strong case for not having iteration in the language proper.
>
> That's fine as far as it goes, but consider that for the benefit of
> not having WHILE as a primitive (a very modest benefit since you still
> need IF, and WHILE isn't substantially more complex), the Scheme
> committee ended up feeling they had to mandate an optimization in the
> standard, which isn't very nice.
Presumably you're referring to "proper tail recursion". But this has
nothing to do with whether WHILE is a primitive. Even if WHILE is a
primitive, proper tail recursion is still an important requirement for a
language that's designed to support recursive programming.
Thinking of proper tail recursion as an "optimization" is a little backwards
(despite the common term "tail-call optimization"). Without it, a language
cannot perform certain kinds of recursive operations, so a language without
it is broken from a recursive perspective. Proper tail recursion is no more
an optimization than automatic garbage collection is. In both cases,
without the feature in question, otherwise normal programs can run out of
space.
> So on the whole I'd say it's a net
> loss in terms of simplicity of the core language.
Not at all. Given a language with proper tail recursion, any conceivable
iterative construct can be implemented in a library, without imposing any
new limitations. Given WHILE without proper tail recursion, the resulting
language is incapable of reliably performing many kinds of recursive
operations which would otherwise be possible.
Anton
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <8yp4venv.fsf@comcast.net>
······@dtpq.com (Christopher C. Stacy) writes:
>>>>>> On Wed, 03 Sep 2003 23:38:21 +0200, Pascal Costanza ("Pascal") writes:
> Pascal> For example, from an academic perspective, recursion is not only
> Pascal> enough, but furthermore has the nice property that you can prove
> Pascal> properties about algorithms that use recursion that you can't prove
> Pascal> that easily when using iteration.
>
> I thought the one of the points of SICP was that recursion is
> equivalent to iteration. If you can't prove something in the
> other notation, isn't that just a problem with the notation?
No. There are recursive functions that are not `primitive recursive'.
Ackermann's function is one example. So iteration is a formal subset
of recursion.
From: ··········@YahooGroups.Com
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <REM-2003sep17-017@Yahoo.Com>
{{Date: 03 Sep 2003 17:10:01 -0400
From: Kent M Pitman <······@world.std.com>
the CL specification uses objects, not text, as the basis for its
semantics exactly because it is possible to get past the non-1-to-1
nature of text->object->text->object that Scheme confronts.}}
IMO, this is one of the really big good things about LISP, not just in
ease of writing a formal spec, but in a novice programmer understanding
what the manual means when it says such and such function-call or
special-form has such and such semantics. The spec writer doesn't have
to worry about overlooking some issue of operator precedence or
special-character quoting, because all of that mess has already been
wiped under the rug by passing the source-text through READ before
starting to study the semantics. With raw text syntax, it's not clear
how many parts 3*5%8 has much less what exactly the parts are, but with
the pointy structure:
[* |] -> [3 |] -> [ | NIL]
!
[MOD |] -> [5 |] -> [8 | NIL]
it's quite apparent (from probing around with CAR and CDR) that the
toplevel list has three parts, an operator and a number and another
level of list, and that lower-level list has three parts, an operator
and two numbers. So to understand what that would EVAL to we merely
look up * and MOD in the spec, and follow the dataflow implied by the
levels of structure. (Note to beginning C programmers: The C syntax and
the pointy structure above do *not* correspond.) So the spec writer
need be concerned only with what operator is in the CAR position, and
how that affects EVALuation or other treatment of the remaining
elements of the list. The spec writer needn't worry about operator
precedence etc. except in writing the specs for READ and PRINT.
Compare this with the horrible mess of trying to write a spec for a
Unix shell scripting language such as sh or csh, with all the funny
properties of quoting with '' or "" or \ not to mention the mess with
regular expressions or simplified regular expressions such as used by
grep or fgrep or procmail, and the problem of a shell-script novice
such as myself trying to understand some hairy script somebody else
wrote.
Of course if the programmer makes heavy use of the backquote macro and
various # read macros, the syntax can get almost as ugly and hard to
parse as C or sh or regexp, sigh. But still, technically that's all
defined inside the spec for READ, so none of the rest of the language
spec need be concerned with such messiness.
From: ·············@comcast.net
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <ekyyvui5.fsf@comcast.net>
"Anton van Straaten" <·····@appsolutions.com> writes:
> "Pascal Costanza" wrote:
>>
>> The fact that programs in Common Lisp are required to be lists is only a
>> sufficient condition for (EQ (FOO) (FOO)) to always be T.
>
> I'm trying to point out that it's *not* a sufficient condition. The
> appropriate specification for the semantics of QUOTE are also required, and
> this seems to be the primary issue.
>
> More generally, the issue may be the meaning of the statement "programs are
> required to be lists". It seems that a further assumption may be being
> bundled into this statement, which is that "literal data specified in a
> program denotes itself". By this I mean that the actual value which occurs
> in a program's list representation, is the value which is used at runtime -
> i.e. a value with the same identity, if the value is an object with
> identity.
But only up to a point. Common Lisp is allowed to `fold' literal
constants. In effect, *discarding* the actual value in the program's
list representation and using a `similar' value found elsewhere in the
program.
From: Paul Dietz
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <3F55FC3B.3BBD23FC@motorola.com>
·············@comcast.net wrote:
> But only up to a point. Common Lisp is allowed to `fold' literal
> constants. In effect, *discarding* the actual value in the program's
> list representation and using a `similar' value found elsewhere in the
> program.
Only in file compilation. If you call COMPILE (or EVAL) then
a conforming implementation must preserve object identity
(see section 3.2.4 of CLtS).
Paul
From: ··········@YahooGroups.Com
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <REM-2003sep17-016@Yahoo.Com>
{{Date: Wed, 03 Sep 2003 14:04:03 GMT
From: ·············@comcast.net
Common Lisp is allowed to `fold' literal constants. In effect,
*discarding* the actual value in the program's list representation and
using a `similar' value found elsewhere in the program.}}
Oops, I overlooked that technicality in my earlier responses in this
thread, where I claimed there must be shared EQ structure between the
CADR of the (QUOTE ...) code-snippet in the source and somewhere deep
inside the compilation thereof. About all that can really be said,
allowing for constants possibly being folded in CL, is that there must
be in the heap the *entire* CADR of the (QUOTE ...) code-snippet,
either EQ or part/all copied doesn't matter, shared or not shared with
constants from elsewhere in the program again doesn't matter, so that
when the compilation of that code-snippet returns its value will be
exactly the handle on that thing in the heap, the same each time it's
called, EQ from call to call within the same core image without the
containing code being re-defined or re-compiled. (And it's neither a
number nor a character, this EQness will be preserved over all bindings
and returns and assignments and embeddings inside other
pointy-structures, but not necessarily across print-read cycles).
···@jpl.nasa.gov (Erann Gat) wrote:
> People are talking about unifying CL and Scheme.
No, the thing that I have seen proposed is that there be something
resembling "detente," where the choice is made to not flame people
silly for the very mention of the "other language."
The battles that rage back and forth make both sides look like the
religious bigots that bloodied England back during the War of the
Roses.
And seeing as how MOST people aren't part of the "Lisp religion,' it
all looks like a religious war between two obscure sects from the same
neighbourhood.
Only a fool would /want/ to become a part of that? Ergo, what kind of
idiot would _seriously_ consider adopting Common Lisp /or/ Scheme?
That's just leaping into an internecine fight.
Is that a _fair_ characterization? Probably not. The trolls that
periodically wander through are pretty successful at getting people to
lock horns as if it were...
--
output = reverse("moc.enworbbc" ·@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/emacs.html
I have this nagging fear that everyone is out to make me paranoid.
From: Kenny Tilton
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <3F515811.8090209@nyc.rr.com>
Christopher Browne wrote:
> The battles that rage back and forth make both sides look like the
> religious bigots that bloodied England back during the War of the
> Roses.
Damn, that is so literate. All I have to offer is a Star Trek episode
with two guys each half black and half white hating each other because
their sides were reversed.
:(
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
Centuries ago, Nostradamus foresaw when Kenny Tilton <·······@nyc.rr.com> would write:
> Christopher Browne wrote:
>> The battles that rage back and forth make both sides look like the
>> religious bigots that bloodied England back during the War of the
>> Roses.
>
> Damn, that is so literate. All I have to offer is a Star Trek episode
> with two guys each half black and half white hating each other because
> their sides were reversed.
>
> :(
Unlike Star Trek, the War of the Roses actually involved two genuinely
separate sides, and despite the fact that we might not be able to
identify the respective theological positions, they actually killed
one another over religious differences.
The differences between Scheme and Lisp communities haven't cost too
many lives, but are nowhere as artificial as those made up on Star
Trek...
--
"aa454",·@","freenet.carleton.ca"
http://www.ntlug.org/~cbbrowne/unix.html
Rules of the Evil Overlord #71. "If I decide to test a lieutenant's
loyalty and see if he/she should be made a trusted lieutenant, I will
have a crack squad of marksmen standing by in case the answer is no."
<http://www.eviloverlord.com/>
On 31 Aug 2003 02:38:30 GMT, Christopher Browne <········@acm.org>
wrote:
>... the War of the Roses actually involved two genuinely
>separate sides, and despite the fact that we might not be able to
>identify the respective theological positions, they actually killed
>one another over religious differences.
I thought the it was over who got the house 8-)
George
George Neuner <········@comcast.net> writes:
> On 31 Aug 2003 02:38:30 GMT, Christopher Browne <········@acm.org>
> wrote:
>
> >... the War of the Roses actually involved two genuinely
> >separate sides, and despite the fact that we might not be able to
> >identify the respective theological positions, they actually killed
> >one another over religious differences.
>
> I thought the it was over who got the house 8-)
Just in case anyone is still confused about this reference, there are at
least twoimportant referents to the reference "The War of The Roses":
http://www.warsoftheroses.com/ (RL)
http://www.imdb.com/title/tt0098621/ (movie)
Christopher Browne wrote:
>>> The battles that rage back and forth make both sides look like the
>>> religious bigots that bloodied England back during the War of the
>>> Roses.
...
> Unlike Star Trek, the War of the Roses actually involved two genuinely
> separate sides, and despite the fact that we might not be able to
> identify the respective theological positions, they actually killed
> one another over religious differences.
I'm no expert on this stuff, but did the Wars of the Roses
actually have anything to do with theology? I've never before
heard that they did.
--
Gareth McCaughan
.sig under construc
Kenny Tilton wrote:
> Christopher Browne wrote:
> > The battles that rage back and forth make both sides look like the
> > religious bigots that bloodied England back during the War of the
> > Roses.
>
> Damn, that is so literate. All I have to offer is a Star Trek episode
> with two guys each half black and half white hating each other because
> their sides were reversed.
>
> :(
You know, I thought of that one a while ago. I didn't mention it because it
seemed too geeky... ;)
It began upon the following occasion. It is allowed on all hands,
that the primitive way of breaking eggs, before we eat them, was
upon the larger end; but his present majesty's grandfather, while
he was a boy, going to eat an egg, and breaking it according to the
ancient practice, happened to cut one of his fingers. Whereupon the
emperor his father published an edict, commanding all his subjects,
upon great penalties, to break the smaller end of their eggs. The
people so highly resented this law, that our histories tell us, there
have been six rebellions raised on that account; wherein one emperor
lost his life, and another his crown. These civil commotions were
constantly fomented by the monarchs of Blefuscu; and when they were
quelled, the exiles always fled for refuge to that empire. It is
computed that eleven thousand persons have at several times suffered
death, rather than submit to break their eggs at the smaller end.
Many hundred large volumes have been published upon this controversy:
but the books of the Big-endians have been long forbidden, and the
whole party rendered incapable by law of holding employments. During
the course of these troubles, the emperors of Blefusca did frequently
expostulate by their ambassadors, accusing us of making a schism in
religion, by offending against a fundamental doctrine of our great
prophet Lustrog, in the fifty-fourth chapter of the Blundecral (which
is their Alcoran). This, however, is thought to be a mere strain
upon the text; for the words are these: 'that all true believers
break their eggs at the convenient end.'
And which is the convenient end, seems, in my humble opinion to be
left to every man's conscience, or at least in the power of the chief
magistrate to determine....
Jonathan Swift, "Gulliver's Travels", chapter 4
In article <···························@posting.google.com>,
··········@verizon.net (William D Clinger) wrote:
> It began upon the following occasion...
>
> Jonathan Swift, "Gulliver's Travels", chapter 4
Is this is meant to be an oblique way of saying that the differences
between Scheme and Common Lisp are as trivial as the difference between
breaking an egg on the large end or the small end?
If so, then surely you will have no objection to abandoning Scheme and
using Common Lisp from now on. I challenge you to put your money where
your metaphors are and do so.
E.
Erann Gat asked:
> Is this is meant to be an oblique way of saying that the differences
> between Scheme and Common Lisp are as trivial as the difference between
> breaking an egg on the large end or the small end?
I am quite sure this is not what Swift was saying.
> If so, then surely you will have no objection to abandoning Scheme and
> using Common Lisp from now on. I challenge you to put your money where
> your metaphors are and do so.
Did you cut your finger or something?
Will
In article <····························@posting.google.com>,
··········@verizon.net (William D Clinger) wrote:
> Erann Gat asked:
> > Is this is meant to be an oblique way of saying that the differences
> > between Scheme and Common Lisp are as trivial as the difference between
> > breaking an egg on the large end or the small end?
>
> I am quite sure this is not what Swift was saying.
OK, I'm afraid you'll have to enlighten this poor unread techno-geek.
What was the point that Swift (and you) were trying to make?
E.
In article <····················@192.168.1.52>, ···@jpl.nasa.gov (Erann
Gat) wrote:
> In article <····························@posting.google.com>,
> ··········@verizon.net (William D Clinger) wrote:
>
> > Erann Gat asked:
> > > Is this is meant to be an oblique way of saying that the differences
> > > between Scheme and Common Lisp are as trivial as the difference between
> > > breaking an egg on the large end or the small end?
> >
> > I am quite sure this is not what Swift was saying.
>
> OK, I'm afraid you'll have to enlighten this poor unread techno-geek.
> What was the point that Swift (and you) were trying to make?
>
Never mind, I think I figured it out:
http://216.239.41.104/search?q=cache:c1QrfP0nkPwJ:mural.uv.es/mafranch/eggs.htm+jonathan+swift+eggs&hl=en&ie=UTF-8
Sorry for the misunderstanding.
E.
William D Clinger wrote:
> Erann Gat asked:
> > Is this is meant to be an oblique way of saying that the differences
> > between Scheme and Common Lisp are as trivial as the difference between
> > breaking an egg on the large end or the small end?
>
> I am quite sure this is not what Swift was saying.
>
> > If so, then surely you will have no objection to abandoning Scheme and
> > using Common Lisp from now on. I challenge you to put your money where
> > your metaphors are and do so.
>
> Did you cut your finger or something?
Perhaps it's a thorn in the paw...?
Anton
William D Clinger <··········@verizon.net> wrote:
> Many hundred large volumes have been published upon this controversy:
> but the books of the Big-endians have been long forbidden,
^^^^^^^^^^^
<snip>
I did read Swift somewhere in the long past of skool-daze, but I never
remembered this neologism. Those old hackers were such cards.
Michael
William D Clinger <··········@verizon.net> wrote:
+---------------
| Many hundred large volumes have been published upon this controversy:
| but the books of the Big-endians have been long forbidden, and the
| whole party rendered incapable by law of holding employments.
+---------------
Except as network protocol architects. And indeed, almost all
of the world's extant network protocol standards are BigEndian,
even unto this present day...
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Christopher Browne <········@acm.org> wrote in message news:<··············@ID-125932.news.uni-berlin.de>...
> The battles that rage back and forth make both sides look like the
> religious bigots that bloodied England back during the War of the
> Roses.
The Wars of the Roses were *not* religious wars. They were a series of
secular conflicts over royal succession between two branches of the
Platagenet family, The House of Lancaster, and the House of York. The
conflicts ended when Lancastrian forces defeated the Yorkist king
Richard III at the battle of Bosworth Field, and the Yorkist leader,
Edward Tudor became King Henry VII. Henry VII instituted a Tudor
policy, continued by his son Henry VIII, and his granddaughter
Elizabeth I, of executing any potential rival claimant to the throne.
From: ··········@YahooGroups.Com
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <REM-2003sep17-011@Yahoo.Com>
{{Date: Sat, 30 Aug 2003 09:50:50 -0700
From: ···@jpl.nasa.gov (Erann Gat)
(defun foo () '(1 2 3))
(eq (foo) (foo))
Common Lisp requires this to return T, but the Scheme equivalent is
not required to return #T (and indeed there are Scheme implementations
that do not return #T).}}
Because of the possible problem of somebody assuming that was a
constant expression, and somebody else getting that value and trying to
modify it via RPLACA etc., I'd probably rewrite it as:
(defvar *fooval* nil)
(defun foo () (or *fooval* (setq *fooval* (list 1 2 3))))
(eq (foo) (foo))
which would return T in CL, would it return T in Scheme?
(I'd still have to be sure I knew whether I was going to be modifying
that in-place or treating it as a once-set-up constant, but at least
the compiler wouldn't be stepping on my toes either way.)
Alternately, if I was sure I wasn't going to modify it, I might do:
(defconstant *fooval* '(1 2 3))
(defun foo () *fooval*)
(eq (foo) (foo))
But would the compiler be smart enough to protect all usages of that
structure? I guess writing into read-only memory would suffice.
(You know what I mean: Protected page that can be appended at load time
but write-disallowed by normal code.) Anyway, would that return T in
Scheme?
(If the above isn't valid Scheme source, please DWIM to the correct
Scheme source.)
Hmm, or I might write the first example as a closure, so the value is
directly accessible *only* via the function call.
If you want to be really picky about what a Lisp is, because in CL
(let ((x z) (y z)) (eq x y))
doesn't necessarily return T, CL might not be considered a true Lisp in
the original sense.
In article <············@comcast.net>, ·············@comcast.net wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > I've decided to go ahead and reply to this at length and start a new
> > thread because there seems to be a great deal of confusion on these
> > points.
>
> I agree. The Scheme standard goes to great lengths to discriminate
> between objects and their printed representation. For some reason,
> people seem to think that this means Scheme is defined only for the
> printed representation.
>
> > The semantics of Common Lisp, unlike every other programming
> > langauge, are defined on Lisp objects. The semantcs of Scheme, like
> > every other programming language except Common Lisp, are defined on
> > strings.
>
> To be pedantic, the semantics of Scheme are defined (in Section 7.2)
> as set of domain equations. It is the formal syntax I want to focus
> on.
>
> >> 3. The Scheme function EVAL takes a piece of list structure as
> >> an argument
>
> > That is not necessarily true. Scheme's EVAL is defined to take "a Scheme
> > program represented as data." The standard does not require that those
> > data be lists, and furthermore it does not require that even if they are
> > lists that they be the particular lists you would get by using the READ
> > function to parse a Scheme program. Granted, the examples shown in the
> > standard do it this way, but those are just that: examples. The standard
> > does not require this behavior. A Scheme EVAL that took Scheme programs
> > represented as strings would be compliant with the standard, and arguably
> > more in keeping with the evolving spirit of Scheme.
>
> The `Scheme program represented as data' is clearly meant to be list
> structure. This is stated repeatedly in other parts of the standard.
> The examples show list structure, the examples do not show strings.
> That definition of EVAL does not explicitly *rule out* strings, that
> hardly means that it is *intended* to mean them!
>
> > The syntax of those strings happens to be the same as the syntax for
> > lists, but this in and of itself does not require there to be any
> > particular relationship between the two.
>
> This is incorrect, and the Scheme standard *emphasizes* that there is
> a deep relationship between lists and programs.
>
> Section 1.2:
> `The grammar of Scheme generates a sublanguage of the language used
> for data. An important consequence of this simple, uniform
> representation is the susceptibility of Scheme programs and data to
> uniform treatment by other Scheme programs.'
>
> Section 3.3:
> `Scheme's syntax has the property that any sequence of characters
> that is an expression is also the external representation of some
> object. This can lead to confusion, since it may not be obvious out
> of context whether a given sequence of characters is intended to
> denote data or program, but it is also a source of power, since it
> facilitates writing programs such as interpreters and compilers that
> treat programs as data (or vice versa).'
>
> Section 6.3.2:
> `Within literal expressions and representations of objects read by
> the read procedure, the forms '<datum>, `<datum>, ,<datum>, and
> ,@<datum> denote two-element lists whose first elements are the
> symbols quote, quasiquote, unquote, and unquote-splicing,
> respectively. The second element in each case is <datum>. This
> convention is supported so that arbitrary Scheme programs may be
> represented as lists. That is, according to Scheme's grammar, every
> <expression> is also a <datum> (see section 7.1.2). Among other
> things, this permits the use of the read procedure to parse Scheme
> programs. See section 3.3.'
>
> Section 7.1.2:
> `Any string that parses as an <expression> will also parse as a
> <datum>.'
>
> > (NOTE: You may find yourself tempted to cite section 1.2 of R5RS in
> > rebuttal to my position. My claim is that section 1.2 is an
> > artifact of Scheme's history, not an accurate reflection of the
> > current Scheme mindset. I predict that if there is ever an R6RS
> > that this passage will disappear.)
>
> I don't claim to know the `Scheme mindset', or to be able predict the
> contents of a future report. I will note, however, that simple
> excision of section 1.2 will not suffice.
>
> > Of course, one obvious way to implement Scheme is to use the same parser
> > for both programs and lists (since they have the same syntax), and at a
> > casual glance it would seem to be crazy to do anything else. And yet
> > there are Scheme implementations that really do have two separate parsers,
> > one for programs, and a different one for lists.
>
> This is true, but since the grammar that generates programs is a
> subset of that which generates data, the two parsers must act the same
> on lists that could be programs. You could have as many parsers as
> you like, but they have to act the same vis-a-vis programs and lists.
>
> > Schemers have what they consider to be perfectly sound reasons for
> > doing it this way.
>
> PLT Scheme keeps track of the line and character offset when lists
> from a file. It uses these to help find missing open or close
> parens. It's quite handy in this regard. This has little to do with
> whether Scheme programs are `strings'.
>
> > This is one indication of the truly deep gulf that separates the two
> > languages. The Lisp-1 vs Lisp-2 issue is a red herring; Scheme and Lisp
> > really represent two completely different mindsets about how programming
> > languages ought to work, indeed about what programs *are*. That CL uses
> > list syntax for programs is a reflection of its actual semantics. That
> > Scheme uses list syntax for programs is mostly a historical accident. In
> > fact, there are people in the Scheme community who think that using list
> > syntax for programs is unnecessarily confusing and ought to be changed.
>
> I cannot claim to know the mindset of either the Common Lisp or Scheme
> communities. Each community attracts its share of crackpots, so I can
> certainly believe that there are those that think that character
> strings are superior to list syntax. There are those that believe
> that a *richer* structure than lists ought to be used, but you can
> find them in the Common Lisp community as well.
>
> >> So a Scheme program may have several different representations over
> >> its lifetime. At certain points in its lifetime (macroexpansion time)
> >> it is required to have a list representation. (And by this I mean
> >> that the representation is indistinguishable from a list using the
> >> standard Scheme predicates.)
> >
> > No, this is not true. (Well, the first sentence is true, but the rest
> > isn't.) It may be that Scheme programs are required at some point in
> > their lives to have a representation that is isomorphic to lists (and even
> > that is questionable) but it is not required to be represented as a list.
> > And, more to the point, it is not required to be represented as any
> > particular kind of list, and (most important) that representation is not
> > required to be accessible to the user in any way.
>
> It is accessible to the user via macros and macros are defined on lists.
>
> > In Common Lisp the program represented by the string "(defun foo () t)" is
> > required to be represented by a list with four elements. In Scheme, the
> > program represented by the string "(define foo (lambda () #T))" could be
> > represented as a list of three elements, or it could be represented as a
> > structure, or a vector, or even a list that looks like: (program :type
> > :definition :name "foo" :value (lambda-expression :arglist () :body #T)))
>
> Again, programs have several different representations. In common
> lisp, a string "(defun foo () t)" may be read yielding the 4 element
> list you describe. That 4 element list is processed by the compiler
> into some intermediate form, and that intermediate form is processed
> into machine code. The intermediate forms may be CLOS structures
> created with (make-instance 'program :type :definition :name "foo"
> :value (lambda-expression :arglist () :body #t)). The system is
> *allowed* to do whatever it likes so long as it *observably* follows
> the definition.
>
> >> The *only* difference between the two is this:
> >>
> >> 1. Common Lisp programs are read by the Common Lisp READ function.
> >>
> >> 2. Scheme programs need not be read by the Scheme READ function.
> >>
> >> This is `a difference that makes no difference' because the macro
> >> system in Scheme requires exactly the same sort of lists that the READ
> >> function would have produced.
> >
> > I disagree. This is a difference that makes an enormous difference. It
> > can actually change the semantics of programs. In particular, it changes
> > the semantics of QUOTE.
>
> Could you give an example that either clearly demonstrates that
> different semantics follow from using a function similar to READ (but
> not actually named READ)? Can you give an example where QUOTE can
> tell?
>
> >> The macro system of Scheme is a mapping from lists->lists, so the
> >> macro system simply would not work if programs behaved differently
> >> from lists.
>
> > No, that is not true. Scheme's macro system is more or less the same as
> > Dylan's. Dylan programs may be represented as lists under the hood, but
> > that representation is not available to the user. The situation is the
> > same in both langauges. Dylan's syntax makes this clear; Scheme's syntax
> > makes it confusing (which is one of the arguments for abandoning the
> > syntax).
>
> I'm not an expert in Dylan, but it is easy to see that Scheme macros
> are defined as list->list to transformations:
>
> Section 7.1.3 of the standard enumerates the various forms that Scheme
> expression may take. One of these forms is as follows:
>
> <macro use> -> (<keyword> <datum>*)
> <keyword> -> <identifier>
>
> That is to say, a form that starts with a identifier and is followed
> by any number of *data* (i.e., arbitrary list structure) may be a
> macro use. Note that in Scheme, there are no reserved words, so an
> expression such as (define (22 "foo") #(3 '8)) may in fact be
> a legitimate program fragment if the user has replaced DEFINE with a
> macro of his own choosing. So the Scheme reader *must* be
> conservative and read the program as <data> because to do otherwise
> may reject a legitimate program. Parenthesised forms read as data
> create lists.
>
> We can go further. Section 4.3.2 describes the macro transformation
> language. It states ``The <pattern> in a <syntax rule> is a *list*
> <pattern> that begins with the keyword for the macro.'' (emphasis
> mine) Further down, the formal rules for matching a pattern state:
>
> ``An input form F matches a pattern P if and only if:
> <clause 1 & 2 omitted here>
>
> - P is a *list* (P1 ... Pn) and F is a *list* of n forms that match
> P1 through Pn, respectively; or
>
> - P is an improper *list* (P1 P2 ... Pn . Pn+1) and F is a *list* or
> improper *list* of n or more forms that match P1 through Pn
> respectively and whose nth `cdr' matches Pn+1; or
>
> - P is of the form (P1 ... Pn Pn+1 <ellipsis>) where <ellipsis>
> is the identifier ... and F is a proper *list* of at least n
> forms, the first n of which match P1 through Pn, respectively,
> and each remaining element of F matches Pn+1; or
>
> <vector forms omitted>
>
> - P is a datum and F is equal to P in the sense of the EQUAL?
> procedure. '' (emphasis mine)
>
>
> This is clearly described as operations on lists. And the final
> clause covers the list case as well.
>
> Because macros are defined as transformations on lists, Scheme *must*
> represent programs internally as something isomorphic to lists.
> There's no way to avoid that. This can be exposed through the
> high-level macro system Scheme provides (although it is an
> extraordinary pain in the ass to do so). Oleg Kiselyov and Al
> Petrovsky have developed macros versions of CAR, CDR, CONS and NULL
> that reflect the implicit list operations that high-level macros
> provide. List structure is defined by induction over those
> primitives.
>
Thanks! Great post.
···@jpl.nasa.gov (Erann Gat) writes:
> I've decided to go ahead and reply to this at length and start a new
> thread because there seems to be a great deal of confusion on these
> points.
>
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > How many times are you going to make me repeat myself? All these
> > > questions are asked and answered in the thread that begins with message id
> > > ··············@ID-60390.news.dfncis.de. Go ye forth and read it.
> > >
> > > (I note in passing that you participated in that thread.)
> >
> > Yes. I understand the issues. I am simply responding to your
> > original assertion that `Scheme programs, like every other programming
> > language and unlike Common Lisp, are strings, not lists'. This is a
> > somewhat vague statement, and what it implies is not true.
>
> That depends on what you think it implies.
>
> The semantics of Common Lisp, unlike every other programming langauge, are
> defined on Lisp objects. The semantcs of Scheme, like every other
> programming language except Common Lisp, are defined on strings. The
> syntax of those strings happens to be the same as the syntax for lists,
> but this in and of itself does not require there to be any particular
> relationship between the two.
[...]
> One last thing: please note the title of this post. I do not have a
> position about whether Scheme is or is not a Lisp. I think it's a waste
> of time to split those kinds of semantic hairs. The purpose of this post
> was not to take a position, but merely to explain why some people think
> that Scheme is not a Lisp despite the fact that it looks like a Lisp and
> even calls itself a Lisp.
In keeping with Erann's setup here, I should identify that I think Scheme
is not a CL, but not (just) for the reasons he cites (which I consider to
be secondary in the sense that they seem to me to be results of, rather than
definitional aspects of, the real split).
I believe what makes languages different is that they are the result of
political parties satisfying (or attempting to satisfy) a constituency.
As in politics, there is the notion of "close, but no cigar" (idiomatic
English meaning "even though there may be objective similarity, the ultimate
result does not pass a subjective 'win/lose' test as a 'win'".)
In a sense, I think the higher order difference that makes Scheme different
than CL is that people who identify themselves as Scheme people often turn
up their noses at CL, and people who identify themselves as CL people turn
up their noses at Scheme, and there is no obvious "small" change that would
fix this (where "small" is something agreed upon by both communities to be
small; indeed, since it's very common in such splits that one community
trivializes what is important to another, it often seems to Scheme people
that the set of changes needed to "fix" CL is small, but CL people regard
those same changes as major, and vice versa).
If I were to characterize my reason for thinking Scheme is unacceptable, I'd
say a lot of it comes down to "lack of respect for object identity". I regard
object identity as core, and functionality to follow from identity. Much of
Scheme definitionalism seems to me to regard functionality as core and identity
as a constructed notion.
The issue isn't just "is it defined textually or as objects", but more
fundamentally, does a definition (like other things) have object identity?
There are a great number of things whose identities in Scheme are regarded
as unimportant. For example, I recall design discussions among the Scheme
authors where it was seriously proposed that EQ? should signal an error
if given two procedures to compare because some of the committee wanted
the identity nature of procedures to be slippery and didn't want to say
whether (lambda () ...) returned the same procedure every time, or whether
the compiler was allowed to 'split' a function or to 'coalesce' functionally
equivalent functions. I think ultimately EQ? was defined as total, but in
CL I don't think the core designers could ever have had such a discussion.
EQ is so fundamental, in fact, that even in the presence of EQL (which
glosses the slippery identity of fixnums and chars), there was an insistence
by the community that EQ should be available even though one might lightly
sum up its only difference from EQL as "adding the ability to confound
newbies or to 'enable' implementation bigots". Nevertheless, the core issue
here is not EQ(?) but whether identity leads functionality or functionality
leads identity. In CL, the designers and the core community knows that objects
_do_ have identity and want an EQ that reveals this. In Scheme, the designers
want to abstract away from identity (which thwarts their functional goals)
and to offer back identity only where it doesn't stand in the way of their
other goals.
Program hygiene (at least as described by Kohlbecker's painting algorithm)
likewise slices and dices a program, EVEN TO invading quoted structures,
reconstructing them later in a way that pretends no violation has occurred.
I find this as personally distasteful as being told that the police will
search my house when I leave it but "don't worry--as long as you've broken
no law, they'll have it back in order as if no one had been there before i
return". That isn't the same as "not searching" no matter how much they
claim it to be "functionally equivalent".
I have often said that if I could ask only one question about a
language to determine whether it's usable, it would be "does it have
unwind-protect?". This is not because I use unwind-protect more than
anything else. Often I don't use it at all. It's because it reveals
a mindset that might render itself in other contexts in other ways,
but is visible. It's like saying that if I wanted to pick a friend
out of a group of strangers, I'd maybe look at their shoes--not
because I care what someone's shoes look like, or even very often LOOK
at anyone's shoes, but because I think people care a lot (probably
unreasonably much) about their shoe choice and so the choice of shoes
(to me) reveals more about their personality in a compact number of
bits than do other tests I could perform. So, likewise, I think looking to
the question of how a programming language treats certain issues of
identity is instructive as to what its decisions will be in other areas
that I care about.
The fact that CL defines its programs in terms of objects doesn't just
lead to a set of different conclusions than a text-defined language, but
it speaks to how the language treats "programs" overall. It's not a
coincidence that the operator COMPILE is in CL and not in Scheme. It
follows from the idea that programs can be reliably computed using the
operators that CL provides, and then there's a need to compile them.
Scheme (a) doesn't want you to construct programs on the fly this way--it
wants you to compose closures of already-compiled functions and (b) doesn't
offer operators to reliably compose programs as text, maintaining boundaries.
So it doesn't offer compile either. Those are all inter-related aspects of
its ecology. It says that programs and text have a natural relation, but
this doesn't really explain gensyms. It doesn't go to enough trouble to
explain how gensyms are translated to text and back. Gensyms "look like"
other objects (i.e., have the same text rep) and so lose information when
made into text. Not treating gensym as important is again a disregard for
identity--it says identity will be kludged in later rather than that identity
is the core thing. By defining the language as objects, we dno't just say
"it's preparsed". Rather, we say, "there are some things that are captured
in structure that are not captured as easily in text".
The identity issue reflects itself yet again in the package/module debate.
Packages are not modules, but packages do create some degree of module-like
division that Scheme is without. In return for this, we in CL have a way of
directly naming data in another's package without going through some kind of
module system to get it. Symbols belonging to one system often can be named
directly by another, without going through any module system. CL people use
this to great effect in order to name classes and methods in various packages
directly from any package. Schemers prefer different mechanisms for naming
that are more "relative" than "absolute". This again follows from differences
in the use of identity.
These are all just my personal characterizations of how a single
"political priority" manifests itself in a variety of disparate ways
throughout the language. People might legitimately disagree about the
priorities they see, or about the causes of the issues I've cited.
But as with all issues of sociology, and that's what I claim is in
play, it's always going to require some amount of subjective
assessement if you don't want to be playing with billions (or more) of
microvariables in the individual brains of each person involved.
Subjectivity is not just handwaving -- it is an attempt to give
aggregate form (gestalt) to something that is otherwise too complex to
speak of. And, like the weather, the fact that it is too complex to
predict exactly does not mean it has no effect.
The bottom line observed truth of why they are different languages,
however you articulate the details, is that if you put all of us in
one room, we'll only bicker and will not move forward. And if you
separate us along these lines, we'll each get useful work done, even
though in an incompatible way.
Like political parties, there are sometimes different divisions that will
create even better power. The lines are often drawn arbitrarily. But
just because the line is drawn arbitrarily does not mean people's choice
of which side of that arbitrary line to be is also arbitrary. For any
given arbitrarily drawn line, people may and often do have a very strong
sense of which side of the line they want/need to be on.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> In keeping with Erann's setup here...
> If I were to characterize my reason for thinking Scheme is unacceptable...
Just to avoid any possibility of confusion, I do not believe that Scheme
is unacceptable. I happen to prefer CL for purely utilitarian reasons,
but when I write code I tend to write in a style that CLers consider
Schemely. So on Kent's political-party model I am an independent (or
perhaps a Libertarian).
Also, while I do not disagree with Kent's view that the two langauge's
position on object identity is one of their core differences, I am not
sure that this is the core difference that makes some people consider
Scheme to not be a Lisp. It is not clear to me that object identity is an
essential element of Lispness (it may well be, but it's just not obvious
to me that it is). Of course, there is no consensus on what the essential
elements of Lispness are, but representation of programs as lists is one
feature that seems to be relatively non-controversial, and so the fact
that Scheme gives the appearance of doing so without actually doing so is
IMO the most defensible reason for someone to consider Scheme to not be a
Lisp (and the reason that Schemers get so defensive about it). But as I
said at the outset, I think that arguing about such things is ultimately a
waste of time.
The reason that I'm spending so much time on this is not because I want to
resolve the issue of whether Scheme is or isn't a Lisp, but simply that I
think it's important for this difference between the two to be better
understood.
I have characterised this difference as "semantics defined on lists vs.
semantics defied on text" to highlight how this difference leads some to
the conclusion that Scheme is not a Lisp. But I could just as well have
characterized it as, "Semantics defined the way they are for all other
programming languages" vs "Semantics as defined for Common Lisp". The
fact that CL semantics are defined on forms (and that CL is the *only*
standardized programming language for which this is true) leads to many
salient consequences, not just (eq (foo) (foo)) being T. I've pointed
some of these out earlier, but to reiterate: there are CL programs that
have no readable representation. There are perfectly well defined CL
programs that have no printable representation. There are CL programs
which are both readable and printable, but which cannot be rendered into
Scheme, e.g.:
(dolist (x '#1=(1 2 3 . #1#)) (print x))
or
(progn . #1=((print "This is an infinite loop") . #1#))
because they cannot be textually represented in Scheme's grammar.
or
(let ( (x #.(compute-hairy-non-printable-thingy)) ) ...)
Reasonable people can differ as to whether one would actually want to ever
do such things. But reasonable people cannot differ over the fact that
this difference exists.
E.
Erann Gat wrote:
> There are CL programs which are both readable and printable,
> but which cannot be rendered into Scheme, e.g.:
>
> (dolist (x '#1=(1 2 3 . #1#)) (print x))
Except that some Schemes support the circular list syntax. The above can be
translated into MzScheme, for example. I might have used for-each instead
of dolist, but for-each seems to require a proper terminating list, at least
in MzScheme, so here's a raw version:
(let loop ((x '#1=(1 2 3 . #1#))) (print (car x)) (loop (cdr x)))
> or
>
> (progn . #1=((print "This is an infinite loop") . #1#))
Changing 'progn' to 'begin' "works" in MzScheme - it hangs and eats CPU
without printing anything. A CL I tried behaved similarly, I don't know if
anything else is expected.
> because they cannot be textually represented in Scheme's grammar.
>
> or
>
> (let ( (x #.(compute-hairy-non-printable-thingy)) ) ...)
>
> Reasonable people can differ as to whether one would actually want
> to ever do such things. But reasonable people cannot differ over the
> fact that this difference exists.
I suspect that the fiction of "reasonable people" soon breaks down. IMO,
reasonable people could agree that the fact that the Scheme grammar can be
and has been consistently extended to support these features is further
evidence that Scheme is a Lisp.
Anton
In article <····················@newsread2.news.atl.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
> Erann Gat wrote:
> > There are CL programs which are both readable and printable,
> > but which cannot be rendered into Scheme, e.g.:
> >
> > (dolist (x '#1=(1 2 3 . #1#)) (print x))
>
> Except that some Schemes support the circular list syntax.
But the Scheme standard doesn't, and you'd be very hard-pressed to extend
it so that it did.
> > (progn . #1=((print "This is an infinite loop") . #1#))
>
> Changing 'progn' to 'begin' "works" in MzScheme - it hangs and eats CPU
> without printing anything. A CL I tried behaved similarly, I don't know if
> anything else is expected.
Of course something else is expected:
? (progn . #1=((print "This is an infinite loop") . #1#))
"This is an infinite loop"
"This is an infinite loop"
"This is an infinite loop"
etc...
> I suspect that the fiction of "reasonable people" soon breaks down.
You seem to be doing your best to demonstrate this.
E.
Erann Gat wrote:
> > Except that some Schemes support the circular list syntax.
>
> But the Scheme standard doesn't, and you'd be very hard-pressed to extend
> it so that it did.
Unless I'm missing something, it should be straightforward to extend the
Scheme standard to support circular list syntax for literal data. What
would be more difficult, would be to extend it to support circular lists
embedded as code, as in your example (progn . #1=((print "This is an
infinite loop") . #1#)).
> Of course something else is expected:
>
> ? (progn . #1=((print "This is an infinite loop") . #1#))
>
> "This is an infinite loop"
> "This is an infinite loop"
> "This is an infinite loop"
>
> etc...
Corman Lisp doesn't do this. Is there a free implementation for Linux or
Windows which does?
> > I suspect that the fiction of "reasonable people" soon breaks down.
>
> You seem to be doing your best to demonstrate this.
I'm sorry you feel that way. I'm trying to understand and perhaps clarify
your point. To that end, I'd appreciate a response to my recent point
elsewhere in this thread about distinguishing the issue of self-denoting
data, from the question of whether programs are represented as lists.
I accept your point that (progn . #1=((print "This is an infinite loop") .
#1#)) may be a program that would require unnatural extensions to the Scheme
standard. However, I see this as a distinct issue from the question of the
meaning of (quote (1 2 3)) and (eq (foo) (foo)). It's true that the
assumption that programs are lists, combined with the assumption that
literal data is self-denoting, is one way to explain both of these examples.
If you modify your original point to address the bit about self-denoting
data in some way, then I would understand and accept it. If I have missed
that you have been trying to do that, then I apologize.
Anton
In article <····················@newsread2.news.atl.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
> > Of course something else is expected:
> >
> > ? (progn . #1=((print "This is an infinite loop") . #1#))
> >
> > "This is an infinite loop"
> > "This is an infinite loop"
> > "This is an infinite loop"
> >
> > etc...
>
> Corman Lisp doesn't do this.
That was cut-and-pasted from MCL.
But it is true that Common Lisp is not required to do this. It turns out
that the results of running ciruclar code are undefined in CL. (I didn't
know that when I came up with the example.)
> I'd appreciate a response to my recent point
> elsewhere in this thread about distinguishing the issue of self-denoting
> data, from the question of whether programs are represented as lists.
Arrgghhh!!!! I'm not talking about whether programs are represented as
lists! I'm talking about whether the semantics are defined on lists!
Those are not the same thing! How hard can that be to understand?
E.
···@jpl.nasa.gov (Erann Gat) writes:
> Arrgghhh!!!! I'm not talking about whether programs are represented
> as lists! I'm talking about whether the semantics are defined on
> lists! Those are not the same thing! How hard can that be to
> understand?
The semantics are defined on some syntax representation, even when the
representation is only on paper -- an implementation *is* just a
fully-specified form of semantics. They are the same kind of thing.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
"Anton van Straaten" <·····@appsolutions.com> writes:
> Erann Gat wrote:
> > or
> >
> > (progn . #1=((print "This is an infinite loop") . #1#))
>
> Changing 'progn' to 'begin' "works" in MzScheme - it hangs and eats CPU
> without printing anything. A CL I tried behaved similarly, I don't know if
> anything else is expected.
They both get stuck because the code is infinite, so it cannot be
compiled, try this:
(defun foo () (progn . #1=((print "foo") . #1#)))
(compile 'foo)
(At least in Allegro, CLisp crashes on the first defun.)
Since the *true* Lisp semantics are defined on cons cells, the above
program is finite, therefore it is expected to be compilable by any
implementation that follows such semantics. (So by a Gatian argument,
the above two products should be renamed Allegro-Almost-Lisp, and
C-sorta-Lisp.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Lars Brinkhoff
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <85fzjee3l8.fsf@junk.nocrew.org>
···@jpl.nasa.gov (Erann Gat) writes:
> There are perfectly well defined CL programs that have no printable
> representation. There are CL programs which are both readable and
> printable, but which cannot be rendered into Scheme, e.g.:
>
> (progn . #1=((print "This is an infinite loop") . #1#))
Are you sure this is legal CL? There are some indications it's not:
http://groups.google.com/groups?selm=3EFFCDA4.8040703%40alum.mit.edu
http://clhs.lisp.se/Body/m_defmac.htm
The consequences are undefined if the result of fully macroexpanding
a form contains any circular list structure except in literal
objects.
http://clhs.lisp.se/Issues/iss291_w.htm
#4: Forms involving explicit circularities, such as
(PROGN . #1=((PRINT 'FOO) . #1#))
would be explicitly undefined.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
In article <··············@junk.nocrew.org>, Lars Brinkhoff
<·········@nocrew.org> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
> > There are perfectly well defined CL programs that have no printable
> > representation. There are CL programs which are both readable and
> > printable, but which cannot be rendered into Scheme, e.g.:
> >
> > (progn . #1=((print "This is an infinite loop") . #1#))
>
> Are you sure this is legal CL?
Well, it's legal in the sense that it is syntactically correct, and has a
reasonable interpretation. But in light of:
> http://clhs.lisp.se/Body/m_defmac.htm
>
> The consequences are undefined if the result of fully macroexpanding
> a form contains any circular list structure except in literal
> objects.
it's not guaranteed to do anything in particular. Heh. You learn
something new every day.
However, this doesn't alter the main point which is that in Scheme (as
defined by the standard) the above code is simply non-sensical.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> Well, it's legal in the sense that it is syntactically correct, and has a
> reasonable interpretation. But in light of:
>
> > http://clhs.lisp.se/Body/m_defmac.htm
> >
> > The consequences are undefined if the result of fully macroexpanding
> > a form contains any circular list structure except in literal
> > objects.
>
> it's not guaranteed to do anything in particular. Heh. You learn
> something new every day.
>
> However, this doesn't alter the main point which is that in Scheme (as
> defined by the standard) the above code is simply non-sensical.
Both languages do not assign any sense to this example, so it is
non-sensical in both.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
<···@barzilay.org> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > Well, it's legal in the sense that it is syntactically correct, and has a
> > reasonable interpretation. But in light of:
> >
> > > http://clhs.lisp.se/Body/m_defmac.htm
> > >
> > > The consequences are undefined if the result of fully macroexpanding
> > > a form contains any circular list structure except in literal
> > > objects.
> >
> > it's not guaranteed to do anything in particular. Heh. You learn
> > something new every day.
> >
> > However, this doesn't alter the main point which is that in Scheme (as
> > defined by the standard) the above code is simply non-sensical.
>
> Both languages do not assign any sense to this example, so it is
> non-sensical in both.
There are degrees of nonsense. Having undefined behavior is different
from being syntactically incorrect.
E.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
> I have often said that if I could ask only one question about a
> language to determine whether it's usable, it would be "does it have
> unwind-protect?". This is not because I use unwind-protect more than
> anything else. Often I don't use it at all. It's because it reveals
> a mindset that might render itself in other contexts in other ways,
> but is visible.
Unless I'm tripped up by some detail, both Dylan and R5RS Scheme have
unwind-protect. It is respected by both R5RS's call/cc and Dylan's more
restricted "exit functions" (which are single-use non-escaping
continuations).
What have I missed?
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@shell01.TheWorld.com>,
> Kent M Pitman <······@world.std.com> wrote:
>
> > I have often said that if I could ask only one question about a
> > language to determine whether it's usable, it would be "does it have
> > unwind-protect?". This is not because I use unwind-protect more than
> > anything else. Often I don't use it at all. It's because it reveals
> > a mindset that might render itself in other contexts in other ways,
> > but is visible.
>
> Unless I'm tripped up by some detail, both Dylan and R5RS Scheme have
> unwind-protect. It is respected by both R5RS's call/cc and Dylan's more
> restricted "exit functions" (which are single-use non-escaping
> continuations).
>
> What have I missed?
That I did not make a claim about Scheme in this regard. I mentioned the
above statement only in passing as an example of looking to a small criterion
to glean a larger truth, not as an assertion for or against Scheme. Neither
did I say that this was a reliable question--just a way of gleaning a single
higher order bit in the absence of prior priming; sort of like the Turing test:
If I announce my question in advance, it becomes less useful. Nevertheless,
discussing people's choices of questions for such an event reveals their
priorities.
There was a discussion on the _answer_ to the question (the one above
that I cited only peripherally) in another thread a long time ago.
Please let's not try to repeat that this soon. I did not mean to
re-open that much pain that quickly; rather, I assumed enough people
would remember it was recently discussed that it would (a) _not_
reopen and (b) be a useful referent to commonly shared information.
Guess I blew that. Anyway, q's like yours are what google is for.
Contact me privately if you can't find the thread and I'll help you.
From: ··········@YahooGroups.Com
Subject: Re: Why some people think that Scheme is not a Lisp
Date:
Message-ID: <REM-2003sep17-010@Yahoo.Com>
{{Date: Fri, 29 Aug 2003 11:10:41 -0700
From: ···@jpl.nasa.gov (Erann Gat)
The semantics of Common Lisp, unlike every other programming
langauge, are defined on Lisp objects. The semantcs of Scheme, like
every other programming language except Common Lisp, are defined on
strings. The syntax of those strings happens to be the same as the
syntax for lists, but this in and of itself does not require there to
be any particular relationship between the two.}}
Let me try to clarify the language here: First two semi-definitions:
List - A kind of pointy structure in RAM.
S-expression - The external representation of a list, as a linear
sequence of ASCII characters.
In regard to the above-stated difference between Scheme and LIsp, we
can say that the semantics of Lisp is defined on lists, whereas the
semantics of Scheme is defined on s-expressions. In Lisp, the
particular syntax is irrelevant. The programmer can write straight
non-macro code, not even ' for quote or #\ for character literal, or
the programmer can make heavy use of both character macros and
structured macros, or anything between, and after READ converts the
syntax to a list, it's all the same, only the structure and contents of
the list is important. But in Scheme, you're saying it's the
character-sequence syntax that defines the semantics, and whatever
internal (pointy or other) structure it may or may not be converted to
is undefined and essentially irrelevant to the semantics, right?
IMO, having a language that has clear semantics for operating on
internal pointy structures, as both Lisp and Scheme do, and having a
standard pointy-structure for representing program source, as only Lisp
really does, and having a standard semantics for these
pointy-structures, as only Lisp does at all, is a big win. Specifically
whether this standard internal representation is lists or something
else isn't important. But it must be something accessible to user code
in a meaningful way that corresponds to the structure. There must be a
clear relation between whole and part, between part and sub-part, as
there is in Lisp. (As a structure of pairs, CONS cells, each list
except NIL has two parts, the CAR part and the CDR part. As a formal
list, each list has zero or more parts which are the CAR part and the
CADR part and the CADDR part etc., or more cleanly as NTH with various
numeric arguments 0 1 2 ... It's the latter I'm referring to when
talking about semantics of lists which are the internal form of
programs.) If a language wants to internalize a program not as a list
but as a defstruct type of structure, with named slots for various
different kinds of things, that's just fine, providing that all
accessors are well documented and available to user programs. That
might actually be an improvement, where for example in a function
definition, the name of the function, the documentation string, the
arglist, the declaractions that apply to the args, the
pervasive-in-function declaractions, and the implicit PROGN (sequence
of statements in the body), are each clearly separated in their own
slots. The very last statement in the PROGN, the only one whose return
value isn't immediately discarded, might even be a separate slot from
earlier statements.
It's really handy to be able to write code traversing software, or
code-generating software, or code-translating software, in each case in
a nice structured way as pointy structures instead of as concatenated
strings. In every other language, it's a pain not to have this
capability, to have no code-related tools available except what is in
the IDE or otherwise provided by the vendor. It's good to be able to
write your own tools for dealing with code structure, given the
low-level primitives provided in the language, and possibly hooks into
vendor-supplied tools which you can call as subroutines.
{{Scheme's EVAL is defined to take "a Scheme program represented as
data."}}
If, as you say, the mapping between source code (in a file) and data
(in RAM) is not well-defined, then EVAL is not precisely defined at
all! Somebody attempting to pass a data structure to EVAL doesn't
really have a clue what data is needed to cause what operation to
thereby occur. For example (EVAL (QUOTE (LIST 1 2 3))) could do
anything at all include coredump, per the specs of Scheme, right?
Whereas in Lisp, it clearly means apply the function LIST to the three
numeric arguments 1 2 and 3, returning the list (1 2 3) unless the
symbol LIST has been FBOUND to something else which would be totally
bad.
{{A Scheme EVAL that took Scheme programs represented as strings would
be compliant with the standard, and arguably more in keeping with the
evolving spirit of Scheme.}}
And that would be utterly dumb, losing any advantage in having the data
already parsed to some internal structured form. Deprecating EVAL to
have no defined semantics whatsoever might be preferable. Maybe not
even have it accessible from the USER package or whatever the Scheme
equivalent is.
{{This is really the heart of the schism between Lisp and Scheme. Both
have their roots in a Lisp where there was a well-defined
relationship between code and lists. Scheme has been gradually
drifting away from that idea and towards the rest of the world where
there is a clear distinction between program and data (at least at
the user level) while CL has maintained the original idea.}}
I would prefer all the other languages, especially those (such as C)
which have clear indentation guidelines for source code which are
supposed to represent the "hierarchial program structure", especially
those (such as Java) which allow running code interpreted, drift toward
Lisp's realization that it's good to define a class of data-structure
which represents program source and a mapping between
program-source-text and data-structure-source. (In Lisp, the same class
of data is used to represent program source and ordinary data lists,
where a subtle sub-set of such instances represent valid programs. But
if there were a totally separate class of data to represent programs,
that would fine too, just as long as it's documented and the accessor
primitives are available from user code.)
[In scheme] {{that representation is not required to be accessible to
the user in any way.}}
IMO, that's a serious failing in modern Scheme, sigh.
I could be willing to try lisp-1, and see how I really like it, but
today's revelation is horrible, wish I knew it before, I don't think I
ever want to try Scheme so long as this is true.
{{It can actually change the semantics of programs. In particular, it
changes the semantics of QUOTE.}}
Can you please provide a simple example of such a discrepancy, to give
me nightmares?
{{Schemers (and Dylaners and MLers and Haskellers, with whom Schemers
have much mindset in common) shudder at Lisp's list-based eval (there
was no EVAL in Scheme before R5RS) because they think that lists
provide too little structure for representing programs.}}
Well lists provide a lot more structure than strings do!! Until and
unless Scheme or Dylan or ML etc. will standardize some alternative to
list representation of program structure, they should not think this
way. Pie in sky is not the same as something available and working.
Lisp lists work already, not perfectly but they do work.
{{The Scheme/Dylan/ML/Haskell mindset is to come up with a principled
solution to this problem (hygienic macros) whereas the CL mindset is
to come up with a workable hack (Lisp-2) and move on.}}
But have they actually come up with anything yet, fully documented
and with access primitives accessible to the user/programmer? No?
{{I do not have a position about whether Scheme is or is not a Lisp. I
think it's a waste of time to split those kinds of semantic hairs.}}
I agree. Scheme is not a read-eval-print language as defined by the
spec, whereas CL is. Agree?
Any language that has a fully integrated garbage collector, and has a
data type for either general pairs (like CONS) or general vectors, as
pointy structures, is capable of *data* list-processing in the same
sense that Lisp does, hence satisfies the original LISP acronym, right?
So Scheme, and Java or whatever, is each a Lisp in that sense,
big deal, who cares...
If and when some programming language clearly provides some alternative
to lists (daisy chains of CONS pairs) as the parsed representation of
program source, then we'll have a new class of language that is more
than just a *data* list-processing language but not exactly a
read-eval-print, some other kind of parse-run-print alternative.
If I were to work on such a project, I might prefer to have a two-pass
parser: First pass just tokenizes the source-input stream and creates a
nested list that represents the nested structure but doesn't represent
any deep semantics, but does has at each level of structure a primary
tag (in the CAR position of the list) which is a keyword telling what
kind of program structure is at this level, such as function
definition, unnamed first-class function object, IF-ELSE, WHILE-UNTIL,
MAP, etc., i.e. tells what kind of parse was used to collect this
particular level of program structure. (It would be easy to
pretty-print from this particular nested structure, to create a copy of
the input source that was properly indented per any desired convention
and for any given linelength and/or font.) Then the second pass
reorganizes the source according to semantics and produces a defstruct
type of nested structure that clearly shows the different semantic
parts at each level such as declaractions and documentation etc. (It
would be easy to write code-walkers, profilers, etc., from this
particular nested structure.)
········@hotmail.com (Tuang) writes:
> I don't yet know what people are talking about when they say that Lisp
> and Scheme are "completely different", other than that CL seems to
> come with an enormous, complicated set of add-ons (including, some
> say, a lot of legacy baggage), and that CL seems generally reputed to
> be the best choice among the Lisps for real production work. Beyond
> that, I don't know and I'm not sure I dare ask. ;-)
"Legacy baggage" is a bit strong. Even ignoring the issue of existing
code bases, I think it would help to distinguish between features
which truly there is no use for in new code, and features which with
the benefit of hindsight are not the best design ever but which are
nevertheless useful. Some people will say "remove LOOP" or "remove
FORMAT" or "lose pathnames, they're broken", but I say to them "only
after you provide an alternative that's at least as convenient".
Most languages and systems accumulate features in the latter category.
Unix is pretty much entirely composed of them, for one.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Jens Axel S�gaard <······@jasoegaard.dk> writes:
> Michael Livshin wrote:
>> "Anton van Straaten" <·····@appsolutions.com> writes:
>
>>>I think Tuang's original post expressed something that might help define a
>>>useful "Lisp community":
>
>>> "I'm trying to learn Lisp because I'm becoming fascinated with several of
>>>the ideas it embodies. I'm not referring to Common Lisp or Scheme per se,
>>>much less any specific implementation, but to the ideas that they seem to
>>>share (to the limited extent I understand them so far.)"
>
>> but this is a kind of circular reasoning. you are saying "let's
>> assert that a community exists because newbies expect it to be there".
>
> It's not circular reasoning. We are discussing this section from
> Tuang's second post:
>
> I've already begun, and I like both CL and Scheme so much that I'm
> curious to know more about what's going on in the Lisp world today. I
> pay attention to new developments and trends in other languages I work
> with, and now that I'm finding Lisp so interesting, I'm just doing the
> same with Lisp. It's a much smaller community than the big, popular
> languages (Java, C++, etc.) and more fragmented than most of the small
> languages (Python, Ruby, etc., presumably because of Lisp's age), so
> it makes it a little harder to find some types of info.
I fail to see what does this fragment add to the previous wrt
reasoning circularity. so Tuang considers both CL & Scheme lisps. I
got that already, thanks.
> well, if you consider Scheme a Lisp, then the community is deeply
> fragmented.
>
> Since Matthias was talking about Tuang's view of the Lisp community
> the real question is: "Does Tuang consider Scheme a Lisp?".
> Anton's (and my quote) clearly shows this is the case.
sure.
> Whether there actually exists such a community is a different
> discussion.
>
> To that end, count the number of people that post both in
> comp.lang.scheme and comp.lang.lisp. And draw your own
> conclusion.
count the number of people that post to both comp.lang.scheme and
comp.lang.ml. And draw your own conclusion.
--
I knew you weren't really interested.
Michael Livshin wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > I think Tuang's original post expressed something that might help define
a
> > useful "Lisp community":
> >
> > "I'm trying to learn Lisp because I'm becoming fascinated with several
of
> > the ideas it embodies. I'm not referring to Common Lisp or Scheme per
se,
> > much less any specific implementation, but to the ideas that they seem
to
> > share (to the limited extent I understand them so far.)"
>
> but this is a kind of circular reasoning. you are saying "let's
> assert that a community exists because newbies expect it to be there".
I should have edited or qualified the quote. The newbie aspect doesn't have
anything to do with what I'm getting at. I also find the ideas embodied and
shared amongst Lisp implementations to be interesting, and I've come across
other non-newbies who feel this way, so the point Tuang expressed is not
just a newbie perspective.
It's hard to know how large the community that might feel this way is, since
there's no unique place for it to congregate. Perhaps what's needed is a
newsgroup called something like comp.lang.lisp.spirit, so that people who
are interested in discussions beyond a single standardized variety of Lisp
have somewhere to discuss things without upsetting some of the more
conservative denizens of c.l.l.
> > There are significant common ideas between all Lisps, including
> > Scheme, which are not present in other kinds of non-Lisp languages.
> > Important ideas relating to syntax, functional abstraction,
> > syntactical abstraction, and ways of approaching problems. Someone
> > who understands the rationale behind one ought to be capable of
> > understanding the rationale behind the other, in a way that's not
> > true of someone only familiar with non-Lisp languages.
>
> the only idea of the above that justifies a "Lisp community" is
> "syntactic abstraction". the rest are a better match for "FP
> community", really.
I don't agree with that. There's plenty of overlap with FP, sure, but I see
a number of related things that distinguish Lisps that have a pervasive
influence on the way programs are written:
* The syntax itself, i.e. parenthesized prefix notation, which makes some of
the other features possible.
* The ability to write programs without declaring types for variables, or
requiring that those types be statically inferenceable. With a few
exceptions, this feature is unusual in the traditional FP space, and is part
of what makes Lisps good scripting languages, and helps create highly
malleable programs.
* Syntactic abstraction, both in terms of macros as well as the more general
ability to easily treat code as data, whether for analysis, source-to-source
transformations that go beyond macros, or whatever.
We apparently agree on the third point, but even if you remove that point,
the first two make for some very distinctive language characteristics which
create a great degree of commonality amongst Lisps.
> and if you look closely, you'll find that Common Lisp's and Scheme's
> ideas of syntactic abstraction are actually very, very different.
The fact that the R5RS Scheme standard has a macro system that (I assume)
isn't available for CL doesn't say anything about the nature of Lisp in
general, other than that Lisp is an amazingly extensible language platform.
Most full Scheme implementations offer a non-hygienic macro facility very
similar to CL's, and afaict, before hygienic macros became available in
Scheme, traditional Lisp-style macros were the rule. I use both hygienic
and non-hygienic macros in Scheme myself. The difference is not only in
hygiene, which isn't always such an important issue. Scheme's hygienic
macros are also more rule-oriented than traditional macros. Sometimes, that
can be useful; other times, it can be restrictive. I like being able to use
either, as I see fit - not to mention syntax-case macros, which provide a
very powerful third alternative.
Afaict, all that stops CL from having a hygienic macro facility like
Scheme's is the idea that it isn't necessary. That's debatable, but there's
nothing fundamental that prevents it being added to CL, whereas there are
fundamental syntactic issues that make it very difficult to add hygienic
macros to other languages. The common factor that makes CL capable of
supporting Scheme-style hygienic macros is that, like Scheme, it's a Lisp,
with Lisp syntax.
> when one says "the community is deeply fragmented", one implies two
> things:
>
> * fragmentation is bad.
Fragmentation can be bad if it leads to lack of cooperation between people
who might otherwise benefit from cooperation.
> * the community in question can (and should) be unified.
That last sentence should be qualified by saying "...unified around certain
issues". As one of those issues, I don't see any productive value or
benefit in over-emphasizing the differences between CL and Scheme and
discounting or ignoring the commonalities. There is far more important
semantic and syntactic commonality between CL and Scheme than between the
"scripting languages" or "OO language with C-like syntax" you gave as
examples.
The original statement to which I responded was "well, if you consider
Scheme a Lisp, then the community is deeply
fragmented". My response was "And if you don't consider Scheme a Lisp, then
the community is *really* deeply fragmented". Perhaps I should have said
"really badly" fragmented. That's based on my strong belief that Scheme
*is* a Lisp. Claiming otherwise doesn't seem justifiable to me, either
technically or historically. (Socially or politically may be a different
matter.)
But I wasn't saying that there shouldn't be different CL and Scheme
communities. See below.
> I claim that the phrase "the Lisp community is deeply fragmented", at
> least if taken to mean "well, you see, there's Common Lisp and there's
> Scheme", is pure propaganda, since the differences between CL and
> Scheme (and the communities thereof) exist for a reason, are not bad,
> and doing away with those differences is in nobody's interest.
I wasn't talking about "doing away with those differences". Communities
overlap, and serve different purposes. There's a Common Lisp community, and
there's a Scheme community, and both of those communities need to exist
separately. But they also do some things in common, including conferences
like the International Lisp Conference. If you question the existence of a
broader "Lisp community", as your earlier post seemed to, the ILC seems to
provide an answer your question.
Yes, there's fragmentation, as is inevitable in the presence of more than
one dialect of a language, but that doesn't mean there can't be a common
community interested in more than one dialect, and it shouldn't mean that
particular dialects be ejected as being too different, without much stronger
reasons than exist in this case.
As you pointed out in another post, there's also a community of people who
use both Scheme and ML, and perhaps (like me) see and value strong
commonalities between those two languages. People who like both Scheme and
ML can almost certainly discuss their common interests in
comp.lang.functional, or for that matter in comp.lang.scheme or
comp.lang.ml. Where should people who like other Lisps in addition to CL
go? The reasoning that says that since the newsgroup comp.lang.lisp is now
devoted primarily, if not exclusively, to Common Lisp, that therefore there
is, can be, or should be no broader Lisp community, isn't even a good enough
argument to be called circular.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> Perhaps what's needed is a newsgroup called something like
> comp.lang.lisp.spirit
Oh nice, that ought to bring ilias back.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, PDP-10, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Lars Brinkhoff wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
> > Perhaps what's needed is a newsgroup called something like
> > comp.lang.lisp.spirit
>
> Oh nice, that ought to bring ilias back.
I admit the name isn't perfect. But 'comp.lang.lisps' seems too potentially
confusing. OK, let's see:
comp.lang.lisp.family
comp.lang.lisp.philosophy
comp.lang.lisp.heritage
comp.lang.lisp.inclusive
comp.lang.lisp.love
;)
Anton
From: Joe Marshall
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <d6epeuri.fsf@ccs.neu.edu>
"Anton van Straaten" <·····@appsolutions.com> writes:
> Lars Brinkhoff wrote:
>> "Anton van Straaten" <·····@appsolutions.com> writes:
>> > Perhaps what's needed is a newsgroup called something like
>> > comp.lang.lisp.spirit
>>
>> Oh nice, that ought to bring ilias back.
>
> I admit the name isn't perfect. But 'comp.lang.lisps' seems too potentially
> confusing. OK, let's see:
>
> comp.lang.lisp.family
> comp.lang.lisp.philosophy
> comp.lang.lisp.heritage
> comp.lang.lisp.inclusive
> comp.lang.lisp.love
Can we have comp.lang.lisp.abuse, too?
Joe Marshall <···@ccs.neu.edu> writes:
> Can we have comp.lang.lisp.abuse, too?
Is there really enough traffic for users of a 1995-era scrolling
platform game from Crack dot com to need their own newsgroup?
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
"Anton van Straaten" <·····@appsolutions.com> wrote in message
·························@newsread2.news.atl.earthlink.net...
>
> It's hard to know how large the community that might feel this way is, since
> there's no unique place for it to congregate. Perhaps what's needed is a
> newsgroup called something like comp.lang.lisp.spirit, so that people who
> are interested in discussions beyond a single standardized variety of Lisp
> have somewhere to discuss things without upsetting some of the more
> conservative denizens of c.l.l.
>
Speaking for myself.....
I consider that the state of the art in Lisp programming has basically come
to a local equilibrium. Most people do not use all the capabilities in CL
that already exist. The only way to evolve Lisp is to put evolutionary
pressure on Lisp is to use it in demanding applications. I no longer
have a need to discuss "interesting" arm chair issues. Anytime
I have followed such an "interesting" discussion in this newsgroup it
ends up in a circular discussion ending back at the "let's use the
current method". This shows me that things have been thought out and
the people who have gone before were intelligent and thoughtful.
You have brought up the hygenic macro issue (yet another go round)
and I just have to roll my eyes up to the heavens. The only reason
some people find them interesting is that thay have the catchy mothering
name "hygenic". They are boring pattern matching glops.
In having this discussion, which basically amounts to a "let's gut the
current macro system out of CL and replace it with something less
powerful". Where do think that will go? Duh!!!
Wade
P.S. There is nothing from you personally starting a c.l.l.spirit group.
Wade Humeniuk wrote:
> Speaking for myself.....
>
> I consider that the state of the art in Lisp programming has basically
come
> to a local equilibrium. Most people do not use all the capabilities in CL
> that already exist. The only way to evolve Lisp is to put evolutionary
> pressure on Lisp is to use it in demanding applications. I no longer
> have a need to discuss "interesting" arm chair issues. Anytime
> I have followed such an "interesting" discussion in this newsgroup it
> ends up in a circular discussion ending back at the "let's use the
> current method". This shows me that things have been thought out and
> the people who have gone before were intelligent and thoughtful.
That's a perfectly reasonable perspective. I'm sure that many, if not most
CL users, and many Scheme users for that matter, feel this way. But the
circularity you mention could also be used as a justification for not
changing even when there might be reasons to.
> You have brought up the hygenic macro issue (yet another go round)
> and I just have to roll my eyes up to the heavens.
I was responding to someone else's point that "Common Lisp's and Scheme's
ideas of syntactic abstraction are actually very, very different" with the
observation that in fact, both languages are capable of performing the same
kind of syntactic abstraction, if their users so choose. CL users are happy
with their kind of macro, and that's fine. Scheme uses them too. My point
was that the fact that the two communities' macro ecology don't overlap
perfectly doesn't imply that one of the languages is not a Lisp, which was
what was being argued. If that were valid, a hygienic pattern-matching
macro fan could be expected to come to the conclusion that since (as a fan)
hygienic macros are the way of the future, the only true modern Lisp is one
with hygienic macros, thus CL is no longer a Lisp, regardless of its
historical status. Please note that the preceding sentence was a
hypothetical.
> The only reason
> some people find them interesting is that thay have the catchy mothering
> name "hygenic". They are boring pattern matching glops.
I'm starting to see how that circular discussion business arises. "Feature
X is a boring ... glop - let's use the current method". I think I can
predict where that will go, every time. But does this actually mean
anything?
> In having this discussion, which basically amounts to a "let's gut the
> current macro system out of CL and replace it with something less
> powerful". Where do think that will go? Duh!!!
You'd be completely right, if anyone were actually arguing for what you
suggest. I pointed out that it should be possible to implement a hygienic,
pattern-matching macro system as an add-on to CL, just as defmacro systems
have been implemented as add-ons in Scheme. I brought this up as an example
of the strikingly close similarities between the two Lisps. Please don't
confuse my mention of a feature, with a desire to convert all CL'ers to that
feature, and rip a corresponding existing feature out of CL.
> P.S. There is nothing from you personally starting a c.l.l.spirit group.
Nothing except time, priorities, and the like. I offer it as a suggestion,
which could actually be helpful to those here who seem to feel put upon when
the discussion strays outside the boundaries they wish to impose.
Anton
"Anton van Straaten" <·····@appsolutions.com> wrote in message
·························@newsread2.news.atl.earthlink.net...
> > current method". This shows me that things have been thought out and
> > the people who have gone before were intelligent and thoughtful.
>
> That's a perfectly reasonable perspective. I'm sure that many, if not most
> CL users, and many Scheme users for that matter, feel this way. But the
> circularity you mention could also be used as a justification for not
> changing even when there might be reasons to.
>
My personal feeling is that hardly any issues come up that justify changing.
I am also very sure if they did they would be blindingly obvious. Also spending
time in circularity (constantly changing one's mind) is demoralizing and
undermines one's commitment to a set approach and concrete base. Hence
the oscillation in such things as
Should I use Scheme or should I use CL?
Are they the same?
Are they different?
Before I decide to commit to one of them I need to "know" I am doing the "right" thing.
This doubt and fear raises these unecessary circular thoughts and undermines
people's adoption of things like CL. There is an inherent assumption that many
people have is that things were "not done right" in the past, "its obvious from the
current state we are in", CL is old, a creation of the past, thus suspect, it has to
change (or at least bend). I take a different view, "the current state we are in"
is because that's the way things are, it's not because we are making mistakes,
its because that's the way programming is. This is evidenced by newer languages
gradually taking on more and more Lisp like features as they are used. Many
Schemes take on an Object system (many like small versions of CLOS), C++
adds garbage collection, Python thinking about macros. They keep reinventing the
wheel because its the wheel. This reinvention syndrome is holding back the
state of the art.
> > name "hygenic". They are boring pattern matching glops.
>
> I'm starting to see how that circular discussion business arises. "Feature
> X is a boring ... glop - let's use the current method". I think I can
> predict where that will go, every time. But does this actually mean
> anything?
>
Yes it does, it means that we all have a mindset about where things are
and what's what. Instead of having circular discussions just cut to the
chase.
Wade
"Anton van Straaten" <·····@appsolutions.com> writes:
> Perhaps what's needed is a newsgroup called something like
> comp.lang.lisp.spirit, so that people who are interested in
> discussions beyond a single standardized variety of Lisp have
> somewhere to discuss things without upsetting some of the more
> conservative denizens of c.l.l.
Personally, I think that every measure that might avoid unduly
emotional tension among the more conservative denizens of
comp.lang.lisp is something to be warmly embraced.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID #xD26EF2A0
From: Kenny Tilton
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F4DDCA1.1090104@nyc.rr.com>
Nils Goesche wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
>
>>Perhaps what's needed is a newsgroup called something like
>>comp.lang.lisp.spirit, so that people who are interested in
>>discussions beyond a single standardized variety of Lisp have
>>somewhere to discuss things without upsetting some of the more
>>conservative denizens of c.l.l.
>
>
> Personally, I think that every measure that might avoid unduly
> emotional tension among the more conservative denizens of
> comp.lang.lisp is something to be warmly embraced.
sounds like a slippery slope leading to an NG where the only thing it is
safe to say is "lovely day!".
i need a snappy quote about how the nastiest fights are inside a family.
one or two people have a cow over Scheme and all of a sudden my
PC-checker has to be told to raise a warning every time I mention the
language? Nahhh, as Marie Antoinette said, "Let them have cows."
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
"Anton van Straaten" <·····@appsolutions.com> writes:
[ I dearly hope he doesn't feel that I quote him out of context,
because below I snip rather liberally. sorry. ]
> It's hard to know how large the community that might feel this way
> is, since there's no unique place for it to congregate. Perhaps
> what's needed is a newsgroup called something like
> comp.lang.lisp.spirit, so that people who are interested in
> discussions beyond a single standardized variety of Lisp have
> somewhere to discuss things without upsetting some of the more
> conservative denizens of c.l.l.
there's an idea.
a community should be beneficial to its members. I can see that the
"Lisp community" idea appeals to Schemers (or else they wouldn't be so
persistent in coming to c.l.l. to talk about Scheme). I don't see how
it's beneficial to CL'ers, apart from improving the attendance of the
ILC. most of the observable effect from the belief that Lisp and
Scheme are two "dialects" of the same language amounts to bad PR for
CL.
>> and if you look closely, you'll find that Common Lisp's and
>> Scheme's ideas of syntactic abstraction are actually very, very
>> different.
>
> The fact that the R5RS Scheme standard has a macro system that (I
> assume)
aye, you assume. have you ever took notice of the tendency of the
CL'ers that care to participate in such threads to know Scheme, and
the respective tendency of the Schemers to not know CL?
> I use both hygienic and non-hygienic macros in Scheme myself. The
> difference is not only in hygiene, which isn't always such an
> important issue. Scheme's hygienic macros are also more
> rule-oriented than traditional macros. Sometimes, that can be
> useful; other times, it can be restrictive. I like being able to
> use either, as I see fit - not to mention syntax-case macros, which
> provide a very powerful third alternative.
syntax-case is nice, yes. but the Lisp macro system is even nicer,
when used with CL.
> Afaict, all that stops CL from having a hygienic macro facility like
> Scheme's is the idea that it isn't necessary.
the fact that it isn't nesessary, more like. else it would be there
in some form.
> Fragmentation can be bad if it leads to lack of cooperation between
> people who might otherwise benefit from cooperation.
idea cross-polination is generally a good thing. but two entities
don't have to declare themselves as siblings in order to
cross-polinate. in fact, it's better for them not to be close
relatives at all, to prevent inbreeding. :)
>> * the community in question can (and should) be unified.
>
> That last sentence should be qualified by saying "...unified around certain
> issues". As one of those issues, I don't see any productive value or
> benefit in over-emphasizing the differences between CL and Scheme and
> discounting or ignoring the commonalities.
I certainly do. just witness the amount of newbie confusion.
> There is far more important semantic and syntactic commonality
> between CL and Scheme than between the "scripting languages" or "OO
> language with C-like syntax" you gave as examples.
from the academic or feature check-list standpoints, perhaps. but
not in practice.
> That's based on my strong belief that Scheme *is* a Lisp. Claiming
> otherwise doesn't seem justifiable to me, either technically or
> historically. (Socially or politically may be a different matter.)
society and politics is what matters most.
--
Nobody can fix the economy. Nobody can be trusted with their finger on the
button. Nobody's perfect. VOTE FOR NOBODY.
Michael Livshin wrote:
> >> and if you look closely, you'll find that Common Lisp's and
> >> Scheme's ideas of syntactic abstraction are actually very, very
> >> different.
> >
> > The fact that the R5RS Scheme standard has a macro system that (I
> > assume) [isn't available for CL]
>
> aye, you assume. have you ever took notice of the tendency of the
> CL'ers that care to participate in such threads to know Scheme, and
> the respective tendency of the Schemers to not know CL?
That's completely out of context, and not because of snipping either. I
wrote "I assume" because although I *know* that CL doesn't have a standard
hygienic macro system like Scheme's syntax-rules, I'm not sure that someone
hasn't implemented an add-on along those lines. It would require a rather
detailed knowledge of all CL implementations and all the add-ons available
for them to be sure that this wasn't the case.
I felt able to *assume* it's not the case because you, Michael Livshin, said
"Scheme's ideas of syntactic abstraction are actually very, very different."
That statement would not be true if CL had an available hygienic macro
system similar to Scheme's, hence my assumption, which I was careful to mark
as such in case I or even you had overlooked the existence of such an
optional package.
I'm trying here, I would hope you could too. "Trying" involves giving the
other person the benefit of some doubt. It also involves not scaling every
perceived transgression from an allegedly guilty individual up to the level
of an entire group, as in "the respective tendency of the Schemers".
> a community should be beneficial to its members. I can see that the
> "Lisp community" idea appeals to Schemers (or else they wouldn't be so
> persistent in coming to c.l.l. to talk about Scheme).
I made a big reason for this fairly clear in my previous post: there are
"Lisp" topics that transcend CL, and those sometimes naturally get raised
here, by others aside from "Schemers". Having been raised, I think it's
quite valid and normal for "Schemers" and users of other Lisps to respond to
such issues.
If Schemers are persistent in coming to c.l.l. to talk about Scheme, it may
not be because they want to be your buddy, but rather because discussions
are happening here that go beyond Common Lisp, whether you like it or not.
That seems to be a consequence of this newsgroup having morphed from serving
a more general function at one time, without that more general function
having been replaced. Quite possibly there was an intentional aspect
there - CL was supposed to unify Lisp, after all - but there are unintended
consequences to that.
> I don't see how it's beneficial to CL'ers, apart from
> improving the attendance of the ILC.
Perhaps you need to stand on the shoulders of a giant to be able to see
this. I'm sorry I'm not big enough to help.
> > That last sentence should be qualified by saying "...unified around
certain
> > issues". As one of those issues, I don't see any productive value or
> > benefit in over-emphasizing the differences between CL and Scheme and
> > discounting or ignoring the commonalities.
>
> I certainly do. just witness the amount of newbie confusion.
Hmm - newbie confusion about Scheme being the same language as Lisp, or
newbie naivete in bringing up Scheme or other non-CL Lisps on c.l.l., as
seems to be done in all innocence on occasion?
> > There is far more important semantic and syntactic commonality
> > between CL and Scheme than between the "scripting languages" or "OO
> > language with C-like syntax" you gave as examples.
>
> from the academic or feature check-list standpoints, perhaps. but
> not in practice.
I've already raised the macro system example, which demonstrates a
commonality that just doesn't exist between other languages. There are also
CLOS-clones implemented in Scheme - Pascal Costanza and I exchanged some CL
& Scheme examples of CLOS code in the earlier Lisp1/Lisp2 thread. What
other non-Lisp languages could implement CLOS as closely, syntactically and
semantically? How *would* you characterize Scheme and its ability to do
this, if it's not a Lisp?
> idea cross-polination is generally a good thing. but two entities
> don't have to declare themselves as siblings in order to
> cross-polinate. in fact, it's better for them not to be close
> relatives at all, to prevent inbreeding. :)
It's not a matter of "declaring themselves as siblings" - it's a matter of
acknowledging the technical and historical facts. You don't prevent
inbreeding by disowning your sister and then sleeping with her.
> society and politics is what matters most.
That's what the NASA administrators end up thinking every decade or so,
until one of their preventable run-ins with reality. Societies make
mistakes.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> Michael Livshin wrote:
>>
>> > The fact that the R5RS Scheme standard has a macro system that (I
>> > assume) [isn't available for CL]
>>
>> aye, you assume. have you ever took notice of the tendency of the
>> CL'ers that care to participate in such threads to know Scheme, and
>> the respective tendency of the Schemers to not know CL?
>
> That's completely out of context, and not because of snipping
> either.
yes. I've misread what you wrote. my apologies.
> I wrote "I assume" because although I *know* that CL doesn't have a
> standard hygienic macro system like Scheme's syntax-rules, I'm not
> sure that someone hasn't implemented an add-on along those lines.
> It would require a rather detailed knowledge of all CL
> implementations and all the add-ons available for them to be sure
> that this wasn't the case.
look at it this way: someone, somewhere, could have written, say, a
complete Python syntax reader for Scheme. does this mean, by itself,
that it is now worth talking about a desirability of giving Scheme a
Python syntax? I think not, unless a sizeable amount of people *use*
this add-on or ask for it (and then again, not ask for it because
they heard that "parenthesized syntax is, like, weird", but because
they rationally concluded, based on actual experience, that it would
be of benefit to them).
same thing with "hygienic" macros for CL. any further talk about them
only feeds the entropy. stop here.
> If Schemers are persistent in coming to c.l.l. to talk about Scheme,
> it may not be because they want to be your buddy, but rather because
> discussions are happening here that go beyond Common Lisp, whether
> you like it or not.
I think discussions about Lisp are welcome here.
>> I don't see how it's beneficial to CL'ers, apart from improving the
>> attendance of the ILC.
>
> Perhaps you need to stand on the shoulders of a giant to be able to
> see this. I'm sorry I'm not big enough to help.
you could at least hint at something I don't see.
(to make the context clearer: I'm personally not at all ignorant of
the things going on on the Scheme side. I'm following the SRFI
process, I'm looking at the PLT stuff and read their papers, I'm
consuming almost everything Olin Shivers writes, etc. the materials
I read are technical and are written in English. there's nothing
about them that needs any kind of "inside knowledge" or "belonging to
the community" to understand.)
> Hmm - newbie confusion about Scheme being the same language as Lisp,
> or newbie naivete in bringing up Scheme or other non-CL Lisps on
> c.l.l., as seems to be done in all innocence on occasion?
the myths about Lisp come in two varieties:
* "Lisp is this tiny slow academic toy language"
* "Lisp is old, too big, and unclean"
the first comes from exposure to Scheme in college and learning that
Scheme is a Lisp. the second comes from exposure to Schemers.
>> from the academic or feature check-list standpoints, perhaps. but
>> not in practice.
>
> I've already raised the macro system example, which demonstrates a
> commonality that just doesn't exist between other languages. There
> are also CLOS-clones implemented in Scheme - Pascal Costanza and I
> exchanged some CL & Scheme examples of CLOS code in the earlier
> Lisp1/Lisp2 thread. What other non-Lisp languages could implement
> CLOS as closely, syntactically and semantically? How *would* you
> characterize Scheme and its ability to do this, if it's not a Lisp?
programming in PLT/Swindle (or Guile/GOOPS) feels closer to CL than
programming in vanilla Scheme does. I guess when Scheme grows to have
all the features of CL, programming in it will feel almost identical
to CL. perhaps you could argue that PLT or Guile have a considerable
amount of Lisp nature. Scheme still doesn't.
it doesn't matter what is *possible* to do in a language. what
matters is what is being *actually done* and what is the community
consensus about what is actually done.
>> idea cross-polination is generally a good thing. but two entities
>> don't have to declare themselves as siblings in order to
>> cross-polinate. in fact, it's better for them not to be close
>> relatives at all, to prevent inbreeding. :)
>
> It's not a matter of "declaring themselves as siblings" - it's a
> matter of acknowledging the technical and historical facts. You
> don't prevent inbreeding by disowning your sister and then sleeping
> with her.
I'm not disputing that Scheme and Lisp come partly from the same
heritage. thing is, history doesn't mean as much as you think it
means. at best it can help explain some things, but appealing to
history in order to influence the future is wrong.
>> society and politics is what matters most.
>
> That's what the NASA administrators end up thinking every decade or so,
> until one of their preventable run-ins with reality. Societies make
> mistakes.
either this analogy is completely inappropriate, or I just don't get
it. care to unpack?
--
Being really good at C++ is like being really good at using rocks to
sharpen sticks.
-- Thant Tessman
Michael Livshin <······@cmm.kakpryg.net> writes:
> the myths about Lisp come in two varieties:
>
> * "Lisp is this tiny slow academic toy language"
>
> * "Lisp is old, too big, and unclean"
>
> the first comes from exposure to Scheme in college and learning that
> Scheme is a Lisp. the second comes from exposure to Schemers.
I see this as more evidence that "nobody uses it" Scheme and "nobody
learns it" Common Lisp could and should capitalize on their family
similarities rather than angrily emphasize their differences.
On 28 Aug 2003 10:09:57 -0400, Bruce Lewis <·······@yahoo.com> wrote:
>Michael Livshin <······@cmm.kakpryg.net> writes:
>
>> the myths about Lisp come in two varieties:
>>
>> * "Lisp is this tiny slow academic toy language"
>>
>> * "Lisp is old, too big, and unclean"
>>
>> the first comes from exposure to Scheme in college and learning that
>> Scheme is a Lisp. the second comes from exposure to Schemers.
>
>I see this as more evidence that "nobody uses it" Scheme and "nobody
>learns it" Common Lisp could and should capitalize on their family
>similarities rather than angrily emphasize their differences.
The problem is that they really are completely different. Yes Scheme
uses the same syntax, but really Scheme and CL take completely
different approaches to implementing a language. Scheme is IMO pretty
good for teaching general programming constructs and concepts, but
because it is so bare bones I personally don't feel like it could be
used for the prime time. Thus I am working on Common Lisp.
I'm sure there are good analogs but take this analogy:
Scheme would be similar to building an extremely simple combustion
engine all by itself. In that form it is great for teaching the
fundamentals of how engines work, but in order for it to be a useful
tool there are all kinds of things to be added to it (frame, body,
fuel injection, cooling system etc)
Common Lisp on the other hand would be more comparable to a vehicle
that is fully built, with all the amenities provided. On the other
hand, because there are specifically so many things provided it may be
a little more difficult to learn some of the underlying concepts.
I think both languages have their place, but I don't see how saying
that CL and Scheme are the same thing would be good for Lisp
development, rather I think it would be counter productive since most
people realize that Scheme is a "Toy" implementation and not suitable
for real world use. I think emphasizing that CL is not Scheme, rather
that is a production quality language is the preferable way to go.
Just my 2p
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
Doug Tolton <·······@yahoo.com> writes:
> Common Lisp on the other hand would be more comparable to a vehicle
> that is fully built, with all the amenities provided. On the other
Manual or automatic transmission?
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
On Thu, Aug 28, 2003 at 06:30:46PM +0100, Daniel Barlow wrote:
> Doug Tolton <·······@yahoo.com> writes:
> > Common Lisp on the other hand would be more comparable to a vehicle
> > that is fully built, with all the amenities provided. On the other
> Manual or automatic transmission?
Rockets don't have transmissions...
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
> I'm sure there are good analogs but take this analogy:
I think there might be a rift between what CL'ers consider part of the
language, and what Schemer's (and most other people) consider to be
part of the language. In most languages, there is a very sharp divide
between what is in the language and what is in the libraries. If
something is in the language standard, either it is a built-in
feature, or is fundemental to workings of every program written in
that language. Thus, when people from these language backgrounds see
the CL spec, they think that all the stuff in there must somehow be
special (because its in the spec!), and having that much special stuff
be part of the language traditionally an indicator of problematic
design. Now, if you follow the CL tradition of using macros to build
up the language towards your problem space, there is much less of
distinction between the language and the libraries. Thus, having the
language "pre-built" to a certain common denominator seems perfectly
natural. Meanwhile, when the same people see the tiny CL spec, they
think, "oh, how can you get anything done with just that?" and ignore
the fact that (for example) implementations like Bigloo come with tons
of support libraries with functionality similar to that in CL.
PS> Now, there is some academic validity to the claim that CL isn't as
clean. If cleanliness means getting down to the bare basics from which
all else can be built, then Scheme is definately cleaner than CL. In
practice, this probably isn't an issue. For example, Scheme has
continuations, from which advanced control-flow stems, while CL has
special-purpose control-flow features. However, a Schemer would
probably just use an EH library in real code, and the net result would
be the same.
Michael Livshin wrote:
> look at it this way: someone, somewhere, could have written, say, a
> complete Python syntax reader for Scheme. does this mean, by itself,
> that it is now worth talking about a desirability of giving Scheme a
> Python syntax? I think not, unless a sizeable amount of people *use*
>
> same thing with "hygienic" macros for CL. any further talk about them
> only feeds the entropy. stop here.
There's a phenomenon that's happened to me repeatedly in these discussions,
which has happened again here. I mention something as an example, and it's
assumed I'm arguing that this example represents a flaw in CL that needs
changing. I meant no such thing. And I think this
defend-the-CL-status-quo-even-against-non-existent-threats behavior is a big
part of why these discussions seem to go so easily off track.
I'll quote my response to Wade Humeniuk on this same issue:
"I was responding to [Michael Livshin's] point that "Common Lisp's and
Scheme's ideas of syntactic abstraction are actually very, very different"
with the observation that in fact, both languages are capable of performing
the same kind of syntactic abstraction, if their users so choose. CL users
are happy with their kind of macro, and that's fine. Scheme uses them too.
My point was that the fact that the two communities' macro ecology don't
overlap perfectly doesn't imply that one of the languages is not a Lisp,
which was what was being argued."
> > Perhaps you need to stand on the shoulders of a giant to be able to
> > see this. I'm sorry I'm not big enough to help.
>
> you could at least hint at something I don't see.
I did more than hint at it in my original message in this thread - the
significant commonality between CL and Scheme, the fact that they share
features in common which are not shared by other languages. Earlier I said
"I think there are plenty of reasons that a Lisp community which embraces
both Common Lisp and Scheme, as well as other Lisp variants, as varying
expressions of a common set of Good Ideas, would make the noosphere a better
place. I can explicate further if you wish." I haven't delivered on that
explication (since I wasn't previously asked to). At this point, I'm going
to need to take time and produce a concrete and carefully-thought out
argument, otherwise there'd be little point since it'd just be torn apart.
It seems that any argument I make has to go up against some deeply-held
convictions about what's in CL's interest and where Scheme fits into that.
> the myths about Lisp come in two varieties:
>
> * "Lisp is this tiny slow academic toy language"
>
> * "Lisp is old, too big, and unclean"
>
> the first comes from exposure to Scheme in college and learning that
> Scheme is a Lisp. the second comes from exposure to Schemers.
The Lisp reputation for "slow" has nothing to do with exposure to Scheme in
college. "Tiny academic toy" is another story, but then your beef is with
the colleges that are not properly educating their students, or putting
their education in context, or perhaps students that persist in
misunderstanding that context.
The second point can also come from a perception which people develop in
other ways. Blaming Schemers for it is a red herring. I might as well
blame CL'ers for perpetuating the perception that Scheme is a tiny toy
language. A healthy Lisp community would recognize that such accusations
are in neither side's interest.
> programming in PLT/Swindle (or Guile/GOOPS) feels closer to CL than
> programming in vanilla Scheme does. I guess when Scheme grows to have
> all the features of CL, programming in it will feel almost identical
> to CL. perhaps you could argue that PLT or Guile have a considerable
> amount of Lisp nature. Scheme still doesn't.
Then perhaps we disagree on what Scheme is. PLT and Guile are both Schemes.
They share the semantics and syntax described in R5RS. The features they
add are extensions to those semantics, many of which can be implemented in
Scheme itself. If PLT or Guile have "a considerable amount of Lisp nature",
to me, that's an argument that Scheme is a Lisp. You can't add Lisp nature
to a non-Lisp language - it just isn't possible. R5RS defines a core
language. If your beef is that "R5RS Scheme is not a Lisp", I can see your
point, although I'd state it as "R5RS Scheme is a core Lisp". Core language
specifications always look rather bare compared to full-fledged
implementations.
> >> society and politics is what matters most.
> >
> > That's what the NASA administrators end up thinking every decade or so,
> > until one of their preventable run-ins with reality. Societies make
> > mistakes.
>
> either this analogy is completely inappropriate, or I just don't get
> it. care to unpack?
I was responding to the statement "society and politics is what matters
most". At NASA, in both the Challenger and Columbia space shuttle
disasters, "society and politics" led NASA to ignore things that shouldn't
have been ignored (e.g. foam causing damage to tiles on multiple occasions),
and take actions that shouldn't have been taken (e.g. launching in very cold
weather in the presence of warnings about the dangers of that). Feynman
summarized the Challenged incident by saying "For a successful technology,
reality must take precedence over public relations, for Mother Nature cannot
be fooled."
I'm not saying the parallel between these incidents and the Lisp community
are strong, although it could be argued that the effects of attempting to
suppress a natural community will come out in other ways, such as excessive
noise on c.l.l.; or more seriously, that infighting in the Lisp community
that you want to pretend doesn't exist will turn potential newcomers off.
But really, my NASA point was just intended to show that "society and
politics is what matters most" can't be assumed to be true, and thus doesn't
justify what you want it to justify.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> Michael Livshin wrote:
> > same thing with "hygienic" macros for CL. any further talk about them
> > only feeds the entropy. stop here.
>
> There's a phenomenon that's happened to me repeatedly in these discussions,
> which has happened again here.
I am sorry, but my observation is that as soon as you post here you
start to spew BS in all directions.
> I mention something as an example, and it's assumed I'm arguing that
> this example represents a flaw in CL that needs changing. I meant
> no such thing.
Good.
> And I think this
> defend-the-CL-status-quo-even-against-non-existent-threats behavior
> is a big part of why these discussions seem to go so easily off
> track.
You started by saying "this kind of macros aren't available in CL". It
is hard, considering you arrogant overall attitude, that you meant
something else than "CL is lacking".
Mario S. Mommer wrote:
> > And I think this
> > defend-the-CL-status-quo-even-against-non-existent-threats behavior
> > is a big part of why these discussions seem to go so easily off
> > track.
>
> You started by saying "this kind of macros aren't available in CL".
As far as I know, the kind of macros in question aren't available in CL, so
that was a statement of fact. If you choose to interpret it as a criticism,
you're being overly defensive. I didn't say that they should be in CL, the
discussion was about whether the fact that CL and Scheme had different macro
systems was evidence for Scheme not being a Lisp.
> It is hard, considering you arrogant overall attitude, that you meant
> something else than "CL is lacking".
My attitude here has been one of defense. In each case, I've started out
with a simple and defensible statement, and have then been required to
either defend it to the death or simply drop it. In many cases, my
intentions have been misread and misunderstood, and I've tried quite hard to
correct that.
If that comes across as arrogant, it certainly no more than matches the
responses I've had to deal with. Until such time as the c.l.l. FAQ reads
"c.l.l. is strictly for discussion of Common Lisp", you're going to have to
deal with people who may not share your exact opinions on everything. Some
of those people may not simply back down when they're met with c.l.l.
vitriol, such as the following:
> I am sorry, but my observation is that as soon as you post here you
> start to spew BS in all directions.
Your observation is incorrect. Perhaps you are not reading my posts
carefully enough, or not trying hard enough to understand them.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> Then perhaps we disagree on what Scheme is. PLT and Guile are both
> Schemes. They share the semantics and syntax described in R5RS.
I'm fucking tired of this terminology game, sorry. if I can't move a
nontrivial program between implementations A and B without changing
the code, then I conclude that A and B implement different languages.
those languages might still be members of the Scheme family (or
perhaps "dialects of Scheme"), but thay are _different_, period. it's
hard to write non-trivial programs using pure R5RS. SRFI's will
probably help someday.
>> >> society and politics is what matters most.
>> >
>> > That's what the NASA administrators end up thinking every decade
>> > or so, until one of their preventable run-ins with reality.
>> > Societies make mistakes.
>>
>> either this analogy is completely inappropriate, or I just don't
>> get it. care to unpack?
>
> I was responding to the statement "society and politics is what
> matters most". At NASA, in both the Challenger and Columbia space
> shuttle disasters, "society and politics" led NASA to ignore things
> that shouldn't have been ignored (e.g. foam causing damage to tiles
> on multiple occasions), and take actions that shouldn't have been
> taken (e.g. launching in very cold weather in the presence of
> warnings about the dangers of that). Feynman summarized the
> Challenged incident by saying "For a successful technology, reality
> must take precedence over public relations, for Mother Nature cannot
> be fooled."
I still don't see why are you so sure that "society and politics"
means "cavalier management attitude" and "ignoring reality", and why
you take "matters most" to mean "other things don't matter at all".
--
a newbie: Why doesn't Lisp have pass by reference?
Erik Naggum: Because C++ doesn't have multiple return values.
(from a conversation in comp.lang.lisp)
Michael Livshin wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > Then perhaps we disagree on what Scheme is. PLT and Guile are both
> > Schemes. They share the semantics and syntax described in R5RS.
>
> I'm fucking tired of this terminology game, sorry.
If you want to put it that way, "Scheme is not a Lisp" is just as much of a
terminology game. If I understand correctly, some people are willing to say
that Scheme is a member of the Lisp family, and that it's a Lisp-1, but
they're not willing to say it's a Lisp. That's the ultimate terminology
game, with rules invented by a demented squirrel on crack.
> if I can't move a
> nontrivial program between implementations A and B without changing
> the code, then I conclude that A and B implement different languages.
Sure. Every variety of Lisp is a different language, so what's the issue?
They're still all Lisps. The real issue is the definition of Lisp, which
probably isn't worth getting into since we obviously disagree on it.
> >> >> society and politics is what matters most.
> >> >
> >> > That's what the NASA administrators end up thinking every decade
> >> > or so, until one of their preventable run-ins with reality.
> >> > Societies make mistakes.
> >>
> >> either this analogy is completely inappropriate, or I just don't
> >> get it. care to unpack?
> >
> > I was responding to the statement "society and politics is what
> > matters most". At NASA, in both the Challenger and Columbia space
> > shuttle disasters, "society and politics" led NASA to ignore things
> > that shouldn't have been ignored (e.g. foam causing damage to tiles
> > on multiple occasions), and take actions that shouldn't have been
> > taken (e.g. launching in very cold weather in the presence of
> > warnings about the dangers of that). Feynman summarized the
> > Challenged incident by saying "For a successful technology, reality
> > must take precedence over public relations, for Mother Nature cannot
> > be fooled."
>
> I still don't see why are you so sure that "society and politics"
> means "cavalier management attitude" and "ignoring reality", and why
> you take "matters most" to mean "other things don't matter at all".
I'm saying "matters most" needs to be qualified to something more like
"matters most some of the time, whereas other things matter more at other
times".
"Cavalier management attitude" oversimplifies the situation. I'm saying
that the attitude was in large part a function of the society within NASA
and the broader society beyond (which controls its budget). Social
pressures - e.g. the desire not to rock the boat - are one of the factors
(probably a major one) that led to ignoring real events ("normalization of
deviance"), which in turn led to apparently preventable disasters. If you
disagree with this interpretation, it doesn't really matter - the underlying
principle still holds, that there are limits to the degree that societies
can ignore reality, even though they sometimes try (defining pi=3 being a
nice example). This simply provides one example of why society and politics
doesn't always matter most. To repeat an earlier disclaimer, this wasn't
intended as a direct analogy to the Scheme/Lisp situation.
Back on topic, re society and politics in the matter in question, "Scheme is
not a Lisp" is a disputed claim at best - society and politics haven't
spoken unambiguously in favor of it, so all that can be said is that the
politics of the issue are ongoing.
Anton
Michael Livshin wrote:
> I don't see how it's beneficial to CL'ers, apart from improving
> the attendance of the ILC. most of the observable effect from
> the belief that Lisp and Scheme are two "dialects" of the same
> language amounts to bad PR for CL.
I noticed a misstatement in the above quote, which should have read "most of
the observable effect from the belief that *Common* Lisp and Scheme are two
"dialects" of the same language..." Contracting "Common Lisp" to "Lisp"
does nothing for clarity in this sort of discussion.
(Hopefully you won't try to argue that making this distinction is not
"beneficial to CL'ers".)
I wanted to say that I'm not arguing for the "dialect of the same language"
interpretation. They're clearly not the *same* language. If you prefer to
say that Common Lisp and Scheme are both languages in the Lisp family of
languages, that's OK with me. This can also be stated by saying "Common
Lisp is a Lisp" and "Scheme is a Lisp". Is there agreement on that?
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> I wanted to say that I'm not arguing for the "dialect of the
> same language" interpretation. They're clearly not the *same*
> language. If you prefer to say that Common Lisp and Scheme are
> both languages in the Lisp family of languages, that's OK with
> me.
That might be acceptable, but...
> This can also be stated by saying "Common Lisp is a Lisp" and
> "Scheme is a Lisp". Is there agreement on that?
No. Scheme willfuly departed from almost anything that might be
called ``Lisp tradition��, and the result doesn't look anything
like a Lisp to me. If a pityful toy language like Scheme would
be considered a Lisp, I'd have to say ``I'd like to program this
in Lisp (but not Scheme. If the only `Lisp� option is Scheme,
let's talk about Java instead)�� all the time.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID #xD26EF2A0
> No. Scheme willfuly departed from almost anything that might be
> called ``Lisp tradition��, and the result doesn't look anything
> like a Lisp to me. If a pityful toy language like Scheme would
> be considered a Lisp, I'd have to say ``I'd like to program this
> in Lisp (but not Scheme. If the only `Lisp� option is Scheme,
> let's talk about Java instead)�� all the time.
I'm confused. I hear this all the time on c.l.l, but there are never
accompanying examples. Why is CL so different from Scheme? Is the
CL/Scheme split kind of like the C/C++ split? Is the programming style
in CL *that* different from the programming style in Scheme, and if
so, how?
·······@mindspring.com (Rayiner Hashem) wrote:
>> No. Scheme willfuly departed from almost anything that might be
>> called ``Lisp tradition��, and the result doesn't look anything
>> like a Lisp to me. If a pityful toy language like Scheme would
>> be considered a Lisp, I'd have to say ``I'd like to program this
>> in Lisp (but not Scheme. If the only `Lisp� option is Scheme,
>> let's talk about Java instead)�� all the time.
>
>I'm confused. I hear this all the time on c.l.l, but there are never
>accompanying examples. Why is CL so different from Scheme? Is the
>CL/Scheme split kind of like the C/C++ split? Is the programming style
>in CL *that* different from the programming style in Scheme, and if
>so, how?
Perhaps more importantly: are the differences between Scheme and CL so much
greater than the differences among various Lisps? The syntax split is bigger
than in C/C++ -- C is a subset of C++, whereas useful programs don't hop
between CL and Scheme without work. But I think that was true of older Lisps
too.
Scheme did diverge from other Lisps in using lexical scoping, as did T. Then
it got picked by Common Lisp and all the dynamic scoped Lisps are dead except
for e-lisp and lush. (Well, and maybe others I haven't heard of.) (lush is
dynamic in interpreted mode, lexical in compiled mode, to fend off
nitpickers.) And the e-lisp people talk about moving to CL or Scheme. So
here Scheme diverged and got followed.
I think some people in the Scheme world questioned whether macros were
necessary, and macros seem an essential part of the full Lisp experience, but
they're part of the Scheme standard now, so.
-xx- Damien X-)
Damien R. Sullivan wrote:
> ·······@mindspring.com (Rayiner Hashem) wrote:
> > [Nils Goesche wrote:]
> >> No. Scheme willfuly departed from almost anything that might be
> >> called ``Lisp tradition��, and the result doesn't look anything
> >> like a Lisp to me.
...
> >
> >I'm confused. I hear this all the time on c.l.l, but there are never
> >accompanying examples.
...
> Perhaps more importantly: are the differences between Scheme and CL so
much
> greater than the differences among various Lisps?
Exactly.
I'm sure it's already obvious, but you can add me to the list of people
unfamiliar with the reasons that Scheme might be considered as having
"willfuly departed from almost anything that might be called ``Lisp
tradition��", or why it "doesn't look anything like a Lisp". If there are
any papers or notes on the subject, or threads which summarizes it without
having to wade through years of history, I'd love to see them.
Specifically:
* Is this just referring to the RnRS or IEEE Scheme standard, whereas
fully-fledged Schemes like PLT and Guile may still be considered Lisps, as
Michael Livshin said he thought? (In which case, the list of
Schemes-that-are-Lisps is probably longer, including e.g. Scheme48 and
Chez.) If it's the minimal standard that's the issue, this may be based on
different interpretations of what the Scheme standard is intended to
achieve.
* Or, are there some very simple, fundamental things that Scheme is missing
that even the more complete implementations cannot do, or do well? If one
goes by the Scheme standards, one might assume that defmacro-style macros
and CLOS-style objects are not part of Scheme, but in practice both are
available to most Scheme users.
* If hygienic and/or pattern-matching macros are one of the things at issue,
I've already tried to address that. Conceivably, such macros could be added
to almost any Lisp, which to me indicates that there's nothing non-Lisp-like
about them, unfamiliar or undesirable as they may be to defmacro fans.
I could speculate further, but if I haven't already hit on it above, what
are the elements of Lisp tradition that Scheme has departed from, and what
are the things which don't look anything like a Lisp?
Anton
········@cs.indiana.edu (Damien R. Sullivan) writes:
> Scheme did diverge from other Lisps in using lexical scoping, as did T. Then
> it got picked by Common Lisp and all the dynamic scoped Lisps are dead except
> for e-lisp and lush.
What were the main Lisps which influenced Common Lisp? I tend to
think of the names Maclisp, Interlisp and Zetalisp, in this
context. Were they dynamically scoped ?
Jacek Generowicz <················@cern.ch> writes:
> What were the main Lisps which influenced Common Lisp? I tend to
> think of the names Maclisp, Interlisp and Zetalisp, in this
> context.
CLtL1 mentions these on the cover: MACLISP, SCHEME, SPICE LISP,
ZETALISP, STANDARD LISP, NIL.
The first sentence in the introduction says "COMMON LISP is a new
dialect of LISP, a successor to MACLISP, influenced strongly by
ZETALISP and also to some extent by SCHEME and INTERLISP."
--
Lars Brinkhoff, Services for Unix, Linux, GCC, PDP-10, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Nils Goesche wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > I wanted to say that I'm not arguing for the "dialect of the
> > same language" interpretation. They're clearly not the *same*
> > language. If you prefer to say that Common Lisp and Scheme are
> > both languages in the Lisp family of languages, that's OK with
> > me.
>
> That might be acceptable, but...
>
> > This can also be stated by saying "Common Lisp is a Lisp" and
> > "Scheme is a Lisp". Is there agreement on that?
>
> No. Scheme willfuly departed from almost anything that might be
> called ``Lisp tradition��, and the result doesn't look anything
> like a Lisp to me. If a pityful toy language like Scheme would
> be considered a Lisp, I'd have to say ``I'd like to program this
> in Lisp (but not Scheme. If the only `Lisp� option is Scheme,
> let's talk about Java instead)�� all the time.
I suggest the c.l.l. FAQ should be updated to reflect this attitude, by
adding a sentence such as the following to "1.4 Is Scheme a lisp?":
"[Some|many] regular c.l.l. participants feel strongly that it is incorrect
to say that "Scheme is a Lisp", and posts which state or assume that such is
the case are likely to lead to unproductive discussion."
BTW, I'd like to note that your characterization of Scheme as a "pityful toy
language" is exactly the kind of thing that a healthy Lisp community would
try to avoid indulging in. You may feel that Scheme has somehow abandonded
what you see as Lisp tradition, but others see it differently. Rather than
staking a highly political and controversial claim that your meaning of the
term Lisp is the right one and others should be considered invalid, can't
you simply say something like "I prefer to program in a big Lisp, such as
CL" ?
Anton
From: Nils Goesche
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <lyvfshrbd4.fsf@cartan.de>
"Anton van Straaten" <·····@appsolutions.com> writes:
> I suggest the c.l.l. FAQ should be updated to reflect this attitude,
> by adding a sentence such as the following to "1.4 Is Scheme a
> lisp?":
>
> "[Some|many] regular c.l.l. participants feel strongly that it is
> incorrect to say that "Scheme is a Lisp", and posts which state or
> assume that such is the case are likely to lead to unproductive
> discussion."
Sounds good.
> BTW, I'd like to note that your characterization of Scheme as a
> "pityful toy language" is exactly the kind of thing that a healthy
> Lisp community would try to avoid indulging in. You may feel that
> Scheme has somehow abandonded what you see as Lisp tradition, but
> others see it differently. Rather than staking a highly political
> and controversial claim that your meaning of the term Lisp is the
> right one and others should be considered invalid,
I am saying that the term Lisp as I understand it does not denote
anything Scheme is a member of. You disagree. So, I consider /your/
definition as invalid, you consider /mine/ as invalid.
And nothing about my understanding is controversial in comp.lang.lisp.
The Scheme community and the Lisp community have been seperated for a
long time and this is generally a good thing. If they weren't, you'd
post your ``CL is unclean�� opinions not on comp.lang.scheme, where
they are welcome, but here, causing eternal flame wars. Just why are
you so eager to get people talking about Scheme in comp.lang.lisp?
What's wrong with comp.lang.scheme? You don't see me coming to
comp.lang.scheme telling people how pitiful their little toy language
is unless they change it into Common Lisp, either, right?
> can't you simply say something like "I prefer to program in a big
> Lisp, such as CL" ?
No. There might be circumstances where I'd want to use a small Lisp.
In that case, I'd choose a real Lisp like ISLISP, not Java, not Algol,
not Scheme.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
From: Kenny Tilton
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F4E3956.4080207@nyc.rr.com>
Nils Goesche wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
>
>>I suggest the c.l.l. FAQ should be updated to reflect this attitude,
>>by adding a sentence such as the following to "1.4 Is Scheme a
>>lisp?":
>>
>>"[Some|many] regular c.l.l. participants feel strongly that it is
>>incorrect to say that "Scheme is a Lisp", and posts which state or
>>assume that such is the case are likely to lead to unproductive
>>discussion."
Moooooooooooooooooooooo. I think it would be an incredible embarrassment
to the entire community to think we need this in the FAQ to guard
against a subtle issue of taxonomy being raised here. Why not just say?:
"[some|many] are barking mad hysterics low on meds so please don't
suggest recursion where iteration will do."
Hmmm. Does have a ring to it. And while we're at it, maybe we should
mention something about not getting [some|many] upset by using camelCase
in code snippets.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
Nils Goesche wrote:
> I am saying that the term Lisp as I understand it does not denote
> anything Scheme is a member of. You disagree. So, I consider /your/
> definition as invalid, you consider /mine/ as invalid.
True. However, your definition tries to exclude people. Mine doesn't.
Given that choice, I'm suggesting that inclusion is better, even if that
involves a certain amount of agreeing to disagree.
> And nothing about my understanding is controversial in comp.lang.lisp.
That may be so, although I don't personally have evidence of it. It could
also be the case that CL'ers who feel otherwise have simply given up on
discussing it, and have learned which subjects to avoid. That's why I
suggested the FAQ change, which would make the issue clear to everyone.
> The Scheme community and the Lisp community have been seperated for a
> long time and this is generally a good thing. If they weren't, you'd
> post your ``CL is unclean�� opinions not on comp.lang.scheme, where
> they are welcome, but here, causing eternal flame wars.
I'm suggesting that a healthy Lisp community would avoid such things. I
haven't posted "CL is unclean" here, or anything like it.
> Just why are you so eager to get people talking about Scheme in
comp.lang.lisp?
I'm not. Re-read the thread. The thread began with a question about Lisps
in general. Michael Livshin raised a point about Scheme, to which I
responded.
> What's wrong with comp.lang.scheme? You don't see me coming to
> comp.lang.scheme telling people how pitiful their little toy language
> is unless they change it into Common Lisp, either, right?
As I've said, I haven't made any statements about changing Common Lisp, so
what you're suggesting has nothing to do with what I've been saying. If
you're going to respond to me, I'd appreciate it if you pay closer attention
to what I've actually been saying.
The issue in this case is that comp.lang.scheme is not designated for
discussions of Lisp in general. C.l.l. still is. I have interests that go
beyond Scheme alone: in the history of Lisp (see my earlier question about
McCarthy's attribution of parenthesized prefix notation); in Lisps that have
been used for specialized purposes, such as Gregory Chaitin's "toy" Lisp; in
Lisps that are used as scripting languages in various systems; in the way
Lisp has influenced other languages.
I have a more inclusive notion of what Lisp is than you do. Although I can
agree to disagree with you once I know what it is we're agreeing to disagree
about, if you or anyone else respond to specific points I've made with
something I disagree with or something which misunderstands or misrepresents
my position, I may choose to respond.
Anton
From: Nils Goesche
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <lyoey9r6uq.fsf@cartan.de>
"Anton van Straaten" <·····@appsolutions.com> writes:
> Nils Goesche wrote:
> > I am saying that the term Lisp as I understand it does not denote
> > anything Scheme is a member of. You disagree. So, I consider
> > /your/ definition as invalid, you consider /mine/ as invalid.
>
> True. However, your definition tries to exclude people.
No, it excludes Scheme, among other things.
> Mine doesn't. Given that choice, I'm suggesting that inclusion is
> better, even if that involves a certain amount of agreeing to
> disagree.
Inclusion per se is not ``better�� at all. If that were the case,
we'd have to define every term to denote the entire universe. I have
tried to explain why it is better to keep Scheme discussions, and
especially Scheme advocacy, in comp.lang.scheme.
> > And nothing about my understanding is controversial in
> > comp.lang.lisp.
>
> That may be so, although I don't personally have evidence of it.
The evidence is that the only people who complain about it whenever
this comes up are comp.lang.scheme denizens who think that Common Lisp
is ``unclean��.
> It could also be the case that CL'ers who feel otherwise have simply
> given up on discussing it, and have learned which subjects to avoid.
> That's why I suggested the FAQ change, which would make the issue
> clear to everyone.
As you may have realized, there are several people posting regularly
in both comp.lang.scheme and comp.lang.lisp without causing any
trouble. That's because they understand that Scheme advocacy belongs
to comp.lang.scheme if only because there is such a thing.
> > The Scheme community and the Lisp community have been seperated
> > for a long time and this is generally a good thing. If they
> > weren't, you'd post your ``CL is unclean�� opinions not on
> > comp.lang.scheme, where they are welcome, but here, causing
> > eternal flame wars.
>
> I'm suggesting that a healthy Lisp community would avoid such
> things. I haven't posted "CL is unclean" here, or anything like it.
When having a discussion with somebody, it is always helpful to know
who you're talking to, because it is easier to understand what the
other guy is saying if you know in what ideological context his
statement was thought of and formulated. While you might not yet
openly say ``CL is unclean�� here, you have done so in
comp.lang.scheme. Hence people know that when /you/ start talking
about CL lacking ``hygienic�� macros and how ``Scheme is a Lisp��
here, this is most likely just the 1324th attempt to make Scheme
advocacy on-topic in comp.lang.lisp.
> > Just why are you so eager to get people talking about Scheme in
> > comp.lang.lisp?
>
> I'm not.
So not posting Scheme advocacy in comp.lang.lisp is fine with you?
Good. We can end this thread, then.
> Re-read the thread. The thread began with a question about Lisps in
> general. Michael Livshin raised a point about Scheme, to which I
> responded.
That's fine, just make sure you don't fall into Scheme advocacy. When
reading comp.lang.scheme, I see Common Lisp often mentioned there,
too, and usually in ways I find inaccurate and don't like. But you
don't see me jumping to its defense there. That's because saying bad
things about Common Lisp is regarded as acceptable behavior in
comp.lang.scheme. Just as saying bad things about Scheme is
considered acceptable behavior here. You'll just have to learn to
live with that, I guess :-)
> The issue in this case is that comp.lang.scheme is not designated
> for discussions of Lisp in general. C.l.l. still is.
More accurately, it is about discussions of all Lisp dialects that
don't have their own newsgroups. You may think that Scheme is one of
those dialects, whereas I don't, but in both cases Scheme discussions
belong to comp.lang.scheme, not here.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > Nils Goesche wrote:
>
> > > I am saying that the term Lisp as I understand it does not denote
> > > anything Scheme is a member of. You disagree. So, I consider
> > > /your/ definition as invalid, you consider /mine/ as invalid.
> >
> > True. However, your definition tries to exclude people.
>
> No, it excludes Scheme, among other things.
Part of this discussion was about the idea and merits of a Lisp community
that includes Scheme. Communities are composed of people, and your
definition attempts to exclude some of those people.
> Inclusion per se is not ``better�� at all. If that were the case,
> we'd have to define every term to denote the entire universe. I have
> tried to explain why it is better to keep Scheme discussions, and
> especially Scheme advocacy, in comp.lang.scheme.
I agree with that, and I haven't been suggesting otherwise.
> > > And nothing about my understanding is controversial in
> > > comp.lang.lisp.
> >
> > That may be so, although I don't personally have evidence of it.
>
> The evidence is that the only people who complain about it whenever
> this comes up are comp.lang.scheme denizens who think that Common Lisp
> is ``unclean��.
I have evidence to the contrary, which is that there are CL users who
believe that Scheme is a Lisp. So you're attempting to deny the existence
of an opinion with which you do not agree.
> > It could also be the case that CL'ers who feel otherwise have simply
> > given up on discussing it, and have learned which subjects to avoid.
> > That's why I suggested the FAQ change, which would make the issue
> > clear to everyone.
>
> As you may have realized, there are several people posting regularly
> in both comp.lang.scheme and comp.lang.lisp without causing any
> trouble. That's because they understand that Scheme advocacy belongs
> to comp.lang.scheme if only because there is such a thing.
It's because they've accepted a certain status quo. I might too, if I could
find where that status quo is laid out. So far, I have gotten in trouble
for suggesting that a small code snippet couldn't illustrate a significant
difference between Lisp1 and Lisp2; and in this thread, for saying that
considering Scheme to not be a Lisp would be indicitave of a deeply divided
Lisp community. I don't consider either to be Scheme advocacy. If you
think otherwise, please explain the error of my ways, or point out the
things I have said - in context, please - which qualify as unwanted
advocacy.
> When having a discussion with somebody, it is always helpful to know
> who you're talking to, because it is easier to understand what the
> other guy is saying if you know in what ideological context his
> statement was thought of and formulated. While you might not yet
> openly say ``CL is unclean�� here, you have done so in
> comp.lang.scheme.
I assume you're referring to a comment I made very recently, about scripting
languages. Since you raise it in a way that mischaracterizes my position, I
need to put it in context. I suggested, in a discussion on c.l.s., that
Scheme could lay claim to being the fastest scripting language, compared to
such languages as Python, Perl etc. Someone responded to my rather blanket
statement about Scheme pointing out, quite correctly, that those on c.l.l.
might not agree. I responded "Good point", and made some tongue-in-cheek
characterizations, one of which was that Scheme was the "highest performing
such language with clean semantics".
It's true that I consider Scheme's semantics cleaner than CL. The fact that
those semantics have a small formal description helps. That doesn't mean
that I consider CL unclean, and I don't believe I have ever said that. I've
more than once, in c.l.s., made flippant remarks about CL which I wouldn't
consider making in this forum. However, if you interpret such remarks -
made in c.l.s. - as anything other than good-natured joking, you are sorely
mistaken. What you are doing is extrapolating what you believe my opinion
to be, from a very small sample taken out of context. The results you have
arrived at are incorrect.
As I've stated here before, I have nothing against CL, I understand the
reasons people use CL, I agree that it's more comprehensive, more
standardized, and more oriented towards real-world development than Scheme,
or at least than most of Scheme's current implementations. I respect CL for
being a Lisp, and I'm glad when I see examples of CL applications in the
real world.
I've also come across CL people who feel a similar way about Scheme, i.e.
they understand its rationale, consider it a Lisp and respect it for that,
and are glad to hear about its successes.
> Hence people know that when /you/ start talking
> about CL lacking ``hygienic�� macros and how ``Scheme is a Lisp��
> here, this is most likely just the 1324th attempt to make Scheme
> advocacy on-topic in comp.lang.lisp.
Those people have arrived at the wrong conclusions. Although this certainly
explains the problem, since you're assuming in advance that what I say must
have the goal of Scheme advocacy, and therefore aren't willing to read and
think about what I'm actually saying. How can I *ever* correct this?
Perhaps you, and others who feel this way, should just add me to your
killfiles and be done with it.
> > > Just why are you so eager to get people talking about Scheme in
> > > comp.lang.lisp?
> >
> > I'm not.
>
> So not posting Scheme advocacy in comp.lang.lisp is fine with you?
> Good. We can end this thread, then.
This thread has nothing to do with Scheme advocacy.
> > Re-read the thread. The thread began with a question about Lisps in
> > general. Michael Livshin raised a point about Scheme, to which I
> > responded.
>
> That's fine, just make sure you don't fall into Scheme advocacy.
I don't believe I have.
> When reading comp.lang.scheme, I see Common Lisp often mentioned there,
> too, and usually in ways I find inaccurate and don't like. But you
> don't see me jumping to its defense there. That's because saying bad
> things about Common Lisp is regarded as acceptable behavior in
> comp.lang.scheme. Just as saying bad things about Scheme is
> considered acceptable behavior here. You'll just have to learn to
> live with that, I guess :-)
I can easily live with that. The problem I'm seeing is an effective
inability to discuss anything beyond CL.
> > The issue in this case is that comp.lang.scheme is not designated
> > for discussions of Lisp in general. C.l.l. still is.
>
> More accurately, it is about discussions of all Lisp dialects that
> don't have their own newsgroups.
Ah! Then why doesn't the FAQ say that?
> You may think that Scheme is one of
> those dialects, whereas I don't, but in both cases Scheme discussions
> belong to comp.lang.scheme, not here.
Whenever I want to discuss Scheme, I do it in c.l.s. I'm not discussing
Scheme here, I'm discussing the meaning of "Lisp" and the idea of an
inclusive Lisp community, which seems on-topic for this group.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> I've more than once, in c.l.s., made flippant remarks about CL which I
> wouldn't consider making in this forum. However, if you interpret
> such remarks - made in c.l.s. - as anything other than good-natured
> joking, you are sorely mistaken.
Here, Anton, is where I think you need to be more sensitive. Consider
that some people reading c.l.s have been on the receiving end of
intellectual snobbery by Schemers, who really ought to be allies.
There's a reason why not everybody thinks such good-natured joking is
funny.
Bruce Lewis wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > I've more than once, in c.l.s., made flippant remarks about CL which I
> > wouldn't consider making in this forum. However, if you interpret
> > such remarks - made in c.l.s. - as anything other than good-natured
> > joking, you are sorely mistaken.
>
> Here, Anton, is where I think you need to be more sensitive. Consider
> that some people reading c.l.s have been on the receiving end of
> intellectual snobbery by Schemers, who really ought to be allies.
I appreciate the advice, and I'll keep that in mind, thanks. For the
record, I don't believe my jokes related to CL (all three or four of them!)
have ever been of the intellectual snobbery variety, although there's always
the possibility of misinterpretation.
> There's a reason why not everybody thinks such good-natured joking is
> funny.
Part of my problem has been that having worked with all sorts of programming
languages and language communities throughout my career, I don't think I've
ever come across a situation which is quite as much of a minefield as the
CL/Scheme one. You can kid a Perl programmer about the language being
CPU-hungry, for example, and it's unlikely to start a war. In fact, the
last time I did that in a public forum, the recipient of the kidding simply
fingered Lisp in return...
In the CL/Scheme case, I'm still stepping on mines, and there doesn't seem
to be a map. In fact, if a Lisp community FAQ were developed along the
lines I've mentioned, it could act as such a map, warning newcomers about
controversial topics and laying out areas in which there's an already
established agreement to disagree.
The current c.l.l. FAQ does that a little in some areas, but I think it's
too circumspect and would require mind-reading in some cases. I notice item
3.2, "I've heard the terms 'Lisp-1' and 'Lisp-2' - what do they mean?" has
no text, for example. And Kent Pitman wonders why threads on this subject
keep appearing??
Anton
From: Kenny Tilton
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F50C5F0.2000101@nyc.rr.com>
Anton van Straaten wrote:
> In the CL/Scheme case, I'm still stepping on mines, and there doesn't seem
> to be a map. In fact, if a Lisp community FAQ were developed along the
> lines I've mentioned, it could act as such a map, warning newcomers about
> controversial topics and laying out areas in which there's an already
> established agreement to disagree.
Exellent. We'll form a committee. Yes, a committee is just the thing we
need. It will include just those people who think usenet flamewars
matter, because anyone else would just sit there making fun of them.
We'll especially need the people most freaked out over how to
characterize the relationship between scheme and lisp.
Then we get these people to agree on on what they agree? Oooookay. But
first we need to decide on the shape of the table.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
Kenny Tilton wrote:
> Anton van Straaten wrote:
> > In the CL/Scheme case, I'm still stepping on mines, and there doesn't
seem
> > to be a map. In fact, if a Lisp community FAQ were developed along the
> > lines I've mentioned, it could act as such a map, warning newcomers
about
> > controversial topics and laying out areas in which there's an already
> > established agreement to disagree.
>
> Exellent. We'll form a committee. Yes, a committee is just the thing we
> need. It will include just those people who think usenet flamewars
> matter, because anyone else would just sit there making fun of them.
> We'll especially need the people most freaked out over how to
> characterize the relationship between scheme and lisp.
>
> Then we get these people to agree on on what they agree? Oooookay. But
> first we need to decide on the shape of the table.
I hear what you've been saying, and don't really disagree with the basic
premise. However, if c.l.l. as a group can't agree enough to document some
of these issues for future reference by newcomers, then the issues are going
to keep coming up again, and again, and again, as they have done in the
past, which seems to annoy some people here. That's the definition of what
a FAQ is for. How did the entries in the existing FAQ get decided on?
Usenet flamewars may not matter in general, but in this case the wars are a
symptom of something which can be addressed in various ways. One underlying
issue I've pointed out, which has led to some of the largest and most
repetitive threads here, is that there's no group where people who have a
more inclusive notion of what Lisp is, can discuss things without being
considered to be off-topic or inflammatory.
It's been suggested that the topicality rule for c.l.l. should be, or
effectively is, "CL plus all Lisps that don't have their own group", but
that still leaves no place where there's a more level playing field between
variants, and no place where the name of any member of the greater Lisp
family can be brought up and be unambiguously considered on topic.
Two obvious ways to address this are: (1) do a better job of providing
warnings and background info about some of these issues in the c.l.l. faq,
which should at least reduce some of the more innocent stumblings into
tarpits; or (2) create a separate group for general Lisp discussion, a group
in which CL is not considered to automatically trump other dialects, and
which doesn't discourage discussion of any member of "the greater Lisp
family". The idea would not be to replace any of the existing comp.lang
groups, but rather to provide a forum for discussions that may not be
appropriate for any of the current groups. Topics could include new Lisp
dialects, which I can only imagine would not go well here. I noticed
earlier ambivalence towards the idea of having discussions related to Arc
here, for example.
Anton
Kenny Tilton <·······@nyc.rr.com> writes:
> Anton van Straaten wrote:
> > In the CL/Scheme case, I'm still stepping on mines, and there doesn't seem
> > to be a map. In fact, if a Lisp community FAQ were developed along the
> > lines I've mentioned, it could act as such a map, warning newcomers about
> > controversial topics and laying out areas in which there's an already
> > established agreement to disagree.
>
> Exellent. We'll form a committee. Yes, a committee is just the thing
> we need. It will include just those people who think usenet flamewars
> matter, because anyone else would just sit there making fun of
> them. We'll especially need the people most freaked out over how to
> characterize the relationship between scheme and lisp.
>
> Then we get these people to agree on on what they agree? Oooookay. But
> first we need to decide on the shape of the table.
But the shape of the table is verrrry important. The side who gives in
has said they are weak and will be treated accordingly by the other side.
And was that a MASH or Korean War reference?
marc
>
>
>
> --
>
> kenny tilton
> clinisys, inc
> http://www.tilton-technology.com/
> ---------------------------------------------------------------
> "Career highlights? I had two. I got an intentional walk from
> Sandy Koufax and I got out of a rundown against the Mets."
> -- Bob Uecker
Hm?
I once read the Java-Newsgroup. Dayly about 300 postings. A great
mixture through all Java aspects. Funny to read for me and place enough
for unnecessary comments. So one day there formed an active group and
build a homepage which act like a detailed FAQ for all these periodic
questions, like which books, how to setup ide, up to different VM
advantages (Jamaica~, uff).
The day arrived, the Java-Newsgroup is split up into over 5 thematic
groups, you can see this in the newsreader comp.lang.~ list. But, beside
all the typical newbie postings, the traffic of quality postings lowers
down. Thus for a while I signd up all Java-Groups and realized, that my
time runs out to follow them. Today I read nothing about Java, guess why
(hint: its boring to do the copy of a copy).
Now, as I remember there was often a CL/Scheme discussion in cll. See
the last postings and what the posters mean to stop this kind of
traffic. Yes it seems that all is worth for nothing else and I say, the
next change is taken to lead readers to an other discus of that kind.
So, is this a special strategy? Is there someone trying to split c.l.l.?
Will someone court CL programmers to Scheme? Or will one bring down the
action about the best thing that can happen to a computer? The point
looks clear and when you think about the past postings, the direction is
a clear line. (hint: only hited dogs are biting, grrr)
My point is relatively easy. My browser offers me the option -ignore
this thread- and this is exactly what I do next. Why? I am using cl,
else: no free brain capacity available. (the Schemer may smile, this one
can stay there, hm? <-:) ).
It may be that things will happen that cannot be undo, so I write this
text to exaggerate mark one point.
stefan
(followed them over three years ...)
> Anton van Straaten wrote:
> > In the CL/Scheme case, I'm still stepping on mines, and there doesn't seem
> > to be a map. In fact, if a Lisp community FAQ were developed along the
> > lines I've mentioned, it could act as such a map, warning newcomers about
> > controversial topics and laying out areas in which there's an already
> > established agreement to disagree.
> Kenny Tilton schrieb:
> Exellent. We'll form a committee. Yes, a committee is just the thing we
> need. It will include just those people who think usenet flamewars
> matter, because anyone else would just sit there making fun of them.
> We'll especially need the people most freaked out over how to
> characterize the relationship between scheme and lisp.
>
> Then we get these people to agree on on what they agree? Oooookay. But
> first we need to decide on the shape of the table.
Anton van Straaten <·····@appsolutions.com> wrote:
> I responded "Good point", and made some tongue-in-cheek
> characterizations, one of which was that Scheme was the "highest performing
> such language with clean semantics".
"Lisper! Unclean!"
Michael
Michael Sullivan wrote:
> Anton van Straaten <·····@appsolutions.com> wrote:
>
> > I responded "Good point", and made some tongue-in-cheek
> > characterizations, one of which was that Scheme was the "highest
performing
> > such language with clean semantics".
>
> "Lisper! Unclean!"
It's a pity about the pejorativeness of some of these commonly used terms.
I should have said "short semantics", or "shortest semantics". It would
still capture what I was referring to, but in a way that's (a) more
objectively defensible and (b) something that most CL fans can probably
agree with, since a common beef with Scheme is that its semantics are *too*
short, with a corresponding effect on base functionality.
BTW, "unclean" seems particularly pejorative, and I've never used that term
in connection with CL, or any other language that I can recall.
Anton
From: Nils Goesche
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <ly8ypcqyvp.fsf@cartan.de>
"Anton van Straaten" <·····@appsolutions.com> writes:
> Nils Goesche wrote:
> > "Anton van Straaten" <·····@appsolutions.com> writes:
> >
> > > Nils Goesche wrote:
> >
> > > > I am saying that the term Lisp as I understand it does not
> > > > denote anything Scheme is a member of. You disagree. So, I
> > > > consider /your/ definition as invalid, you consider /mine/ as
> > > > invalid.
> > >
> > > True. However, your definition tries to exclude people.
> >
> > No, it excludes Scheme, among other things.
>
> Part of this discussion was about the idea and merits of a Lisp
> community that includes Scheme. Communities are composed of people,
> and your definition attempts to exclude some of those people.
No. It is excluding Scheme. People can be members of more than one
community. What I want is that people who act as members of the Lisp
community leave their Scheme hats at home. There are people who can
do that but some can't, unfortunately. Imagine someone who can't had
been present at some X3J13 meeting discussing, say, FORMAT. He'd
either have to keep his mouth shut, or he'd ruin any sensible
discussion with all his ``Oh my gawd, FORMAT sucks so much. It's so
ugly. It looks like Perl.�� interjections. Yes, I'd like to have
that guy excluded, preferably after punching him on the nose first.
Now that guy would have been a pain in the ass back then. But today,
if he posted regularly on comp.lang.lisp, he'd most likely /still/ be
a major pain in the ass. It is only a matter of time until he'll
bring up the FORMAT issue again, and again, and again after that.
While nobody else in the Lisp community cares and everybody is simply
using FORMAT as it is, namely damned convenient, this guy will try to
make people talk about some FORMAT ``replacement��, which will
invariably be some awkward, Schemish, functional thing nobody else
would use. I mean, he could simply write his FORMAT replacement and
publish it as a library, but that's not what he wants. He wants to
make everybody else hate FORMAT at least as much as he does, and
convince people that FORMAT is somehow a problem which it is not. You
know, other people in the Lisp community use Lisp to write code. If
something is perceived to be a problem, like say, slow streams,
they'll complain to their vendors and they might come up with some
alternative design if necessary. Nobody has so far issued any
complaint that he cannot do formatted output conveniently.
What they do /not/ do and do /not/ want, however, but what people who
can't leave their Scheme hats at home are doing all the time, is
continually fumble with the core language to find the One True
Language because they are getting bored with the last design they'd
come up with. Scheme is such a playground. Lisp is not.
> > The evidence is that the only people who complain about it
> > whenever this comes up are comp.lang.scheme denizens who think
> > that Common Lisp is ``unclean��.
>
> I have evidence to the contrary, which is that there are CL users
> who believe that Scheme is a Lisp. So you're attempting to deny the
> existence of an opinion with which you do not agree.
As there are actually people who /use/ Common Lisp, it won't be hard
to find a Common Lisp user who'll believe that the earth is flat. If
a Lisper thinks that Scheme is a Lisp, the most likely explanation is
that he hasn't thought about the issue. I used to think that, too: It
has lots of parentheses, car, cdr, cons, how can it be not a Lisp?
And it is only natural that most Schemers think so: They typically
write Scheme code in Common Lisp and say: ``See? Same thing, more or
less.�� But Lispers don't write Scheme code in Lisp. When they see a
Schemer use five LAMBDA forms and tail recursion where a normal guy
would use LOOP and push a property onto a symbol, they cringe. If you
want to see some good, Lispish code, have a look into Norvig's
``Paradigms of Artificial Intelligence Programming��. I don't know
how hard it would be to translate that code as literally as possible
to Scheme (impossible in Standard Scheme, of course), but even if you
succeed somehow, other Schemers would hate the resulting code, too.
And Norvig's code is not just Common Lisp code, it's /Lisp code/.
That's exactly how you'd write it in Elisp or ISLISP, too, for
instance. Schemers would hate the code because they hate the Lisp way
of thinking behind it. They think differently (with their Scheme hats
on, at least). That's why Scheme is not a Lisp.
Have I made myself clear?
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche wrote:
...
> Have I made myself clear?
No, not at all. You've alluded to some idea of the Lisp way of thinking
that you've happened to settle on, and made vague generalizations about the
Scheme way of thinking, which could all be argued endlessly - because
they're matters of opinion which vary from one user to the next, and don't
get you anywhere with defining Lisp.
I'll point out two areas in which I can easily rebut your point of view:
> Scheme is such a playground. Lisp is not.
Lisp, since its inception, has been used to develop all sorts of
language-based ideas. Sometimes, those have taken the form of extensions to
some base Lisp, and sometimes they've taken the form of new Lisp dialects.
Common Lisp is a stable, practical Lisp which has unified some of the more
practically-oriented dialects, and that's very important. If you said
"Common Lisp is not a playground", that would make sense (ignoring the
possibly pejorative connotations of "playground"). To say that "Lisp" is
not a playground, in the sense of a testbed and platform for the development
of innovative ideas, flies in the face of Lisp's entire history.
My second point has to do with the question of programming styles across
Lisps. One of the (multiple) styles that's fairly common in Scheme is a
functional style. Perhaps you think that a highly functional style is
non-Lisp-like? In that case, I refer once again to John McCarthy, from
http://www-formal.stanford.edu/jmc/history/lisp/node3.html :
"One mathematical consideration that influenced LISP was to express
programs as applicative expressions built up from variables and constants
using functions. I considered it important to make these expressions obey
the usual mathematical laws allowing replacement of expressions by
expressions giving the same value. The motive was to allow proofs of
properties of programs using ordinary mathematical methods. This is only
possible to the extent that side-effects can be avoided."
In other words, McCarthy was interested in functional programming and
referential transparency, and developed Lisp with that in mind. As such, it
would seem difficult to claim that such a style is somehow "not Lisp". In a
sense, it is what Lisp was originally created to achieve.
Certainly, referentially transparent functional programming is not what a
major branch of Lisp practice settled on, but I don't see how that makes one
interpretation "Lisp" and another "not Lisp". And besides, that style is
just one style that's used in Scheme, it's by no means the only one.
Perhaps your assumptions about the Scheme way of thinking have to do with
something other than functional style - I don't know, since you weren't
explicit. Regardless, the presence of different programming styles is only
as big a deal as you make it. I use multiple styles in multiple languages,
myself, which may explain why I have a little difficulty getting my head
around the concept of programming style as a basis for a decades-long feud.
Anton
From: Nils Goesche
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <lyn0dspedb.fsf@cartan.de>
"Anton van Straaten" <·····@appsolutions.com> writes:
> Nils Goesche wrote:
>
> > Have I made myself clear?
>
> No, not at all. You've alluded to some idea of the Lisp way of
> thinking that you've happened to settle on, and made vague
> generalizations about the Scheme way of thinking, which could all be
> argued endlessly - because they're matters of opinion which vary
> from one user to the next, and don't get you anywhere with defining
> Lisp.
>
> I'll point out two areas in which I can easily rebut your point of
> view:
I am not arguing. I have tried to /explain/ something. There is no
need to ``rebut�� anything. Can I formally prove anything I said?
No. You said you wanted to understand why certain things will be met
with hostility, I tried to explain it to you. Now you could try to
understand what I said or you don't. It's up to you.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
...
> > I'll point out two areas in which I can easily rebut your point of
> > view:
>
> I am not arguing. I have tried to /explain/ something. There is no
> need to ``rebut�� anything. Can I formally prove anything I said?
> No. You said you wanted to understand why certain things will be met
> with hostility, I tried to explain it to you. Now you could try to
> understand what I said or you don't. It's up to you.
I'll rephrase. I pointed out two areas as evidence against the claim that
"Scheme is not a Lisp", as you've described it. If the claim is weak, your
ability to make it is diminished. You're free to hold it as an opinion, but
if you choose to assert it, you're likely to meet disagreements, which
hopefully will not be presented with hostility, but with rational arguments.
Regarding understanding what you've said, I've tried. However, there were
too many implicit assumptions about what you think Lisp code should look
like, and generalizations about what you think Scheme code looks like, for
me to gather anything beyond a vague idea of what you're getting at.
Insofar as I understand that vague idea, it doesn't seem very compelling, as
I've pointed out.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> Insofar as I understand that vague idea, it doesn't seem very
> compelling, as I've pointed out.
I didn't expect you to find it compelling.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID #xD26EF2A0
Nils Goesche wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>>Part of this discussion was about the idea and merits of a Lisp
>>community that includes Scheme. Communities are composed of people,
>>and your definition attempts to exclude some of those people.
>
> No. It is excluding Scheme. People can be members of more than one
> community. What I want is that people who act as members of the Lisp
> community leave their Scheme hats at home. There are people who can
> do that but some can't, unfortunately. Imagine someone who can't had
> been present at some X3J13 meeting discussing, say, FORMAT. He'd
> either have to keep his mouth shut, or he'd ruin any sensible
> discussion with all his ``Oh my gawd, FORMAT sucks so much. It's so
> ugly. It looks like Perl.�� interjections. Yes, I'd like to have
> that guy excluded, preferably after punching him on the nose first.
You seem to be really sensitive wrt this issue.
An important part of the history of the Lisp family of languages
consists of discussions about language constructs. This isn't a great
surprise because Lisp's strongest advantage is that the line between
programming and language design is blurred.
Constructive discussions about language design include references to how
things are done in other languages. This really helps to broaden one's
view, as has repeatedly been shown in the history of Lisp.
So when discussing a particular feature of Common Lisp, it's sometimes
helpful to have discussions of the sort "look, this is how it is done in
X", with X being replaced by some languages. X can be any language. And
of course, it _must_ be possible to criticize the way certain things are
done in Common Lisp. That's because Common Lisp isn't perfect. No
language is perfect and of course, this includes all the Lisp languages
as well.
One can get the impression that some people in c.l.l react much more
sensitive when X is Scheme than when X is any other language.
Let me stress again that these sorts of discussions are important. They
may be of minor importance to pure practitioners - these people want to
get their job done and are not interested in nitpicking. That's fine.
However, Lisp attracts language researchers, and this is generally a
good thing. Many successful languages have also a strong backing in the
academic world. (For example, look at all the language extensions that
are built around Java. Yes, many of them suck, but that's besides the
point.)
For language researchers such discussions are their _essential_
motivating activities. If you actively try to prevent people from
leading such discussions, you risk to lose an important audience to
other languages. They will continue their work, but probably with other
languages, so you don't gain anything from your behavior. To the contrary.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
From: Nils Goesche
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <lyvfsgpfmi.fsf@cartan.de>
Pascal Costanza <········@web.de> writes:
> Nils Goesche wrote:
>
> > He'd either have to keep his mouth shut, or he'd ruin any sensible
> > discussion with all his ``Oh my gawd, FORMAT sucks so much. It's
> > so ugly. It looks like Perl.�� interjections. Yes, I'd like to
> > have that guy excluded, preferably after punching him on the nose
> > first.
>
> You seem to be really sensitive wrt this issue.
Just annoyed, and tired.
> An important part of the history of the Lisp family of languages
> consists of discussions about language constructs. This isn't a
> great surprise because Lisp's strongest advantage is that the line
> between programming and language design is blurred.
>
> Constructive discussions about language design include references to
> how things are done in other languages. This really helps to broaden
> one's view, as has repeatedly been shown in the history of Lisp.
Sure. Of course. But that doesn't mean we should invite every C++,
Perl and Haskell freak who doesn't understand what Lispers want to
join and repeat his sermon about how stupid the Lisp way and how cool
the Perl way is over and over again in case anybody missed it the
1324th time he repeated it.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche wrote:
> I am saying that the term Lisp as I understand it does not denote
> anything Scheme is a member of. You disagree. So, I consider /your/
> definition as invalid, you consider /mine/ as invalid.
>
> And nothing about my understanding is controversial in comp.lang.lisp.
I tend to disagree with your point of view. And here is some empirical
evidence that the designers of both Scheme and Common Lisp consider both
languages as members of the same family of languages:
+ One of the first publications about Scheme has the subtitle "A Dialect
of Lisp". See ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-452.pdf
+ CLtL2 mentions Scheme on its cover. See
http://www.csc.villanova.edu/~klassner/csc4500/resources.html (look
closely on the book cover - unfortunately, I haven't found a bigger
picture.)
+ The Common Lisp ANSI standard has the following description of Scheme
in its introductory sections:
"One of the most important developments in Lisp occurred during the
second half of the 1970's: Scheme. Scheme, designed by Gerald J. Sussman
and Guy L. Steele Jr., is a simple dialect of Lisp whose design brought
to Lisp some of the ideas from programming language semantics developed
in the 1960's."
See http://www.lispworks.com/reference/HyperSpec/Body/01_ab.htm
(It's also included in the ANSI documents - I have checked it.)
Although of course all these people might be wrong, this evidence proves
at least that it doesn't seem too far-fetched to call Scheme a Lisp.
So what are your main arguments that oppose this point of view?
Pascal
Wolfhard Bu� wrote:
>>"One of the most important developments in Lisp occurred during the
>>second half of the 1970's: Scheme. Scheme, designed by Gerald
>>J. Sussman and Guy L. Steele Jr., is a simple dialect of Lisp whose
>>design brought to Lisp some of the ideas from programming language
>>semantics developed in the 1960's."
>
> It's true that some Lispniks got affected by an algolish teaching
> vehicle in the eighties.
"some"? "teaching vehicle"?
Among other things, we are talking about lexical scoping here. CL has it
by default, and this is because of the experience with Scheme.
Or do you really want to suggest that a purely dynamically scoped Common
Lisp would have been just as good?
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> + CLtL2 mentions Scheme on its cover. See
> http://www.csc.villanova.edu/~klassner/csc4500/resources.html
That's really the first edition.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, PDP-10, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
From: Nils Goesche
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <lyd6eor22a.fsf@cartan.de>
Pascal Costanza <········@web.de> writes:
> Although of course all these people might be wrong, this evidence
> proves at least that it doesn't seem too far-fetched to call Scheme
> a Lisp.
>
> So what are your main arguments that oppose this point of view?
Just the ones that have been discussed here a thousand times before.
Sorry, I really don't feel like repeating those threads. Nobody is
going to change my mind, and neither am I going to change anybody
else's mind in yet another thread about that.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche wrote:
> Pascal Costanza <········@web.de> writes:
>
>>Although of course all these people might be wrong, this evidence
>>proves at least that it doesn't seem too far-fetched to call Scheme
>>a Lisp.
>>
>>So what are your main arguments that oppose this point of view?
>
> Just the ones that have been discussed here a thousand times before.
> Sorry, I really don't feel like repeating those threads. Nobody is
> going to change my mind, and neither am I going to change anybody
> else's mind in yet another thread about that.
At least, some pointers would be helpful.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
From: Nils Goesche
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <lyr834pf23.fsf@cartan.de>
Pascal Costanza <········@web.de> writes:
> Nils Goesche wrote:
> > Pascal Costanza <········@web.de> writes:
> >
> >>Although of course all these people might be wrong, this evidence
> >>proves at least that it doesn't seem too far-fetched to call Scheme
> >>a Lisp.
> >>
> >>So what are your main arguments that oppose this point of view?
> > Just the ones that have been discussed here a thousand times before.
> > Sorry, I really don't feel like repeating those threads. Nobody is
> > going to change my mind, and neither am I going to change anybody
> > else's mind in yet another thread about that.
>
> At least, some pointers would be helpful.
I think I gave an explanation in the posting you responded to at
Fri, 29 Aug 2003 18:27:07 +0200
You could also start with the ``Why is Scheme not a Lisp?�� thread
from March 2002. And there were numerous others. Just Google for
them if you want more.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche wrote:
> You could also start with the ``Why is Scheme not a Lisp?�� thread
> from March 2002. And there were numerous others. Just Google for
> them if you want more.
Thanks for the reference. My favorite quote from that thread is by Doug
Quale:
"As a final thought, it's quite funny that someone can say that Common
Lisp is a lisp-2 and Scheme is a lisp-1, and then in the next breath say
Scheme is not a Lisp."
Nils Goesche:
> You could also start with the ``Why is Scheme not a Lisp?�� thread
> from March 2002. And there were numerous others. Just Google for
> them if you want more.
Anton van Straaten:
> Thanks for the reference. My favorite quote from that thread is by Doug
> Quale:
>
> "As a final thought, it's quite funny that someone can say that Common
> Lisp is a lisp-2 and Scheme is a lisp-1, and then in the next breath say
> Scheme is not a Lisp."
Indeed. TLC-LISP was a Lisp1. Don't know of any other.
--
"Hurry if you still want to see something. Everything is vanishing."
-- Paul C�zanne (1839-1906)
In article <··············@buss-14250.user.cis.dfn.de>,
·····@gmx.net (Wolfhard Bu�) wrote:
> Nils Goesche:
> > You could also start with the ``Why is Scheme not a Lisp?�� thread
> > from March 2002. And there were numerous others. Just Google for
> > them if you want more.
>
> Anton van Straaten:
> > Thanks for the reference. My favorite quote from that thread is by Doug
> > Quale:
> >
> > "As a final thought, it's quite funny that someone can say that Common
> > Lisp is a lisp-2 and Scheme is a lisp-1, and then in the next breath say
> > Scheme is not a Lisp."
>
> Indeed. TLC-LISP was a Lisp1. Don't know of any other.
EuLisp.
Nils Goesche <···@cartan.de> wrote in message news:<··············@darkstar.cartan>...
> No. Scheme willfuly departed from almost anything that might be
> called ``Lisp tradition��, and the result doesn't look anything
> like a Lisp to me. If a pityful toy language like Scheme would
> be considered a Lisp,
Who are we talking about nowadays? Some guys on usenet saying "You
suck"? All this lisp politics only makes sense to me in the context
of revising the CL standard, which a) is costly and b) will probably
be controlled and financed by entrenched companies like Franz, whose
customers won't be thrilled by rewriting code. Even though there
isn't that much CL code by the standards of Java/C/C++, large painful
changes seem unlikely.
Therefore it seems that all these language politics are really usenet
politics now. If you look at programming trends, people are
interested in merging languages with tools like agnostic interpreters,
and defining guidelines on which language is appropriate for situation
X. The python usenet group seems interested when MLers or CLers talk
about useful techniques that could be supported, and Java people are
glad that they can use CL memoization techniques through proxy
classes.
I'm posting this because I have a general interest in communities, and
it seems that certain forums can be stuck on points like this. Even
though it's clear that there are no visible forces who can actually
force a CL revision in the next few years. So you're not arguing
against people who happen to use Scheme (like me) but Slashdot-style
trolls. If I'm wrong, I'd be grateful if you could help me
understand.
Tayss wrote:
> Who are we talking about nowadays? Some guys on usenet saying "You
> suck"? All this lisp politics only makes sense to me in the context
> of revising the CL standard
...
> Therefore it seems that all these language politics are really usenet
> politics now.
Usenet politics are presumably a visible representation of some underlying
attitudes that extend beyond Usenet, though.
I don't think any of the current discussion has anything to do with revising
the CL standard. It has to do with how the relationship between CL and
Scheme is perceived, and whether the respective communities might benefit
from more cooperation, which could include things like declaring a "truce"
around the "you suck" kind of claims.
Anton
From: Nils Goesche
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <ly4r00qys9.fsf@cartan.de>
··········@yahoo.com (Tayss) writes:
> I'm posting this because I have a general interest in communities,
Sorry, I haven't.
> and it seems that certain forums can be stuck on points like this.
> Even though it's clear that there are no visible forces who can
> actually force a CL revision in the next few years. So you're not
> arguing against people who happen to use Scheme (like me) but
> Slashdot-style trolls. If I'm wrong, I'd be grateful if you could
> help me understand.
Right: I have absolutely nothing against Scheme users.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
From: Damien Kick
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <ovwucpscfw.fsf@email.mot.com>
"Anton van Straaten" <·····@appsolutions.com> writes:
> I wanted to say that I'm not arguing for the "dialect of the same
> language" interpretation. They're clearly not the *same* language.
> If you prefer to say that Common Lisp and Scheme are both languages
> in the Lisp family of languages, that's OK with me.
Common Lisp and Scheme have to be members of the same family. Only
family members would spend this much time bickering with each other.
Damien Kick wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
>
>>I wanted to say that I'm not arguing for the "dialect of the same
>>language" interpretation. They're clearly not the *same* language.
>>If you prefer to say that Common Lisp and Scheme are both languages
>>in the Lisp family of languages, that's OK with me.
>
>
> Common Lisp and Scheme have to be members of the same family. Only
> family members would spend this much time bickering with each other.
:-)
That's a good one!
Pascal
Michael Livshin <······@cmm.kakpryg.net> writes:
> but that's exactly analogous to the "scripting language" community
> being deeply fragmented: Perl, Python, sh & Ruby are all scripting
The fragmentation matters because the Perl or Python communities alone
are larger than the Lisp family languages together. Let's say you want
to write a cross-platform GUI application: you can choose between
multiple free frameworks (with native widgets/without, etc) with lots
of documentation as a Python user. Or you want to build a web
application: choose between multiple good, more less well documented
frameworks (e.g. Zope, Twisted, Webware) each supported by a
relatively large community.
Nils Kassube wrote:
> Michael Livshin <······@cmm.kakpryg.net> writes:
>
> > but that's exactly analogous to the "scripting language" community
> > being deeply fragmented: Perl, Python, sh & Ruby are all scripting
>
> The fragmentation matters because the Perl or Python communities alone
> are larger than the Lisp family languages together. Let's say you want
> to write a cross-platform GUI application: you can choose between
> multiple free frameworks (with native widgets/without, etc) with lots
> of documentation as a Python user. Or you want to build a web
> application: choose between multiple good, more less well documented
> frameworks (e.g. Zope, Twisted, Webware) each supported by a
> relatively large community.
And there are features which all Lisps could benefit from - for example a
replacement for FORMAT, which is being discussed elsewhere in this thread.
A good replacement for FORMAT could be useful to any Lisp, including Scheme,
and cooperation on such things would be far more useful than pretending that
there are two almost unrelated languages which have nothing to do with each
other.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> And there are features which all Lisps could benefit from - for example a
> replacement for FORMAT, which is being discussed elsewhere in this thread.
> A good replacement for FORMAT could be useful to any Lisp, including Scheme,
> and cooperation on such things would be far more useful than pretending that
> there are two almost unrelated languages which have nothing to do with each
> other.
Caught you red-handed spewing BS.
FORMAT is a non-issue, for christs sake. Splitting hairs is not going
to benefit anybody, except those that hate Lisp.
Mario S. Mommer wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
> > And there are features which all Lisps could benefit from - for example
a
> > replacement for FORMAT, which is being discussed elsewhere in this
thread.
> > A good replacement for FORMAT could be useful to any Lisp, including
Scheme,
> > and cooperation on such things would be far more useful than pretending
that
> > there are two almost unrelated languages which have nothing to do with
each
> > other.
>
> Caught you red-handed spewing BS.
>
> FORMAT is a non-issue, for christs sake. Splitting hairs is not going
> to benefit anybody, except those that hate Lisp.
I was talking about something being discussed by other CL users in this
thread. Perhaps you disagree with those users about the need for what
they're discussing, but that's really besides the point.
I chose to mention that example because I happen to share at least an aspect
of the opinion which leads to a desire for something other than a
FORMAT-style solution, namely the feeling that encoding formatting
information in raw, unstructured strings isn't necessarily the best
solution, or at least shouldn't be the only solution.
I don't see how any of this qualifies as "spewing BS". Alleging that only
"those that hate Lisp" would discuss such things is a transparent attempt to
shut down discussion. The part of the discussion that needs to be shut
down, however, are the sorts of comments you're making, which serve no
constructive purpose.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> I don't see how any of this qualifies as "spewing BS". Alleging that only
> "those that hate Lisp" would discuss such things is a transparent attempt to
> shut down discussion.
Your reading skills are lacking.
> The part of the discussion that needs to be shut down, however, are
> the sorts of comments you're making, which serve no constructive
> purpose.
I think instead we could arange a monthly lisp1 vs. lisp2 tournament.
Mario S. Mommer wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
> > I don't see how any of this qualifies as "spewing BS". Alleging that
only
> > "those that hate Lisp" would discuss such things is a transparent
attempt to
> > shut down discussion.
>
> Your reading skills are lacking.
Care to explain? You wrote: "Caught you red-handed spewing BS. FORMAT is a
non-issue, for christs sake. Splitting hairs is not going to benefit
anybody, except those that hate Lisp."
Why don't you simply apologize for your remark, instead?
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> Care to explain? You wrote: "Caught you red-handed spewing BS. FORMAT is a
> non-issue, for christs sake. Splitting hairs is not going to benefit
> anybody, except those that hate Lisp."
>
> Why don't you simply apologize for your remark, instead?
Because I did not say that discussing about aternatives to format is
something that is done by those that hate lisp, just that it doesn't
benefit anybody in the Lisp comunity (btw, I think scheme looks like
lisp and smells like lisp, so it is a Lisp. That means that fretting
about format is something that won't, from my point of view, benefit
you either).
Suppose that after all these years, the scheme and common-lisp
comunities where suddenly engaged in peace talks, as is maybe starting
to happen. I would sugest, as a basis for discussion, the following
conditions for that peace.
1. The scheme comunity accepts that lisp1 vs. lisp2 is a matter of
taste and choice. I think c.l.l. is a bit further down that road
than c.l.s.
2. Stops calling CL a big, dead monster with unclean semantics (maybe
we could stop calling scheme a toy).
3. Stops ivory-towering on issues like packages, continuations, and
macro hygiene. Or as an alternative, do so acknowledging the wisdom
of making choices under practical considerations.
4. Agrees on trying to find ways to help each other. (I am
particularly amazed by the ability of scheme to worm-hole into
almost any environment, although I really prefer the full power of
CL. Maybe there is some room for cooperation on real issues that
are hurting us all?)
Does that sound reasonable to you? What would your conditions be, and
are there chances that this kind of charta can find support in both
communities?
Mario S. Mommer <········@yahoo.com> writes:
> Suppose that after all these years, the scheme and common-lisp
> comunities where suddenly engaged in peace talks, as is maybe starting
> to happen. I would sugest, as a basis for discussion, the following
> conditions for that peace.
>
> 1. The scheme comunity accepts that lisp1 vs. lisp2 is a matter of
> taste and choice. I think c.l.l. is a bit further down that road
> than c.l.s.
>
> 2. Stops calling CL a big, dead monster with unclean semantics (maybe
> we could stop calling scheme a toy).
>
> 3. Stops ivory-towering on issues like packages, continuations, and
> macro hygiene. Or as an alternative, do so acknowledging the wisdom
> of making choices under practical considerations.
>
> 4. Agrees on trying to find ways to help each other. (I am
> particularly amazed by the ability of scheme to worm-hole into
> almost any environment, although I really prefer the full power of
> CL. Maybe there is some room for cooperation on real issues that
> are hurting us all?)
>
> Does that sound reasonable to you? What would your conditions be, and
> are there chances that this kind of charta can find support in both
> communities?
I find this greatly reasonable. Now let's all get along! Death to fanatics!
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Mario S. Mommer wrote:
> Because I did not say that discussing about aternatives to format is
> something that is done by those that hate lisp, just that it doesn't
> benefit anybody in the Lisp comunity
Well, you did add the bit that went "except those that hate Lisp"! I'll
save the in-depth analysis of how that was ambiguous, and why it's
suppressive of discussion no matter its interpretation, and move onto
something more constructive.
> (btw, I think scheme looks like
> lisp and smells like lisp, so it is a Lisp.
Great!
> That means that fretting
> about format is something that won't, from my point of view, benefit
> you either).
Somewhat tangentially, have you ever looked at Olin Shivers' s-exp regular
expression language, in Scsh? That's the kind of thing that I think could
be useful as a formatting language.
> Suppose that after all these years, the scheme and common-lisp
> comunities where suddenly engaged in peace talks, as is maybe starting
> to happen. I would sugest, as a basis for discussion, the following
> conditions for that peace.
>
> 1. The scheme comunity accepts that lisp1 vs. lisp2 is a matter of
> taste and choice. I think c.l.l. is a bit further down that road
> than c.l.s.
Even better, trying to characterize which community is further down which
road is probably a bad idea. Both the Scheme and CL community should (a)
accept that lisp1 vs. lisp2 is a matter of taste and choice, and (b) accept
that each language has made its decision, which isn't going to change. That
also implies a freedom - it can be assumed that no-one will reasonably try
to argue that e.g. CL should adopt a single namespace, as I was erroneously
accused of in a previous thread. If someone does try, they can be pointed
to a Lisp community FAQ.
> 2. Stops calling CL a big, dead monster with unclean semantics (maybe
> we could stop calling scheme a toy).
Yes, that's exactly the kind of thing I had in mind, and would be one of the
benefits of a somewhat less divided community, or at least an overlap
between communities (a de-militarized zone?)
> 3. Stops ivory-towering on issues like packages, continuations, and
> macro hygiene. Or as an alternative, do so acknowledging the wisdom
> of making choices under practical considerations.
I think the alternative you give is better. There's value in having a
language that can act as an academic workbench, and as a testing ground for
new ideas. I don't think it's an accident that "Lisp" in general has often
been used for this sort of thing, and it's part of what has made Lisp
strong.
Lexical variables were once an ivory-tower, academic feature, for example.
As I've pointed out here before, Lisp was conceived partly as "a way of
describing computable functions much neater than the Turing machines or the
general recursive definitions used in recursive function theory." (John
McCarthy, http://www-formal.stanford.edu/jmc/history/lisp/node3.html ). I
think the academic and the practical need to be able to coexist
constructively, just as much as CL and Scheme.
> 4. Agrees on trying to find ways to help each other. (I am
> particularly amazed by the ability of scheme to worm-hole into
> almost any environment, although I really prefer the full power of
> CL. Maybe there is some room for cooperation on real issues that
> are hurting us all?)
Yes, finding ways to help each other, and cooperating on real issues that
affect us all was one of my underlying assumptions of the benefits of a
broader Lisp community.
> Does that sound reasonable to you?
Yes, it sounds very much like the sort of thing I had in mind.
> What would your conditions be
I can only speak for myself, not for the Scheme community. What you've laid
out so far sounds like a good starting point. Anything else would have to
be developed by constructive discussion, focusing on points of agreement.
Perhaps this could be done by collaborating on a Lisp community FAQ. At the
very least, such a FAQ might clear many topics up for newbies, in a way that
the current c.l.l. FAQ does not.
> and are there chances that this kind of charta can find support in
> both communities?
I know that there are people on both sides who would support this kind of
thing, but I have no idea how many, or how much of a priority they would
make it. From the newsgroup perspective, perhaps, as I've suggested, a
separate "general Lisp" newsgroup is needed, so that there can be a CL-only
newsgroup in which non-CL discussion is offtopic. Beyond newsgroups, since
I'm not currently involved in any kind of standards or other official
bodies, or conference organizing, I have little idea of what kind of real
ties there are between Scheme and CL.
Clearly, at the level of conferences like ILC, there is some sort of
cooperation. My exchanges in this group have been an ongoing education for
me on some of the positions on these matters held by a few CL folk, but
being an optimist, I would hope that at any level where meaningful decisions
are being made, there might be more cooperation and understanding.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> I chose to mention that example because I happen to share at least an aspect
> of the opinion which leads to a desire for something other than a
> FORMAT-style solution, namely the feeling that encoding formatting
> information in raw, unstructured strings isn't necessarily the best
> solution, or at least shouldn't be the only solution.
I think I've just worked out why I don't consider this terrifically
important, and it's simply that if anyone wants to redesign FORMAT he
could do it himself in portable ANSI code - after choosing a new name,
obviously. There is no need to produce a new Lisp to do this, nor
even to go back to ANSI with a proposal and the aim of making the
vendors do it.
That being so, then as the apparent status is that nobody has
bothered, what does that say about the perceived importance of such a
redesign? Note that this is unlike even LOOP, where alternatives for
some/all/many of its uses - aside from the builtin DO/DOTIMES/DOLIST -
include SERIES and ITERATE and a zillion COLLECTING macros.
If we're going to talk about formatted output in the context of CL or
language-in-the-same-space-as-CL, I don't think it's unreasonable to
impose a barrier to entry on discussion of "working prototype". That
doesn't mean you have to post the code - though obviously that would
be neat - but it does mean you can offer some kind of credible
evidence that you've considered the issues and done some actual
design. In the absence of this work, discussion of the "format sucks"
flavour is simply not going anywhere.
(I'm not singling Anton out here. That was a generic "you")
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > I chose to mention that example because I happen to share at least an
aspect
> > of the opinion which leads to a desire for something other than a
> > FORMAT-style solution, namely the feeling that encoding formatting
> > information in raw, unstructured strings isn't necessarily the best
> > solution, or at least shouldn't be the only solution.
>
> I think I've just worked out why I don't consider this terrifically
> important
I don't either, I consider that it could be a "nice to have".
> and it's simply that if anyone wants to redesign FORMAT he
> could do it himself in portable ANSI code - after choosing a new name,
> obviously. There is no need to produce a new Lisp to do this
Sure, and I wasn't suggesting otherwise. But part of what I was suggesting
is that there's enough similarity between Lisps, including Scheme, that
specs for all sorts of features could be adhered to across Lisp varieties
(to avoid the "d" word). The feature that I chose as an example had just
been mentioned in this thread.
> nor even to go back to ANSI with a proposal and the aim of
> making the vendors do it.
In that respect, something like Scheme's SRFI process might not be a bad
idea. SRFI's aren't compulsory for Scheme implementations but they
nevertheless standardize optional features, which is useful.
> That being so, then as the apparent status is that nobody has
> bothered, what does that say about the perceived importance of such a
> redesign?
It doesn't matter. I picked the example because someone was discussing it
in this very thread, and it's something I'm interested in myself.
Tangentially, to motivate my own interest: in doing database-driven systems,
often output formatting is generated from a data specification, and building
a format string, not to mention manipulating it later, is less natural than
it might be if s-exps were used. When the output is in the form of web
pages, I mostly rely on an s-exp-based XML/HTML format, and I find that
works very well, for the reasons I've just described. I've similarly found
that the s-exp based regular expressions in Scsh can be very useful. My
reasoning is that something similar could apply to formatted output of the
kind FORMAT produces.
> If we're going to talk about formatted output in the context of CL or
> language-in-the-same-space-as-CL, I don't think it's unreasonable to
> impose a barrier to entry on discussion of "working prototype".
That doesn't make much sense to me. If no-one could discuss something
without first producing a working prototype, nothing collaborative would
ever get done.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> I chose to mention that example because I happen to share at least an aspect
> of the opinion which leads to a desire for something other than a
> FORMAT-style solution, namely the feeling that encoding formatting
> information in raw, unstructured strings isn't necessarily the best
> solution, or at least shouldn't be the only solution.
That is, you would write something like:
(fformat 'string
( "A decimal: " (:decimal 3 #\0)
", a float: " (:float 12 2)
(:newline 3)
"Something: " (:aestetic 30)
" or this: " (:standard 20) :newline :aestetic)
42 123.45 "Stuff" '(a b c) :STUFF)
rather than:
(format nil
"A decimal: ~3,'D, a float: ~12,2F~3%Something: ~30A or this: ~20S~%~A"
42 123.45 "Stuff" '(a b c) :STUFF)
Why not, but I'm not sure to see the benefit.
Note that in Common-Lisp, with FORMAT, using an unstructured string is
NOT the only solution: you can use a control function instead, or you
can still use a sequence of calls to print, prin1, princ, etc.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
From: Douglas Philips
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F4F5EE4.1000906@mac.com>
Pascal Bourguignon wrote:
> That is, you would write something like:
>
> (fformat 'string
> ( "A decimal: " (:decimal 3 #\0)
> ", a float: " (:float 12 2)
> (:newline 3)
> "Something: " (:aestetic 30)
> " or this: " (:standard 20) :newline :aestetic)
> 42 123.45 "Stuff" '(a b c) :STUFF)
>
> rather than:
>
> (format nil
> "A decimal: ~3,'D, a float: ~12,2F~3%Something: ~30A or this: ~20S~%~A"
> 42 123.45 "Stuff" '(a b c) :STUFF)
>
> Why not, but I'm not sure to see the benefit.
I don't see the benefit of intermixing the constant parts of the
formating with the variable part. Without marrying it for life, I'd be
more inclined to do something like:
(fformat
(stream-thingy-expr-here)
"A decimal ~1, a float: ~2
Something: ~4 or this: ~5
~6"
(fmt-decimal 42)
(fmt-float 123.45)
(optional-thingy)
(fmt-aesthetic "Stuff")
(fmt-for-read '(a b c))
(fmt-aesthetic :STUFF))
Except for one-time quicky debugging (which I use my own DUMP functions
for, so this is doubly hypothetical), such constructs (i.e. any
formatted output) would be:
(defun emit-foo-msg 42 123.45 (optional-thingy) "Stuff" '(a b c) :STUFF)
(with enough parameters, I might be tempted to use keywords but that is
an orthogonal issue.)
OK, so, to explain/justify parts of my non-answer:
What's with the ~1 ~2 thing?
I've done enough work with translating programs to know that the
English-centric idea of "plug'n'play" with languages doesn't work well
in other languages. The message string could very well come from a
catalog and the translators may need to radically reorder the message.
The parameters being substituted may even need to be reworked, but at
least the order of the parameters to the output-generating-function
should NOT have to change just because their order of substitution does.
Perhaps a "fmt-currency" "fmt-date" set of functions would make sense.
But the point I'm getting at here is that FORMAT really does two things:
Puts together templates of constant data with variable parts
and
Turns non-string data into strings
What's with the embedded newlines?
Protest against the ~<newline> BS that looks like it just should have
been a part of how strings in general work, not just "FORMAT" strings.
If it has worked well in FORMAT for 10+ years, put it into string
"constants" everywhere. If not, deprecate and remove it. Grrr. (Again,
my annoyance is with the spec language, not the people and the
sociopolitical realities)
What's with the (fmt-...) functions?
I didn't want to get distracted by issues about the (potential
non-)suitability of existing "princ/prin1/..." functions here.
> Note that in Common-Lisp, with FORMAT, using an unstructured string is
> NOT the only solution: you can use a control function instead, or you
> can still use a sequence of calls to print, prin1, princ, etc.
Precisely!
I don't dispute the compactness of the FORMAT strings. And for simple
formating they can be relatively transparent (I have a hard time judging
this, since they are very similar in many ways to C's printf strings and
I've used those for so long that I can't really say much more than that
they are relatively transparent to me).
<D\'gou
From: Joe Marshall
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <smnkbh38.fsf@ccs.neu.edu>
Douglas Philips <····@mac.com> writes:
> I don't see the benefit of intermixing the constant parts of the
> formating with the variable part. Without marrying it for life, I'd be
> more inclined to do something like:
> (fformat
> (stream-thingy-expr-here)
> "A decimal ~1, a float: ~2
> Something: ~4 or this: ~5
> ~6"
> (fmt-decimal 42)
> (fmt-float 123.45)
> (optional-thingy)
> (fmt-aesthetic "Stuff")
> (fmt-for-read '(a b c))
> (fmt-aesthetic :STUFF))
>
(in-package "CL-USER")
(defconstant +xformat+ ··@··@?~}")
(defconstant +fmt-aesthetic+ "~a")
(defconstant +fmt-decimal+ "~d")
(defconstant +fmt-float+ "~e")
(defconstant +fmt-newline+ "~%")
(defun testit ()
(format t +xformat+
"How about a decimal: " +fmt-decimal+ 42
", or a float : " +fmt-float+ 123.45
+fmt-newline+
+fmt-aesthetic+ :stuff))
From: Douglas Philips
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F4FA5FB.3000106@mac.com>
Joe Marshall wrote:
> (in-package "CL-USER")
>
> (defconstant +xformat+ ··@··@?~}")
>
> (defconstant +fmt-aesthetic+ "~a")
> (defconstant +fmt-decimal+ "~d")
> (defconstant +fmt-float+ "~e")
> (defconstant +fmt-newline+ "~%")
>
> (defun testit ()
> (format t +xformat+
> "How about a decimal: " +fmt-decimal+ 42
> ", or a float : " +fmt-float+ 123.45
> +fmt-newline+
> +fmt-aesthetic+ :stuff))
I wondered how long it would take for something like that to surface. ;-)
Being that any alternative to FORMAT would be of equivalent power, I'd
be surprised if such a mapping weren't possible.
Its a question of what are the cleaner and more resuable building
blocks, for example, lets take the complexity up a notch:
~F takes 5 arguments and an optional ·@'. How do I write code that will
take a Fixed-Format Floating-Point specification and look at, tweak it,
and return a new one? I have to STRING PARSE it. And the character
designators in that string are not the 'standard' Lisp character syntax,
they're just single quoted. Plus I have no hooks into the FORMAT engine
to do any of this parsing and recreating of a Fixed-Format
Floating-Point control-string, I have to duplicate all of that myself.
Why? The spec is quite clear on exactly what that can look like.
Oh wait, I could just use the same primitive that FORMAT uses, except
well, that's not portable, and maybe not even exposed by any particular
implementation (non-portable) anyways.
But I shouldn't be hacking strings when I have wonderful S-Exprs and
billions of tools that work on S-Exprs already.
Having a string encoding is terse and powerful.
Having a string encoding be the only way to communicate with the FORMAT
engine is fragile and painful. Its even more painful than the
magic/special syntax of LOOP, at least that you can look at with READ.
<D\'gou
Oops! Douglas Philips <····@mac.com> was seen spray-painting on a wall:
> But I shouldn't be hacking strings when I have wonderful S-Exprs and
> billions of tools that work on S-Exprs already.
Yes, that's the problem with FORMAT, as it stands.
> Having a string encoding is terse and powerful.
> Having a string encoding be the only way to communicate with the
> FORMAT engine is fragile and painful. Its even more painful than the
> magic/special syntax of LOOP, at least that you can look at with READ.
LOOP is somewhat "magic," but at least separates things out and gives
readable names to all of the components.
FORMAT is terse and powerful nearly in the TECO sense, which is
unfortunate. Part of me wants to understand it better, as there are
some useful bits. Part of me would rather not, because I have only so
much room for "cryptic things," and there is no doubt but that it is
pretty cryptic. My understanding of it remains that of a novice, as a
result...
--
let name="cbbrowne" and tld="ntlug.org" in name ^ ·@" ^ tld;;
http://www3.sympatico.ca/cbbrowne/oses.html
Chad has brought us a brilliant new twist: "Nobody has ever been a bad
parent by buying Microsoft."
-- David Steinberg <········@interchange.ubc.ca>
Nils Kassube <····@kassube.de> writes:
> Michael Livshin <······@cmm.kakpryg.net> writes:
>
>> but that's exactly analogous to the "scripting language" community
>> being deeply fragmented: Perl, Python, sh & Ruby are all scripting
>
> The fragmentation matters because the Perl or Python communities alone
> are larger than the Lisp family languages together. Let's say you want
> to write a cross-platform GUI application: you can choose between
> multiple free frameworks (with native widgets/without, etc) with lots
> of documentation as a Python user. Or you want to build a web
> application: choose between multiple good, more less well documented
> frameworks (e.g. Zope, Twisted, Webware) each supported by a
> relatively large community.
I'm confused (but then, I'm easily confused). how exactly this
problem (of there not being enough good libraries to choose from) is
going to be solved by some people agreeing to consider Scheme a Lisp?
are you perhaps thinking that, as a result of this, hordes of Scheme
folks will start writing lots of CL libraries (or vice versa)?
--
For those who like this sort of thing, this is the sort of thing they like.
-- fortune
Tuang wrote:
> I've already begun, and I like both CL and Scheme so much that I'm
> curious to know more about what's going on in the Lisp world today. I
> pay attention to new developments and trends in other languages I work
> with, and now that I'm finding Lisp so interesting, I'm just doing the
> same with Lisp. It's a much smaller community than the big, popular
> languages (Java, C++, etc.) and more fragmented than most of the small
> languages (Python, Ruby, etc., presumably because of Lisp's age), so
> it makes it a little harder to find some types of info.
I've been working on a new (not Common) Lisp implementation too,
but before that's taken as evidence of further fragmentation, I do
occasionally join other (Common) Lispers in a pub for a pint or
two every now and then. There it's been called "a Lisp-like
language" by one of them, which I suppose must apply to Arc as well.
There's been very little interest (the first release was in February)
but that doesn't worry me, as it's not yet stable enough for
widespread release.
I needed it for another project which I've alluded to here in
the past.
--
:ugah179 (home page: http://web.onetel.com/~hibou/)
"I'm outta here. Python people are much nicer."
-- Erik Naggum (out of context)
From: Kenny Tilton
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F5A5962.7050706@nyc.rr.com>
Donald Fisk wrote:
> I've been working on a new (not Common) Lisp implementation too,
OK, it'll be easier this way: Anybody /not/ working on a new LispLite
please raise your hand.
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
From: Joe Marshall
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <llsznw0h.fsf@ccs.neu.edu>
Kenny Tilton <·······@nyc.rr.com> writes:
> Donald Fisk wrote:
>> I've been working on a new (not Common) Lisp implementation too,
>
> OK, it'll be easier this way: Anybody /not/ working on a new LispLite
> please raise your hand.
>
I'm not, but I might if I could make time for it....
Kenny Tilton <·······@nyc.rr.com> writes:
> Donald Fisk wrote:
> > I've been working on a new (not Common) Lisp implementation too,
>
> OK, it'll be easier this way: Anybody /not/ working on a new LispLite
> please raise your hand.
>
> :)
(Checks calendar, raises hand) Not anymore. It was actually more of a
LispHeavy anyway...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On 08 Sep 2003 14:49:10 -0700, ···@firestorm.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > OK, it'll be easier this way: Anybody /not/ working on a new
> > LispLite please raise your hand.
>
> (Checks calendar, raises hand) Not anymore. It was actually more of
> a LispHeavy anyway...
What? Is it finished or did you cancel it?
Edi.
Edi Weitz <···@agharta.de> writes:
> On 08 Sep 2003 14:49:10 -0700, ···@firestorm.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > > OK, it'll be easier this way: Anybody /not/ working on a new
> > > LispLite please raise your hand.
> >
> > (Checks calendar, raises hand) Not anymore. It was actually more of
> > a LispHeavy anyway...
>
> What? Is it finished or did you cancel it?
The latter. Actually, the project it was supporting is no more, and
there was too much work left to do before it was usable as a general
purpose CL.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Kenny Tilton
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F5D32AF.7050305@nyc.rr.com>
Thomas F. Burdick wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Donald Fisk wrote:
>>
>>>I've been working on a new (not Common) Lisp implementation too,
>>
>>OK, it'll be easier this way: Anybody /not/ working on a new LispLite
>>please raise your hand.
>>
>>:)
>
>
> (Checks calendar, raises hand) Not anymore. It was actually more of a
> LispHeavy anyway...
>
We are so desperate for nots that we'll accept both your not anymore and
Joe's not yet. But we're still trailing.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
On Sat, 06 Sep 2003 22:03:43 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>OK, it'll be easier this way: Anybody /not/ working on a new LispLite
>please raise your hand.
*raises hand, then hesitates most of the way up* I am shooting the
bull about what a new Lisp-like language should contain if the market
for such still existed, I'm just not actually going ahead and
implementing it :)
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
From: Ray Dillinger
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F6E0EFD.20D41F3C@sonic.net>
Russell Wallace wrote:
>
> On Sat, 06 Sep 2003 22:03:43 GMT, Kenny Tilton <·······@nyc.rr.com>
> wrote:
>
> >OK, it'll be easier this way: Anybody /not/ working on a new LispLite
> >please raise your hand.
>
> *raises hand, then hesitates most of the way up* I am shooting the
> bull about what a new Lisp-like language should contain if the market
> for such still existed, I'm just not actually going ahead and
> implementing it :)
Similar. I got sidetracked onto different projects, but it's still
on my hard drive waiting for me to get interested in it again.
My aim was (and sorta still is, though not actively now) a LISPy
language, mostly similar in semantics to Scheme. Basically, I
wanted a small language with very clean semantics, capable of a
very small implementation but also capable of having libraries
that do arbitrary, unanticipated, hardware things be portable
across multiple implementations. Finally, I wanted it capable
of the kind of introspection and dynamism and macros that LISPs
allow.
I would add three new lambda forms: one for defining and
handling exceptions a lot more gracefully, one primitive for
defining new routines using bytecode directly, and a subprimitive
for defining routines using raw machine code (of course safety
is out the window when you do this, but programs that do not
use the machine-code interface could be run in kernel memory
without fear, and programs using functions defined in trusted
libraries using the machine-code interface could be run in
kernel memory depending on their libraries' trust levels. I
hate sandbox languages where you can't do something because
the implementor didn't think of it. Actually "bytecodes" may
be a misnomer. I think there'd need to be more than 256 of
them.
My "vision" is that the bytecodes would be defined using machine
code, so targeting for a new machine basically involves defining
a new bytecode set as a bunch of little machine-language vectors
that do specific small language-level tasks and then building the
compiler using the new bytecode set. (of course, you couldn't use
existing libraries that relied on the machine-code interface,
but you could use existing libraries that rely on the bytecode
interface). But you could also define routines using machine
code directly if you need something like direct video card access
or a binary interface to a network buffer which your bytecodes don't
do.
I also want an "uneval" that gets the list structure of a routine
back. Of course it might be implicit in list accessors that when
you try to use car or cdr on a routine it automatically recovers
the list structure before proceeding, as done in Common Lisp, so
there might be no visible uneval - but semantically, I like having
an explicit "uneval" and treating the returned list structure as
a function result of a function to which the routine was passed
as an argument, rather than treating the returned list as the
routine itself. This is mainly because it removes a lot of hair
about whether, how and when to change the routine when someone uses
a mutator on the list structure by just saying, we have a semantics
completely consistent with just not changing it at all. If you
want to change a routine during runtime, you can mutate that routine
(not on some tiny subchunk down in its list structure) directly.
This would be the same list (starting with lambda) that could be
used to define the function - including, in the case of primitives
or machine-code or bytecode-defined functions, lists like
(lambda args
"doc string"
(*machinecode* #(88 22 110 210 32 ... )))
or
(lambda (arg1 arg2)
"doc string"
(*bytecode* #(88 22 110 210 32 ...)))
I want to pay particular attention to getting numbers *right*.
Sigh. My idea of *right*, however, is at variance with the idea
of many people. SISC (one of the scheme implementations) gets this
pretty close to right with their bigints and arbitrary-precision
floats, but they don't have fixnums and if you start using complex
numbers they tend to mess up on the branch-cuts of the trig
functions.
Finally I want to nail down library interfaces. C did a good job
of this (though not perfect), and CL did a good job of this (which
seems better but I have to think about it); Zetalisp did an okay
job but surprisingly brittle in some ways. But the fundamental
binary format of linkable languages on modern machines (ELF/COFF/etc)
doesn't really do everything that ought to be done for LISPy
languages that may do macroexpansion of code in one file based
on macro definitions stored in another, and access (and modify!)
their code as data.
in Scheme the standard is silent about library interfaces, and
as a result trying to write libraries that are portable between
scheme implementations is like trying to nail jelly to a tree.
There are a few who've managed it to some extent, like SLIB;
but it's neither natural nor easy.
Bear
On Sat, 06 Sep 2003 22:03:43 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>
>
>Donald Fisk wrote:
>> I've been working on a new (not Common) Lisp implementation too,
>
>OK, it'll be easier this way: Anybody /not/ working on a new LispLite
>please raise your hand.
>
>:)
I'm not...yet.
I wouldn't mind working on a Lisp implementation. Any of you that are
working on it, need some gruntwork done? I'm still pretty new to
Lisp, but I would love to get involved with a project. Kenny, need
any help on cells? What better way to learn Lisp, than writing it!!
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
In article <··································@4ax.com>, ·······@yahoo.com
wrote:
> On Sat, 06 Sep 2003 22:03:43 GMT, Kenny Tilton <·······@nyc.rr.com>
> wrote:
>
> >
> >
> >Donald Fisk wrote:
> >> I've been working on a new (not Common) Lisp implementation too,
> >
> >OK, it'll be easier this way: Anybody /not/ working on a new LispLite
> >please raise your hand.
> >
> >:)
>
> I'm not...yet.
>
> I wouldn't mind working on a Lisp implementation. Any of you that are
> working on it, need some gruntwork done? I'm still pretty new to
> Lisp, but I would love to get involved with a project. Kenny, need
> any help on cells? What better way to learn Lisp, than writing it!!
Take a look at http://www.flownet.com/gat/ciel.pdf and see if anything you
see there interests you.
E.
Doug Tolton <·······@yahoo.com> writes:
> What better way to learn Lisp, than writing it!!
Is that a question?
If it were, I'd answer: writing an application.
It is easily possible to know how to implement a complete language,
yet not how to use it well at all.
Using a language is about composing its parts toward a useful end.
Implementing a language is about fulfilling documented specifications.
I'm sure there are people who can competently make art supplies but
cannot paint.
Doug Tolton wrote:
> What better way to learn Lisp, than writing it!!
Writing a test suite for it. :)
Paul
From: Kenny Tilton
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F5F9B7F.1010203@nyc.rr.com>
Doug Tolton wrote:
> On Sat, 06 Sep 2003 22:03:43 GMT, Kenny Tilton <·······@nyc.rr.com>
> wrote:
>
>
>>
>>Donald Fisk wrote:
>>
>>>I've been working on a new (not Common) Lisp implementation too,
>>
>>OK, it'll be easier this way: Anybody /not/ working on a new LispLite
>>please raise your hand.
>>
>>:)
>
>
> I'm not...yet.
>
> I wouldn't mind working on a Lisp implementation. Any of you that are
> working on it, need some gruntwork done? I'm still pretty new to
> Lisp, but I would love to get involved with a project. Kenny, need
> any help on cells? What better way to learn Lisp, than writing it!!
Cells and RoboCells are now both SourceForge projects, MIT-style
license. I'll probably do Cello (the GUI built atop Cells) under the
Cells project. Right now only the RoboCells project has source and doc,
but that includes the latest/greatest in Cells, including a tiny bit of doc.
Cells are pretty much done in the sense of mature, tho they will be
expanding all the time. I got part way thru implementing them for
structures to get a lighter-weight implementation, and I might create a
lazy option so I do not have to talk anymore to the ninnys who think
that is a good idea. :)
If you have time, watch for the next release of RoboCells and jump on
that. But if you are still learning Lisp it will be tough to contribute
much before the conference in October.
As for Cello, now there we can talk. That needs an OpenGL wiz, or if I
decide to switch to Gtk or Tk for window management and text/graphic
support, someone strong there. And any of these projects could use
someone to take a new release and validate it under any of the supported
combos of Cl implementation and OS. I work on ACL under win32, so
someone strong on Linux can be big help supporting that side of things.
thx for the interest. Good luck with whatever project you settle on. And
watch for the "Lisp With Kenny Far Away!" distance learning series, to
begin after ILC2003.
btw, the line-up for this conference is tremendous. when I heard the
list of luminaries who will be talking, including John McCarthy Himself,
I started getting a serious case of performance anxiety. i think we will
point to ILC2003 and say that is when CL turned the corner and started
its run for the gold. also, autumn is a beautiful time to be in NYC.
y'all should join us, :)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"This is my simple religion.
There is no need for temples;
no need for complicated philosophy.
Our own brain, our own heart is our temple;
the philosophy is kindness."
-- Tenzin Gyatso, the Dalai Lama
Doug Tolton <·······@yahoo.com> writes:
> I wouldn't mind working on a Lisp implementation. Any of you that are
> working on it, need some gruntwork done? I'm still pretty new to
> Lisp, but I would love to get involved with a project. Kenny, need
You might consider contributing to SBCL.
Paolo
--
Paolo Amoroso <·······@mclink.it>
Doug Tolton <·······@yahoo.com> writes:
> On Sat, 06 Sep 2003 22:03:43 GMT, Kenny Tilton <·······@nyc.rr.com>
> wrote:
>>OK, it'll be easier this way: Anybody /not/ working on a new LispLite
>>please raise your hand.
:-)
> I'm not...yet.
Nor I. I'm working on an existing implementation of an existing
standardized language. That way, I get all the benefit of the work
that the ANSI committee, and the implementors before them, put into
design, _and_ I don't have to care about implementing the cruftier
bits (whichever bits you think they are[*]) because it's already
been _done_.
> I wouldn't mind working on a Lisp implementation. Any of you that are
> working on it, need some gruntwork done? I'm still pretty new to
> Lisp, but I would love to get involved with a project. Kenny, need
> any help on cells? What better way to learn Lisp, than writing it!!
There's all kinds of thing that could be done in SBCL: bug fixes,
thread auditing, new contrib modules, enhancements to current contrib
modules (there's always work to be done on SB-POSIX), new external
asdf-installable (i.e. CCLAN) libraries. Or you could download CLX
and McCLIM and try your hand at some CLIM programming, or check out
Portable Hemlock and write some neat stuff in a real CL Emacs-like
editor; help free us from ILISP. Or ...
Are you on the clump mailing list? Lots of stuff happening there.
Seriously, this is a good time to hack Lisp. And you don't have to
hack the implementation directly either; there's lots of userland
stuff to do.
-dan
[*] Personally I'd like a pathname abstraction that makes sense on
arbitrary unix filenames, and an environment chapter defined tightly
enough that you could actually do anything with the answers beyond
reporting them to the user. But, hey. No big deal.
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Kenny Tilton
Subject: We need a flamewar: SBCL vs CMUCL? [was: Re: What's happening in the Lisp world today?]
Date:
Message-ID: <3F60AB6A.3010407@nyc.rr.com>
Daniel Barlow wrote:
> There's all kinds of thing that could be done in SBCL:
Just kidding about the flamewar, I am just wondering if the whole LX
world has shifted to SBCL without telling me. I have just started
chipping away at the whole LX/CMUCL/EMACS/ILISP etc etc etc learning
curve and will swap in SBCL for CMUCL if the former is surging ahead to
stay. I know active development is going on in both, including nice PCL
speed-up for CMUCL and a couple of hacks to permit callbacks to Lisp from C.
So...is SBCL ready for prime time? Can it do callbacks from C? Is CMUCL
fading in popularity if not new development? Do some people use both?
Email feedback is fine if your asbestos is at the cleaners. :)
And in case that does not succeed in starting a flamewar, why the
divided effort? Why not CCCL (Common CMU Common Lisp)? Fundamental
differences, I presume, so this should really get things going.
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"This is my simple religion.
There is no need for temples;
no need for complicated philosophy.
Our own brain, our own heart is our temple;
the philosophy is kindness."
-- Tenzin Gyatso, the Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> So...is SBCL ready for prime time? Can it do callbacks from C? Is
> CMUCL fading in popularity if not new development? Do some people use
> both? Email feedback is fine if your asbestos is at the cleaners. :)
Define "prime time" ...
I'm going to tackle this by assuming that you consider CMUCL ready for
prime time, so a comparison with CMUCL is useful. If you don't, it's
not, and you need to ask some better-directed questions.
- Most of the library code is pretty similar between the two
implementations except for the bits that don't exist in SBCL. Most
of this (sockets, CLX, Posix access, date parsing etc) is available
as add-on libraries; it might just take a little longer to assemble
- The compiler is still slower (though substantially faster in CVS
than 0.8.3 was; we're catching up).
- Threads in SBCL are new and largely untested - they're native
threads using the kernel scheduler, whereas CMUCL threads are
scheduled by Lisp. There are advantages and disadvantages to each
approach
- I _think_ SBCL is ahead on the number of currently working
platforms. We're ahead on fashionable platforms, at least - we have
PPC/MacOS X and they don't, ner ner ner
- ILISP probably gets more easily confused with SBCL (one of the
reasons I want people to hack on Portable Hemlock ;-) especially
where threads are concerned. I'll probably investigate this one day
when I get sufficiently annoyed by it: I suspect ILISP may be trying
to send an interrupt to the wrong process id or something.
- CMUCL (the CVS version of) has a generational GC on SPARC and X86,
whereas SBCL only has it on x86. Our OS X guys are planning how to
port it to PPC, though
> And in case that does not succeed in starting a flamewar, why the
> divided effort? Why not CCCL (Common CMU Common Lisp)? Fundamental
> differences, I presume, so this should really get things going.
Musical differences, yes. A little competition is good for everyone.
Plus which, the name CCCL is only going to get confused with MCL
(ex-Coral Common Lisp) or Corman. So that's no good.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
> > And in case that does not succeed in starting a flamewar, why the
> > divided effort? Why not CCCL (Common CMU Common Lisp)? Fundamental
> > differences, I presume, so this should really get things going.
>
> Plus which, the name CCCL is only going to get confused with MCL
> (ex-Coral Common Lisp) or Corman. So that's no good.
How about SMCL -- Steel Mellon Common Lisp ;-)
Marcus Pearce <·····@soi.city.ac.uk> writes:
> > > And in case that does not succeed in starting a flamewar, why the
> > > divided effort? Why not CCCL (Common CMU Common Lisp)? Fundamental
> > > differences, I presume, so this should really get things going.
> >
> > Plus which, the name CCCL is only going to get confused with MCL
> > (ex-Coral Common Lisp) or Corman. So that's no good.
>
> How about SMCL -- Steel Mellon Common Lisp ;-)
Let me start off by saying that your lousiness is matched only by your
narrow-mindedness[1] and that you're always totally wrong[1].
I hope that will prove sufficient in the flame department.
As far as CMUCL vs. SBCL goes, I should point out that the original
fork, while motivated by strong but misguided opinions, was relatively
free from acrimony. After all, people who care more about getting
things right than running really fast, well, you don't want such
people touching your source base, right? You'd much rather they went
off and played by themselves.
Since they were Lisp hackers, they knew how to hack, after a fashion,
and so CMUCL got the best of both worlds. We don't have pedantic
issues slowing down CMUCL and we can steal the bug fixes they make.
One thing I've seen is a tendency for the CMUCL developers to spend
perhaps a little too much time schmoozing with the SBCL people, to the
point where they have even started taking Paul Dietz seriously and
treating ansi incompatibilities in CMUCL as bugs and fixing them.
Fortunately I haven't noticed much in the way of major slowdowns in
CMUCL to date.
The only thing that scares me is that SBCL might actually make a
Windows port. That could have serious consequences.
[1] M-x flame
--
Fred Gilham ······@csl.sri.com
The spam folder --- you will never find a more wretched hive of scum
and villainy. We must be cautious.
Fred Gilham wrote:
> Let me start off by saying that your lousiness is matched only by your
> narrow-mindedness[1] and that you're always totally wrong[1].
that's just nitpicking!
> Fortunately I haven't noticed much in the way of major slowdowns in
> CMUCL to date.
The million dollar question is, did /SBCL/ turn out slower?
>
> The only thing that scares me is that SBCL might actually make a
> Windows port. That could have serious consequences.
That would be cool. Then I could create an IDE (possibly within Emacs
ala ilisp) based on Cells/Cello and we'd have the moral equivalent of a
free, universal implementation for newbies to jump on, as exists for
Python and Perl. Not that Python has a good IDE. (Perl I do not know
about in this (or any) regard.)
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"I'm non-violent, but if a hawk comes down when I'm feeding
my birds, I lose my temper and get my air rifle."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> Fred Gilham wrote:
>> Fortunately I haven't noticed much in the way of major slowdowns in
>> CMUCL to date.
>
> The million dollar question is, did /SBCL/ turn out slower?
Currently, in CVS HEAD, the compiler is roughly 10% or so slower; the
compiled output is slightly different; it can be noticeably faster, or
somewhat slower. "Your application is the only benchmark".
Can I have a million dollars, please? After all, I'm a college
student, and it doesn't make economic sense for me to work on SBCL
without substantial remuneration...
>> The only thing that scares me is that SBCL might actually make a
>> Windows port. That could have serious consequences.
>
> That would be cool. Then I could create an IDE (possibly within Emacs
> ala ilisp) based on Cells/Cello and we'd have the moral equivalent of
> a free, universal implementation for newbies to jump on, as exists for
> Python and Perl.
A Windows port will happen not by talking about it, but by having
people who know how to program for Windows doing it.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> wrote:
>>> The only thing that scares me is that SBCL might actually make a
>>> Windows port. That could have serious consequences.
>>
>> That would be cool. Then I could create an IDE (possibly within
>> Emacs ala ilisp) based on Cells/Cello and we'd have the moral
>> equivalent of a free, universal implementation for newbies to jump
>> on, as exists for Python and Perl.
>
> A Windows port will happen not by talking about it, but by having
> people who know how to program for Windows doing it.
Thanks, that's very reassuring. That means I don't have to put out a
contract on Bill Newman or Dan Barlow. Or you, for that matter.
Hmn, now that I think about it I haven't seen any postings or messages
from Bill Newman in a long time. Does he know how to program for
Windows?
--
Fred Gilham ······@csl.sri.com
[My tutors] got bored sooner than I, and laid down a general rule
that all statements about languages had to be in a higher level
language. I thereupon asked in what level of language that rule was
formulated. I got a very bad report. -- J. R. Lucas
Kenny Tilton <·······@nyc.rr.com> writes:
> ...
> Then I could create an IDE (possibly within Emacs
> ala ilisp) based on Cells/Cello
> ...
By the way, is it possible (or have you even tried) to port Cells to
elisp?
Marco Gidde wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>...
>> Then I could create an IDE (possibly within Emacs
>>ala ilisp) based on Cells/Cello
>>...
>
>
>
> By the way, is it possible (or have you even tried) to port Cells to
> elisp?
Tried? No, as a matter of fact, your query impelled me to look for the
first time at the elisp manual. I see arrays, I see lambda, I see
macros... it can be done! I am guessing, however, that it would be a
bunch of work, so someone would really have to want it. I would gladly
offer copious assistance and guidance to anyone attempting such a thing.
kenny
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"I'm non-violent, but if a hawk comes down when I'm feeding
my birds, I lose my temper and get my air rifle."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> Marco Gidde wrote:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >
> >>...
> >> Then I could create an IDE (possibly within Emacs
> >>ala ilisp) based on Cells/Cello
> >>...
> >
> >
> >
> > By the way, is it possible (or have you even tried) to port Cells to
> > elisp?
>
> Tried? No, as a matter of fact, your query impelled me to look for the
> first time at the elisp manual. I see arrays, I see lambda, I see
> macros... it can be done! I am guessing, however, that it would be a
> bunch of work, so someone would really have to want it. I would gladly
> offer copious assistance and guidance to anyone attempting such a thing.
Just a warning: it's lambda, but not as we know it. No closures
though you can fake them, but to do so, you have to enumerate what you
want to be able to close over; hint -- you do this by using
"lexical-let". To remedy this, at various times I've written code
walkers for elisp, which is thankfully a lot easier than for CL...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Alphabetic names are so ordinary, how about
~|CL
You can be turning over a "new leaf".
This has the added "advantage" of being
a really annoying file name to deal with
on unix.
Marcus Pearce <·····@soi.city.ac.uk> writes:
> > > And in case that does not succeed in starting a flamewar, why the
> > > divided effort? Why not CCCL (Common CMU Common Lisp)? Fundamental
> > > differences, I presume, so this should really get things going.
> >
> > Plus which, the name CCCL is only going to get confused with MCL
> > (ex-Coral Common Lisp) or Corman. So that's no good.
>
> How about SMCL -- Steel Mellon Common Lisp ;-)
You're just being hard-headed.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> Marcus Pearce <·····@soi.city.ac.uk> writes:
>
>
>>>>And in case that does not succeed in starting a flamewar, why the
>>>>divided effort? Why not CCCL (Common CMU Common Lisp)? Fundamental
>>>>differences, I presume, so this should really get things going.
>>>
>>>Plus which, the name CCCL is only going to get confused with MCL
>>>(ex-Coral Common Lisp) or Corman. So that's no good.
>>
>>How about SMCL -- Steel Mellon Common Lisp ;-)
>
>
> You're just being hard-headed.
>
Those are fighting words. You may end up tasting his metal. if he tests
your mettle. I hope it is ripe for the tasting. Someone stop me....
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"I'm non-violent, but if a hawk comes down when I'm feeding
my birds, I lose my temper and get my air rifle."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> Thomas F. Burdick wrote:
> > Marcus Pearce <·····@soi.city.ac.uk> writes:
> >
> >
> >>>>And in case that does not succeed in starting a flamewar, why the
> >>>>divided effort? Why not CCCL (Common CMU Common Lisp)? Fundamental
> >>>>differences, I presume, so this should really get things going.
> >>>
> >>>Plus which, the name CCCL is only going to get confused with MCL
> >>>(ex-Coral Common Lisp) or Corman. So that's no good.
> >>
> >>How about SMCL -- Steel Mellon Common Lisp ;-)
> >
> >
> > You're just being hard-headed.
> >
>
> Those are fighting words. You may end up tasting his metal. if he tests
> your mettle. I hope it is ripe for the tasting. Someone stop me....
The thing about this group is that when you start punning, you can
always bank on someone trying to steel your thunder.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Marcus Pearce <·····@soi.city.ac.uk> writes:
> > > And in case that does not succeed in starting a flamewar, why the
> > > divided effort? Why not CCCL (Common CMU Common Lisp)? Fundamental
> > > differences, I presume, so this should really get things going.
> >
> > Plus which, the name CCCL is only going to get confused with MCL
> > (ex-Coral Common Lisp) or Corman. So that's no good.
>
> How about SMCL -- Steel Mellon Common Lisp ;-)
I think that might prove a bit hard to swallow.
--
Gareth McCaughan
.sig under construc
From: Stefan Scholl
Subject: Re: We need a flamewar: SBCL vs CMUCL? [was: Re: What's happening in the Lisp world today?]
Date:
Message-ID: <sy6lb2jeox51.dlg@parsec.no-spoon.de>
Funny thing is: you can edit CMUCL and SBCL with Emacs _and_ with
XEmacs! :-)
Stefan Scholl <······@no-spoon.de> wrote in message news:<················@parsec.no-spoon.de>...
> Funny thing is: you can edit CMUCL and SBCL with Emacs _and_ with
> XEmacs! :-)
Well, CMUCL-18e with XEmacs/ilisp seems to have problems for some
people. (see ilisp mailing list...). I don't know myself, I use
plain gnu emacs+ilisp with CMUCL 18e with no problem.
On Thu, 11 Sep 2003 16:32:27 +0100, Daniel Barlow <···@telent.net>
wrote:
>There's all kinds of thing that could be done in SBCL: bug fixes,
>thread auditing, new contrib modules, enhancements to current contrib
>modules (there's always work to be done on SB-POSIX), new external
>asdf-installable (i.e. CCLAN) libraries. Or you could download CLX
>and McCLIM and try your hand at some CLIM programming, or check out
>Portable Hemlock and write some neat stuff in a real CL Emacs-like
>editor; help free us from ILISP. Or ...
>
>Are you on the clump mailing list? Lots of stuff happening there.
>
>Seriously, this is a good time to hack Lisp. And you don't have to
>hack the implementation directly either; there's lots of userland
>stuff to do.
>
>-dan
I just subscribed to the clump mailing list. It looks like there are
some really good projects to get involved with, I am leaning towards
SBCL, although I wouldn't mind helping with some of the other projects
mentioned. Thank all of you for your suggestions, I am going to start
looking through the code of some of these projects and hopefully get
an idea about where to start.
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
Something to point out. There has been serious progress recently with
Free CLIM. They have a lisp listener that actually seems to work
pretty well and has lisp-listener-like features. It's something I
tried to do on and off in various environments for years without any
real success.
Also, the g-sharp group has put out an alpha (pre-alpha?) version of
their CLIM-based music editor which shows a lot of potential.
As far as my own efforts are concerned, I've been trying to hack CMU
Lisp so it will save executables. I've gotten to the point where it
works reliably under FreeBSD. You can type
(save-lisp "foo" :executable t)
and you wind up with a stand-alone file that you can run, in which the
CMU lisp spaces are elf sections.
I'm still having trouble with stable operation under Linux (which I'm
beginning to believe may be more a result of the current state of the
CMUCL Linux port than my stuff) otherwise I'd have released it for
general consumption already.
I have to concur with others. There's a lot of stuff to do, and not
that many people doing it. The field is wide open. Jump in. Become
a celebrity like Kenny Tilton.
--
Fred Gilham ······@csl.sri.com
A step into the Way has been made by the person who ceases to say,
"God, look how big my problems are!", and instead says, "Problems,
look how big my God is!" -- Jonathan Hayward
From: Kenny Tilton
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F625256.7060901@nyc.rr.com>
Fred Gilham wrote:
> There's a lot of stuff to do, and not
> that many people doing it. The field is wide open. Jump in.
Yeah, it's nuts whining about "no Lisp jobs" if one is not working to
fill in the library gap. Pick something of interest or in your area of
strength and go.
> Become
> a celebrity like Kenny Tilton.
>
I am a simple Lisp programmer.
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"I am a simple Buddhist monk. "
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> > Become
> > a celebrity like Kenny Tilton.
> >
>
> I am a simple Lisp programmer.
>
> --
>
> clinisys, inc
> http://www.tilton-technology.com/
> ---------------------------------------------------------------
> "I am a simple Buddhist monk. "
> -- Tenzin Gyatso, the Fourteenth Dalai Lama
On top of everything else, humble too! :-)
--
Fred Gilham ······@csl.sri.com
The rage of dance and style that swept the country in the late '70s
crumbled from serious backlash as disco freaks seemed to finally wake
up and realize what they were wearing. -- Michael Okwu
From: Kenny Tilton
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F6268CD.9050000@nyc.rr.com>
Fred Gilham wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>> Become
>>>a celebrity like Kenny Tilton.
>>>
>>
>>I am a simple Lisp programmer.
>>
>>--
>>
>> clinisys, inc
>> http://www.tilton-technology.com/
>> ---------------------------------------------------------------
>>"I am a simple Buddhist monk. "
>> -- Tenzin Gyatso, the Fourteenth Dalai Lama
>
>
> On top of everything else, humble too! :-)
>
Oh, gosh, sorry. Just noticed that now!
:)
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"I'm non-violent, but if a hawk comes down when I'm feeding
my birds, I lose my temper and get my air rifle."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Fred Gilham <······@snapdragon.csl.sri.com> writes:
[...]
> I'm still having trouble with stable operation under Linux (which
> I'm beginning to believe may be more a result of the current state
> of the CMUCL Linux port than my stuff) otherwise I'd have released
> it for general consumption already.
[...]
Perhaps post the patches anyways so that other people could perhaps
have a shot at the problem? At the very least it will give the
FreeBSD users the use of the enhancement. :>
"Given enough eyeballs, all bugs are shallow" (Linus's Law) and all
that.
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
David Magda writes:
> Perhaps post the patches anyways so that other people could perhaps
> have a shot at the problem? At the very least it will give the
> FreeBSD users the use of the enhancement. :>
Fred has already posted his standalone application generation patches
for FreeBSD to the CMUCL mailing list.
Paolo
--
Paolo Amoroso <·······@mclink.it>
Paolo Amoroso <·······@mclink.it> writes:
> David Magda writes:
>
> > Perhaps post the patches anyways so that other people could perhaps
> > have a shot at the problem? At the very least it will give the
> > FreeBSD users the use of the enhancement. :>
>
> Fred has already posted his standalone application generation patches
> for FreeBSD to the CMUCL mailing list.
Yes. I've posted them again and again. And again. And I think I'll
soon post them again. :-) They gave me CVS commit access just to get
me to stop annoying them.
BTW, the stuff now works for both FreeBSD and Linux.
The main task left, AFAIAC, is to get rid of the need for linker
scripts, which are REALLY REALLY ugly and seem to require updating for
every change in version. The GNU people came up with this wonderful
mechanism to program the linker but I don't think they thought anyone
would be so foolish as to actually use it.
In the case of Linux you also have to worry about different
distributions having different paths.
--
Fred Gilham ······@csl.sri.com
A common sense interpretation of the facts suggests that a
superintellect has monkeyed with physics, as well as with chemistry
and biology, and that there are no blind forces worth speaking about
in nature. --- Fred Hoyle
From: Greg Menke
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <m3u17fb66w.fsf@europa.pienet>
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> Paolo Amoroso <·······@mclink.it> writes:
>
> The main task left, AFAIAC, is to get rid of the need for linker
> scripts, which are REALLY REALLY ugly and seem to require updating for
> every change in version. The GNU people came up with this wonderful
> mechanism to program the linker but I don't think they thought anyone
> would be so foolish as to actually use it.
Heh heh, you should see what the embedded systems folks do with linker
scripts. I work with one so complicated that its generated by a shell
script working off meta-data. The difficult part is dealing with
changes to gcc- the reference scripts that ship with it contain quite
a lot of cruft that tends to disguise gcc's requirements for section
layout at runtime.
Gregm
Greg Menke writes:
> Heh heh, you should see what the embedded systems folks do with linker
> scripts. I work with one so complicated that its generated by a shell
> script working off meta-data. The difficult part is dealing with
Looks like a good job for Lisp :)
Paolo
--
Paolo Amoroso <·······@mclink.it>
From: Greg Menke
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <m3isnvb00t.fsf@europa.pienet>
Paolo Amoroso <·······@mclink.it> writes:
> Greg Menke writes:
>
> > Heh heh, you should see what the embedded systems folks do with linker
> > scripts. I work with one so complicated that its generated by a shell
> > script working off meta-data. The difficult part is dealing with
>
> Looks like a good job for Lisp :)
I do use Lisp for other things, collecting and interpreting logic
analyzer traces and self-test data. I like clisp because it runs
anywhere, so I can avoid moving data around the network to be
processed on a box with something like Lispworks. OTOH, I use
Lispworks for the same thing because its quite fast and can work
through big datasets much faster than clisp can.
The CL reader is a huge help because I can generate "Lisp-ified" data
and trivially load it- structs & arrays are easy, I don't have to
worry about parsing numbers, and overhead both in cycles and bytes is
minimal. I suppose XML would work too, but sexp's seem fundamentally
simpler to deal with.
Gregm
Also, if it interests you, a lot of development is being done for Scheme
Shell( http://www.scsh.net/ ). It's an open source Unix shell that can do
many fun and wonderful things with scheme. I'd recommend reading this guy's
page http://www.cc.gatech.edu/~shivers/ and contacting him if you have any
sort of interesting.
Charles
"Tuang" <········@hotmail.com> wrote in message
·································@posting.google.com...
> I'm trying to learn Lisp because I'm becoming fascinated with several
> of the ideas it embodies. I'm not referring to Common Lisp or Scheme
> per se, much less any specific implementation, but to the ideas that
> they seem to share (to the limited extent I understand them so far.)
>
> I don't expect that a knowledge of Lisp will improve my career
> prospects, but it may make my life more interesting. In fact, I'm
> already observing that it is, so I'll keep at it to the extent I can.
>
> And I'm not entirely ruling out the possibility of career enhancement,
> so I'm wondering....
>
> What's happening in the Lisp world today?
>
> Are there any new Lisp-family languages being created? I don't mean,
> are any languages retrofitting a few Lisp-like features (most are),
> but are there any "new and improved Lisp" languages being created?
> I've only heard of Paul Graham's Arc, but it appears from the Arc
> website that he abandoned it after "three weeks" (or put it on a back
> burner? went underground? anybody know?) and went off to battle spam.
> Are there any other "new Lisps" in the making?
>
> Is there another Common Lisp standard in the works? Another Scheme
> standard?
>
> Are there any new implementations being *actively* worked on? Yes,
> I've seen the exhaustive lists of links to implementations, but such
> lists studiously avoid making value judgments that might lead me to an
> understanding of what's really going on (or isn't anymore). Something
> that was very promising twenty years ago and is now on life support is
> going to look the same to me as something that is very promising
> *today*, so I'd be very interested in well-informed, opinionated,
> judgmental comments about implementations.
>
> So what is being energetically worked on now? I'm particularly
> interested in open source projects, but not exclusively so.
>
> Any sign that Guy Steele is going to persuade Sun to come out with a
> new Lisp + Java runtime upgrade combination optimized for each other?
> How about an L# from Microsoft to match the F# (ML for .Net) they have
> announced?
>
> And are there any market segments (finance, robotics, etc.) or fields
> where the use of Lisp is increasing significantly? Not the standard
> "Viaweb and Orbitz" examples, but domains in which Lisp is growing.
>
> Anything else that is a significant area of activity in the Lisp world
> today?
>
> Thanks.
whampa <·······@prism.gatech.edu> wrote:
+---------------
| Also, if it interests you, a lot of development is being done for Scheme
| Shell( http://www.scsh.net/ ). It's an open source Unix shell that can do
| many fun and wonderful things with scheme. I'd recommend reading this guy's
| page http://www.cc.gatech.edu/~shivers/ and contacting him if you have any
| sort of interesting.
+---------------
That brings up a question about the CL reader I've been wondering about
for some time, inasmuch as I've occasionally mused about doing something
like the Scheme Shell in CL...
Scsh makes heavy use of [non-hygenic, defmacro-like] macros for syntactic
sugar, especially for what it calls "process forms" (PFs) and "extended
process forms" (EPFs) in which subforms are "implicitly backquoted". That
is, you can use comma and comma-at *without* typing an initial backquote.
A couple of small examples[1] using the RUN macro, one of the main EPFs,
will show you what I mean:
;; If the resource file F exists, load it into X Windows.
(when (probe-file f)
(run (xrdb -merge ,f)))
;; Compile FILE with FLAGS.
(run (cc ,file ,@flags))
;; Delete every file in DIR containing the string "/bin/perl":
(dolist (file (directory dir))
(if (zerop (run (grep -s /bin/perl ,file)))
(delete-file file)))
The problem is that I can see no way in ANSI Common Lisp of defining
the RUN macro such that it would permit this syntax to be acceptable
to the CL reader.[2] Am I missing something obvious? Or is this in fact
a fundamental limitation, such that the closest one could come to the
above would be this?
(when (probe-file f)
(run `(xrdb -merge ,f)))
(run `(cc ,file ,@flags))
O.k., let me restate that -- I should have said: The only way I see to
use exactly Scsh-like syntax would be to define one's own reader macros
for backquote and comma, effectively replacing the built-in ones with
one's own. [Yes, you could, I suppose, do something like temporarily
restore the original definitions when you see a backquote until that
subexpression is read and then pop back to your own, but it would
probably be easier overall to do the whole thing yourself and not try
to mix the styles].
So to repeat: Am I missing something simple/obvious? Or is that the
best one can do?
-Rob
[1] These are mildly edited into CL syntax from the Scsh examples here:
<URL:http://www.scsh.net/docu/scsh-paper/scsh-paper-Z-H-5.html>
[2] In Scheme 48 [the engine underneath Scsh] it's fairly simple, since
backquote, comma, and comma-at are defined as being simple QUOTE-like
abbreviations for a longer S-expression syntax, defined completely in
isolation of each other. That is, in Scheme:
'form ==> (quote form)
`form ==> (quasiquote form)
,form ==> (unquote form)
,@form ==> (unquote-splicing form)
Given these isolated transformations[3], QUASIQUOTE can simply be a
macro that tree-walks its argument, rewriting any S-expr sub-forms
whose CAR is one of QUASIQUOTE/UNQUOTE/UNQUOTE-SPLICING.
In CL, on the other hand, the comma & comma-at are not defined in
isolation, but only in the context of an open backquote; also, unlike
Scheme, no standard list representation of a backquoted expression
is mandated, only that [per CLHS "2.4.6 Backquote"]:
An implementation is free to interpret a backquoted form F1 as
any form F2 that, when evaluated, will produce a result that is
the same under EQUAL as the result implied by the above definition,
provided that the side-effect behavior of the substitute form F2
is also consistent with the description given above.
[3] Note that like CL, the R5RS standard officially only defines UNQUOTE
and UNQUOTE-SPLICING when they appear within a QUASIQUOTE template,
however Scheme 48, MzScheme, and several other implementations are
more lenient in their behavior, e.g., in MzScheme:
> '(run (cc ,file ,@flags))
(run (cc (unquote file) (unquote-splicing flags)))
>
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> O.k., let me restate that -- I should have said: The only way I see to
> use exactly Scsh-like syntax would be to define one's own reader macros
> for backquote and comma, effectively replacing the built-in ones with
> one's own. [Yes, you could, I suppose, do something like temporarily
> restore the original definitions when you see a backquote until that
> subexpression is read and then pop back to your own, but it would
> probably be easier overall to do the whole thing yourself and not try
> to mix the styles].
>
> So to repeat: Am I missing something simple/obvious? Or is that the
> best one can do?
Common Lisp generally uses the same trick as Scheme: replace the comma
and ······@ forms with some sort of unquote and unquote-splicing form.
The only difference being that Scheme defines a canonical name for the
unquoting.
You ought to be able to extract the implementation-specific names
with a macro.
Joe Marshall <···@ccs.neu.edu> wrote in message news:<············@ccs.neu.edu>...
> ····@rpw3.org (Rob Warnock) writes:
>
> > O.k., let me restate that -- I should have said: The only way I see to
> > use exactly Scsh-like syntax would be to define one's own reader macros
> > for backquote and comma, effectively replacing the built-in ones with
> > one's own. [Yes, you could, I suppose, do something like temporarily
> > restore the original definitions when you see a backquote until that
> > subexpression is read and then pop back to your own, but it would
> > probably be easier overall to do the whole thing yourself and not try
> > to mix the styles].
> >
> > So to repeat: Am I missing something simple/obvious? Or is that the
> > best one can do?
>
> Common Lisp generally uses the same trick as Scheme: replace the comma
> and ······@ forms with some sort of unquote and unquote-splicing form.
> The only difference being that Scheme defines a canonical name for the
> unquoting.
>
> You ought to be able to extract the implementation-specific names
> with a macro.
Unfortunately, this isn't true, as I found out empirically by writing
just such a program. There is a great deal of variety in the
representation of backquotes. Some backquote implementations perform
the expansion at read time, so that optimized list construction code
comes right of the reader. The backquote is not transliterated into a
macro language which can be parsed to find the unquote forms. You type
`(a ,@(list b c) d) and the form that pops out the actual reader macro
might be (list 'a b c 'd). You can look for the unquote-splicing
structure in vain; no such thing exists at all.
CLISP had an interesting implementation which is now rewritten from
scratch. Its reader macro produced both a Scheme-like form, and list
construction code. The two forms were positioned as the two arguments
of a SYSTEM::BACKQUOTE macro call. That macro, did no work at all: it
just regurgitated the second argument, namely the ready-made code
produced by the reader, ignoring the Scheme-like backquote structure
in the first argument. The reason for retaining that structure was to
be able to pretty-print the backquote form as something close to the
original backquote syntax. The macro looked at the second argument,
the pretty printer at the first.
So in other words, the CLISP reader might have turned the above
backquote form into something like:
(SYSTEM::BACKQUOTE (A (SYSTEM::SPLICE (LIST B C)) D)
(LIST 'A B C 'D))
Evaluating the above would spit out (LIST 'A B C 'D), and
pretty-printing it would invoke a special recognizer for
SYSTEM::BACKQUOTE that would work exclusively with the first argument.
Thus, the trick of trying to extract the implementation-specific
unquote forms did not work; it succeeded in producing a backquote form
that pretty-printed properly, but did not actually evaluate to
anything meaningful, lacking the third argument that would supply the
code! What looked like a target expression language for writing
backquotes really wasn't.
The new implementation has a ``fat'' backquote macro which does the
actual work of compiling a Scheme-like representation to code. The
reader is now ``thin''. There is no second argument to the macro; the
pretty printer works with the same data as the macro expander, and the
CLISP user has an implementation-specific target language for making
backquote forms.
···@ashi.footprints.net (Kaz Kylheku) writes:
> Joe Marshall <···@ccs.neu.edu> wrote in message news:<············@ccs.neu.edu>...
> > ····@rpw3.org (Rob Warnock) writes:
> >
> > > O.k., let me restate that -- I should have said: The only way I see to
> > > use exactly Scsh-like syntax would be to define one's own reader macros
> > > for backquote and comma, effectively replacing the built-in ones with
> > > one's own. [Yes, you could, I suppose, do something like temporarily
> > > restore the original definitions when you see a backquote until that
> > > subexpression is read and then pop back to your own, but it would
> > > probably be easier overall to do the whole thing yourself and not try
> > > to mix the styles].
> > >
> > > So to repeat: Am I missing something simple/obvious? Or is that the
> > > best one can do?
> >
> > Common Lisp generally uses the same trick as Scheme: replace the comma
> > and ······@ forms with some sort of unquote and unquote-splicing form.
> > The only difference being that Scheme defines a canonical name for the
> > unquoting.
> >
> > You ought to be able to extract the implementation-specific names
> > with a macro.
>
> Unfortunately, this isn't true, as I found out empirically by
> writing just such a program. There is a great deal of variety in the
> representation of backquotes.
Kaz, since you went through all this pain to discover how different
implementations dealt with backquotes, I'd be interested in your
opinion on something.
Let me preface my question with an observation: it seems to me that
there is a theory of language specification that it is good to avoid
overspecifying things, lest implementations be unduly constrained by
the specification. Thus leaving details like exactly how backquotes
are handled are up to the implementation, allows the possibility of
folks finding different, better ways of doing things. (Which is not to
say, that this theory is why backquote is specified the way it is;
it's pure speculation on my part that it might have influenced the
decision.)
So my question is: did you see, while looking at thoes different
implementations, evidence that the diversity allowed by not
specifiying a particular implementation of backquotes yielded any
benefits? Did some implementations come up with particularly clever
optimizations that would have been precluded by a more tightly
specified definition of backquote? (I'm thinking of something more
like the definition of the relation between ' and QUOTE, e.g. ` being
defined to simply be a reader macro for a BACKQUOTE macro, which would
then be defined by the standard. In the spirit of the recent
discussion of Lisp/Scheme detente, I noticed the other day that's more
or less how R5Rs defines `, et al.)
And for anyone who participated in the standardization, I am, as
always, interested to hear the backstory on how these decisions were
made, what alternatives, if any, were considered, etc.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
> ···@ashi.footprints.net (Kaz Kylheku) writes:
>
> > Joe Marshall <···@ccs.neu.edu> wrote in message news:<············@ccs.neu.edu>...
> > > ····@rpw3.org (Rob Warnock) writes:
> > >
> > > > O.k., let me restate that -- I should have said: The only way I see to
> > > > use exactly Scsh-like syntax would be to define one's own reader macros
> > > > for backquote and comma, effectively replacing the built-in ones with
> > > > one's own. [Yes, you could, I suppose, do something like temporarily
> > > > restore the original definitions when you see a backquote until that
> > > > subexpression is read and then pop back to your own, but it would
> > > > probably be easier overall to do the whole thing yourself and not try
> > > > to mix the styles].
> > > >
> > > > So to repeat: Am I missing something simple/obvious? Or is that the
> > > > best one can do?
> > >
> > > Common Lisp generally uses the same trick as Scheme: replace the comma
> > > and ······@ forms with some sort of unquote and unquote-splicing form.
> > > The only difference being that Scheme defines a canonical name for the
> > > unquoting.
> > >
> > > You ought to be able to extract the implementation-specific names
> > > with a macro.
> >
> > Unfortunately, this isn't true, as I found out empirically by
> > writing just such a program. There is a great deal of variety in the
> > representation of backquotes.
>
> Kaz, since you went through all this pain to discover how different
> implementations dealt with backquotes, I'd be interested in your
> opinion on something.
>
> Let me preface my question with an observation: it seems to me that
> there is a theory of language specification that it is good to avoid
> overspecifying things, lest implementations be unduly constrained by
> the specification. Thus leaving details like exactly how backquotes
> are handled are up to the implementation, allows the possibility of
> folks finding different, better ways of doing things. (Which is not to
> say, that this theory is why backquote is specified the way it is;
> it's pure speculation on my part that it might have influenced the
> decision.)
>
> So my question is: did you see, while looking at thoes different
> implementations, evidence that the diversity allowed by not
> specifiying a particular implementation of backquotes yielded any
> benefits?
No; and in fact I rewrote CLISP's implementation to do it the
``canonical'' way. Not for that reason, mind you; the real intent was
to fix bugs.
In many cases, the final code generated by the old and new
implementation is exactly the same. In some cases, the code is
actually better. I put the optimization into a separate filtering
which doesn't care which pieces came from the backquote template and
which were spliced in. So for example if you have something like `(a
,@(list 'b 'c) d), the first pass turns it into something like (append
(list 'a) (list 'b 'c) (list 'd)) and the optimizer can crack the
(list ...) expressions to realize that the whole thing can just be '(a
b c d). It doesn't distinguish where the (list ...) came from. The
old reader macro was trying to optimize and generate in one pass, so
it could not see cases like that.
> Did some implementations come up with particularly clever
> optimizations that would have been precluded by a more tightly
> specified definition of backquote?
No, because a tightly defined intermediate language based on lists
does not preclude any optimizations whatsoever. The intermediate
language is just a notational transliteration that doesn't constrain
the semantics in any way. Informal proof: you can print that language
back to backquote notation, and then process that notation from
scratch however you want.
One feature of the CL backquote notation that allows for useful
optimizations is the destructive splicing operator ,. (comma dot).
It's important for the implementation to try to generate code that
uses destructive list manipulation. A list-based target language for
Common Lisp backquotes must be able to articulate the difference
between a regular splice and a destructive splice.
That being said, the freedom in the CL requirements for backquote
processing does allow implementors to choose how much work is done at
read time versus later. You can have a ``fat'' reader macro which does
most of the work. Or you can have a ``thin'' reader macro which lets a
subsequent macro do most of the work. I tend to gravitate toward the
opinion that there is no value in a ``fat'' reader macro for
backquotes, and in fact that it's a waste of time to do all that
expansion work for backquotes that might never be evaluated.
Ultimately, what matters most is the quality of the generated
code---and only in cases when the result of the backquote expansion
occurs in some inner loop of the actual running application. Most
backquotes occur in macro bodies, so the efficiency of the generated
code affects the compilation time of a large Lisp system that has many
macros.
For an application's performance to be affected by the backquote
compiler, it has to generate code that uses backquotes. That's hard to
do, given you don't have a target language to do so, other than the
character-level syntax you can feed to the reader. :)
Tuang wrote:
> Are there any new Lisp-family languages being created?
...
> Are there any other "new Lisps" in the making?
GOO might qualify: http://www.ai.mit.edu/~jrb/goo/
Both Arc and Goo offer some good justifications for certain kinds of
changes. But another point here is that Lisps in general are good at being
extended in all sorts of directions - the ultimate growable languages -
which makes it more difficult to justify and create "new Lisps", whose
features can't simply be assimilated into other Lisps.
So to look for new language development in the Lisp world, look also at
what's being done on top of existing implementations. That happens quite a
bit with Scheme implementations, for example: PLT Scheme is actively
developing in interesting directions on multiple fronts, including a module
system with the ability to define custom languages, as well as some
interesting IDE features like embedded XML editing with automatic conversion
to S-expressions. Java-based Schemes like SISC have neat ways of
integrating with the Java type system, e.g. using generic functions. A
number of systems offer continuation-based web server state handling.
There's a lot of activity like this that doesn't show up in the form of "new
Lisps".
Anton
From: Kenny Tilton
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F4C43F3.3020502@nyc.rr.com>
Anton van Straaten wrote:
> Tuang wrote:
>
>>Are there any new Lisp-family languages being created?
>
> ....
>
>>Are there any other "new Lisps" in the making?
>
>
> GOO might qualify: http://www.ai.mit.edu/~jrb/goo/
>
> Both Arc and Goo offer some good justifications for certain kinds of
> changes. But another point here is that Lisps in general are good at being
> extended in all sorts of directions - the ultimate growable languages -
> which makes it more difficult to justify and create "new Lisps", whose
> features can't simply be assimilated into other Lisps.
yep. and look at how long it takes a language to mature, stabilize, get
optimizing native compilers, etc etc. why start that process all over
again when, as you say, whatever we might dream up (Cells?) can be built
atop the language?
Even if I decide I would like to see compiled Cells, shucks, there is a
common lisp compiler out there for the taking, cmucl.
I would answer the OP that /he/ is what is happening in the Lisp world
today. This page still seems to be here:
http://www.cliki.net/The%20RtLS%20by%20Road
...a few of the new faces appearing on the seen almost daily. We can
guess where this is going to lead (more and more users), and where that
will lead (more libraries, bindings to C libs, etc etc), and soon enough
<gasp!> Lisp jobs.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
> yep. and look at how long it takes a language to mature, stabilize, get
> optimizing native compilers, etc etc. why start that process all over
> again when, as you say, whatever we might dream up (Cells?) can be built
> atop the language?
Its a matter of differing priorities. If your priority is just to
finish this particular job as quickly as possible, then by all means,
use whatever language allows you to do that. However, if your priority
is to work with a language that is clean and elegant, than you will
probably be attracted to languages that are less immediately
utilitarian, but more beautiful by your own standards.
There are two major reasons new languages get written:
1) To do something not technologically possible in another language.
Haskell is useful in certain problem spaces because you can run a
theorem prover on it. SequenceL was designed to exploit the highly
parallel supercomputers used by the government. AspectJ was created to
allow aspect-oriented iiutechniques. You just cannot do these things
in CL.
2) To explore language design. To make languages that are not
necessarily useful, but that conform to a particular model of
computing. This is something else you can't build on top of an
existing language. You can do functional programming very well in
Lisp, but you can't change the fact that it is an eager-evaluating
language that allows side-effects.
Personal example: My work requires me to use C++. So at work, I use
C++, and go on my way. Now, I was looking awhile ago at languages that
I would want to use when hacking just for the fun of it. I looked at
CL, and immediately passed and went on to Dylan. Why? Well, CLOS is
not "objects all the way down" (built-in functions like +/- aren't
generic). "t" and "nil" don't look as nice next to each other "#t" and
"#f". Does any of this matter in practice? Hell no! They are largely
superficial reasons. But I don't care if Lisp has better development
tools, or a zillion times as many available libraries, or that cmucl
has qt bindings (I use KDE) while d2c only has gtk+ bindings. My goal
isn't to get a particular project done as quickly as possible (that's
what I do at work!) but to have fun while doing it.
On Thu, Aug 28, 2003 at 03:10:24PM -0700, Rayiner Hashem wrote:
> 1) To do something not technologically possible in another language.
> Haskell is useful in certain problem spaces because you can run a
> theorem prover on it. SequenceL was designed to exploit the highly
> parallel supercomputers used by the government. AspectJ was created to
> allow aspect-oriented iiutechniques. You just cannot do these things
> in CL.
I would just like to point out two things:
(a) ACL2 (http://www.cliki.net/ACL2)
(b) _The Art of the Meta-Object Protocol_, co-authored by the creator of
AspectJ, which describes an implementation of CLOS with a Meta-Object
protocol that has been very influential in the implementation of many
CLs.
You can't say ``can't'' ;-)
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
> (a) ACL2 (http://www.cliki.net/ACL2)
This one is debatable. From a cursory look, it seems that, while ACL2
is built on top of Common Lisp, its not *all* of CL. Specifically, its
not any old CL code that's being run through the theorem prover, but a
special sub-language defined on top of CL. I could just as well write
a theorem prover for a purely functional subset of C, in C, and claim
that C code is provable. ACL2 is useful, but mainly just proves that
CL is a good language for writing language translators/compilers in.
The nice thing about Haskell is that all proper Haskell programs are
provable, not just a subset.
> (b) _The Art of the Meta-Object Protocol_, co-authored by the creator of
> AspectJ, which describes an implementation of CLOS with a Meta-Object
> protocol that has been very influential in the implementation of many
> CLs.
I'll have to research this one a bit more, but I think you might be
right. AspectJ is specially designed for AOP, so it might be more
appropriate to the task, but it does seem that the MOP encapsulates a
lot of AOP features.
·······@mindspring.com (Rayiner Hashem) writes:
> > (b) _The Art of the Meta-Object Protocol_, co-authored by the creator of
> > AspectJ, which describes an implementation of CLOS with a Meta-Object
> > protocol that has been very influential in the implementation of many
> > CLs.
> I'll have to research this one a bit more, but I think you might be
> right. AspectJ is specially designed for AOP, so it might be more
> appropriate to the task, but it does seem that the MOP encapsulates a
> lot of AOP features.
You might be also interested in looking at the message
<http://groups.google.com/groups?q=g:thl3496297078d&dq=&hl=en&lr=&ie=UTF-8&selm=costanza-65382E.21360723042003%40news.netcologne.de>
and the discussion that followed. IIRC the conclusion was that AOP can
be done in "plain" CL, and that it is in fact quite natural.
Rayiner Hashem wrote:
>>(a) ACL2 (http://www.cliki.net/ACL2)
>
> This one is debatable. From a cursory look, it seems that, while ACL2
> is built on top of Common Lisp, its not *all* of CL. Specifically, its
> not any old CL code that's being run through the theorem prover, but a
> special sub-language defined on top of CL. I could just as well write
> a theorem prover for a purely functional subset of C, in C, and claim
> that C code is provable. ACL2 is useful, but mainly just proves that
> CL is a good language for writing language translators/compilers in.
> The nice thing about Haskell is that all proper Haskell programs are
> provable, not just a subset.
Well, but then again Haskell is just a subset of other languages in
terms of concepts, so this doesn't prove anything.
Furthermore, they don't _claim_ that ACL2 is provable, they use it for
industrial applications.
Are there any real-world applications of Haskell? (This is not a
rhetorical question - I really don't know...)
>>(b) _The Art of the Meta-Object Protocol_, co-authored by the creator of
>>AspectJ, which describes an implementation of CLOS with a Meta-Object
>>protocol that has been very influential in the implementation of many
>>CLs.
>
> I'll have to research this one a bit more, but I think you might be
> right. AspectJ is specially designed for AOP, so it might be more
> appropriate to the task, but it does seem that the MOP encapsulates a
> lot of AOP features.
No, AOP is just another buzzword for metaprogramming. A MOP allows you
to define properties for / change the behavior of specially tagged
classes and methods. The only thing AOP adds to that is that you don't
need to tag the stuff that you want to affect. (This is what they a call
a join point model.)
95% of the AOP stuff already exists in CLOS. The rest can be added
relatively easily.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
> Well, but then again Haskell is just a subset of other languages in
> terms of concepts, so this doesn't prove anything.
This proves that there are things you can do in other languages that
you cannot in Lisp. That was the original point of the post --- why
other languages are created. Sometimes, you have to remove features
(side-effects) to get something particularly important to you
(provability).
>
> Furthermore, they don't _claim_ that ACL2 is provable, they use it for
> industrial applications.
But the whole point of Haskell is that its provable! ACL2 might be a
fine program for its application domain, but that domain isn't the
same as Haskell's.
>
> Are there any real-world applications of Haskell? (This is not a
> rhetorical question - I really don't know...)
Sure. In addition to applications in its traditional mathematical
domain, it has lots of applications in the area of "trusted kernels."
That is, pieces of code that guarantee (provably) that larger pieces
of code have a certain external behavior. Also, consider OWL (the new
semantic web language). It is first order logic expressed in very
verbose and hard to write XML. New extensions will allow certain
executable expressions to co-exist with logic statements. To me, it
seems like a perfect application for a real executable first-order
logic language.
Rayiner Hashem wrote:
>>Well, but then again Haskell is just a subset of other languages in
>>terms of concepts, so this doesn't prove anything.
>
> This proves that there are things you can do in other languages that
> you cannot in Lisp. That was the original point of the post --- why
> other languages are created. Sometimes, you have to remove features
> (side-effects) to get something particularly important to you
> (provability).
The subset of Common Lisp that is used in ACL2 is created exactly
because of this reason. Care to explain why creating a subset is not
acceptable whereas creating a completely new language is?
>>Furthermore, they don't _claim_ that ACL2 is provable, they use it for
>>industrial applications.
>
> But the whole point of Haskell is that its provable! ACL2 might be a
> fine program for its application domain, but that domain isn't the
> same as Haskell's.
The subset of CL used in ACL2 is provable as well. When they discover
new proof strategies they might even be able to create a larger subset.
In fact, they do have some form of side effects in their language
without harming provability.
What do you mean by "application domain" in this context?
Pascal
> The subset of Common Lisp that is used in ACL2 is created exactly
> because of this reason. Care to explain why creating a subset is not
> acceptable whereas creating a completely new language is?
It helps to keep the original point in mind. The point was that you
might want to create a new language because Common Lisp isn't
provable. While ACL2 might be provable, and might be implemented *on*
Common Lisp, it is not itself Common Lisp. To get a good provable
language along the lines of Haskell or Clean, you'd have to do most of
the language design that went into Haskell and Clean. After doing that
design, you've created a new language. At that point, using CL macros
as a substrate is just an implementation consideration. Whether its a
good one is debatable. Haskell and Clean have such different
computational models to that of CL (lazy vs eager, static vs dynamic,
pure vs unpure, etc), that implementing them on top of CL would be
onerous and possibly very slow. Its useful to note that compilers for
Haskell/Clean have very different priorities than compilers for CL.
Thus, less is wasted by not building on top of CL than one would
think.
> What do you mean by "application domain" in this context?
I think that one would not use ACL2 and Haskell or Clean in the same
types of projects. You would use ACL2 when you needed to write
provable logic statements in a CL program. You'd use Haskell or Clean
when you'd want to write a complete application that could be
rigerously checked.
In article <····························@posting.google.com>,
·······@mindspring.com (Rayiner Hashem) wrote:
> > The subset of Common Lisp that is used in ACL2 is created exactly
> > because of this reason. Care to explain why creating a subset is not
> > acceptable whereas creating a completely new language is?
> It helps to keep the original point in mind. The point was that you
> might want to create a new language because Common Lisp isn't
> provable. While ACL2 might be provable, and might be implemented *on*
> Common Lisp, it is not itself Common Lisp. To get a good provable
> language along the lines of Haskell or Clean, you'd have to do most of
> the language design that went into Haskell and Clean. After doing that
> design, you've created a new language. At that point, using CL macros
> as a substrate is just an implementation consideration. Whether its a
> good one is debatable. Haskell and Clean have such different
> computational models to that of CL (lazy vs eager, static vs dynamic,
> pure vs unpure, etc), that implementing them on top of CL would be
> onerous and possibly very slow. Its useful to note that compilers for
> Haskell/Clean have very different priorities than compilers for CL.
> Thus, less is wasted by not building on top of CL than one would
> think.
>
> > What do you mean by "application domain" in this context?
> I think that one would not use ACL2 and Haskell or Clean in the same
> types of projects. You would use ACL2 when you needed to write
> provable logic statements in a CL program. You'd use Haskell or Clean
> when you'd want to write a complete application that could be
> rigerously checked.
Which prover can do that for full Haskell?
········@hotmail.com (Tuang) writes:
> Is there another Common Lisp standard in the works? Another Scheme
> standard?
The Scheme Requests for Implementation (SRFI) process is adding some
long-overdue standardization to the Scheme community. I don't expect to
see R6RS any time in the next few years, though.
From: Marco Antoniotti
Subject: Re: What's happening in the Lisp world today?
Date:
Message-ID: <3F4D1C72.3090103@cs.nyu.edu>
Bruce Lewis wrote:
> ········@hotmail.com (Tuang) writes:
>
>
>>Is there another Common Lisp standard in the works? Another Scheme
>>standard?
>
>
> The Scheme Requests for Implementation (SRFI) process is adding some
> long-overdue standardization to the Scheme community. I don't expect to
> see R6RS any time in the next few years, though.
Yeah. Some of the stuff is needed since the publication of CLtL1 (mid 80's)
Cheers
--
Marco
In article <···············@biohazard-cafe.mit.edu>,
Bruce Lewis <·······@yahoo.com> wrote:
> ········@hotmail.com (Tuang) writes:
>
> > Is there another Common Lisp standard in the works? Another Scheme
> > standard?
>
> The Scheme Requests for Implementation (SRFI) process is adding some
> long-overdue standardization to the Scheme community. I don't expect to
> see R6RS any time in the next few years, though.
and the SRFI process seems to work nicely...
········@hotmail.com (Tuang) writes:
[...]
> Is there another Common Lisp standard in the works? Another Scheme
> standard?
Why do you want *another* new stuffs. There is still plenty of
unused languages in this world. Did you try Common Lisp? It's a
well-designed language and very complete. There is a lot of
libraries to do all your day-to-day stuffs!
Concerning implementations, *all* commercials implementations are
well supported and comes with a lot of recent features, like XML,
RPC, graphics, GUI, etc...
Concerning the Common Lisp community, it's really amazing to be able
to talk with the masters just about anything about computing. This
is an execptional opportunity to have such experimeted people here!
This is not the case with, say the Java community.
Concerning Free implementation, SBCL is a growing one. With a lot
of refactoring and a lot of availables features. Working with a
Debian system is a plus because every Common Lisp library is
packaged within the system.
My suggestion. Start learning and using Common Lisp.
--
Frederic Brunel
········@hotmail.com (Tuang) writes:
> What's happening in the Lisp world today?
These resources provide short summaries or overviews, and are useful
for keeping reasonably up to date with what goes on in the Lisp world
without checking all newsgroups and mailing lists:
http://alu.cliki.net/Recent%20Changes
http://www.cliki.net/Recent%20Changes
http://lemonodor.com
http://lwn.net (check sections Development/Programming
Languages/[Lisp|Scheme] or Announcements/[Events|Non commercial])
Most of the above sites also provide RSS feeds, in case you are
interested.
> And are there any market segments (finance, robotics, etc.) or fields
> where the use of Lisp is increasing significantly? Not the standard
> "Viaweb and Orbitz" examples, but domains in which Lisp is growing.
Check the industry applications and success stories pages at:
http://alu.cliki.net
Paolo
--
Paolo Amoroso <·······@mclink.it>
> (or put it on a back burner? went underground? anybody know?)
For what it's worth, I sent him some ARC suggestions a couple of weeks
ago and immediately got an excited reply back from the big "G" himself
about it, so I'd say it looks like it is still in the works.