What's happening in the Lisp world today?
Tuang
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.
Edi Weitz
> 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.
Anton van Straaten
> 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
whampa
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" <tuan...@hotmail.com> wrote in message
news:df045d93.03082...@posting.google.com...
Kenny Tilton
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
Tuang
> On 26 Aug 2003 13:24:34 -0700, tuan...@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.
Edi Weitz
> > <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.
Bruce Lewis
> 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.
Mario S. Mommer
> > 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.
Matthias
> 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.
Michael Livshin
> 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.
Anton van Straaten
news:s33cfnq...@laredo.verisity.com.cmm...
> Matthias <sp...@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
Douglas Philips
[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
Michael Livshin
> 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
Frederic Brunel
[...]
> 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
Anton van Straaten
> "Anton van Straaten" <an...@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
Tuang
>
> - 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.
Michael Livshin
> 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.
Jens Axel Søgaard
> "Anton van Straaten" <an...@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
Michael Livshin
> Michael Livshin wrote:
>> "Anton van Straaten" <an...@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.
Paul F. Dietz
> 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
Tuang
> tuan...@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.
Marco Antoniotti
Yeah. Some of the stuff is needed since the publication of CLtL1 (mid 80's)
Cheers
--
Marco
Daniel Barlow
> 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
Anton van Straaten
> "Anton van Straaten" <an...@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
Lars Brinkhoff
> 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/
Anton van Straaten
> "Anton van Straaten" <an...@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
Michael Livshin
"Anton van Straaten" <an...@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.
Nils Goesche
> 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
Anton van Straaten
> >> 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
>
> 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
Wade Humeniuk
"Anton van Straaten" <an...@appsolutions.com> wrote in message
news:zO93b.17594$8i2....@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.
Anton van Straaten
> 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
Tuang
> 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. ;-)
Anton van Straaten
> 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
Nils Goesche
> 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.
Erann Gat
tuan...@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.
Kenny Tilton
Nils Goesche wrote:
> "Anton van Straaten" <an...@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
Michael Livshin
> 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
Paolo Amoroso
> 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:
Paolo
--
Paolo Amoroso <amo...@mclink.it>
Wade Humeniuk
> > 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
Daniel Barlow
> 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.
Douglas Philips
> Douglas Philips <dg...@mac.com> writes:
>>Its too bad the cruft can't be removed: LOOP and FORMAT spring
>>instantly to mind.
>
> 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
Espen Vestre
> 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)
Douglas Philips
>>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
Bruce Lewis
> 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.
Espen Vestre
> 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)
Joe Marshall
> In article <df045d93.03082...@posting.google.com>,
> tuan...@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.
Joe Marshall
Can we have comp.lang.lisp.abuse, too?
Douglas Philips
> 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
Daniel Barlow
> 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
Erann Gat
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.
Raymond Wiker
... 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: Raymon...@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/
Anton van Straaten
> 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*
>
> 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
> "Anton van Straaten" <an...@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
> 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
> 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
Mario S. Mommer
> > 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".
Nils Goesche
> 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
Anton van Straaten
> > 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
Joe Marshall
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?
Nils Kassube
> 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.
Doug Tolton
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.~a" "dtolton" "ya" "hoo" "com")
Kenny Tilton
Nils Goesche wrote:
> "Anton van Straaten" <an...@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.
Anton van Straaten
> 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
Daniel Barlow
> 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?
Anton van Straaten
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
> Daniel Barlow <d...@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
Douglas Philips
> 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
Nils Goesche
> 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.
Rayiner Hashem
> 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?
Anton van Straaten
> "Anton van Straaten" <an...@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
Mario S. Mommer
> 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.
Anton van Straaten
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
Mario S. Mommer
> 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.
Daniel Barlow
> 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?
Anton van Straaten
> "Anton van Straaten" <an...@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
Damien R. Sullivan
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-)
Erann Gat
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
bbnlm2$b1s19$1...@ID-60390.news.dfncis.de. Go ye forth and read it.
(I note in passing that you participated in that thread.)
E.
Mario S. Mommer
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?
Daniel Barlow
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"
Ray Blaak
> 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,
rAYb...@STRIPCAPStelus.net The Rhythm has my soul.
Rayiner Hashem
> 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.
Pascal Costanza
> 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
Matthew Danish
> Doug Tolton <dto...@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 <mda...@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
> 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'' ;-)
Anton van Straaten
> 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
Tayss
> No. Scheme willfuly departed from almost anything that might be
> 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.
Anton van Straaten
> hel...@mindspring.com (Rayiner Hashem) wrote:
> > [Nils Goesche wrote:]
> >> No. Scheme willfuly departed from almost anything that might be
> >> 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
Anton van Straaten
> 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
Pascal Bourguignon
"Anton van Straaten" <an...@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.
Edi Weitz
> 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.
Daniel Barlow
> 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
Daniel Barlow
> On Thu, 28 Aug 2003 15:53:26 +0100, Daniel Barlow <d...@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.
Conrad Barski
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.
Rayiner Hashem
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.
Rayiner Hashem
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.
Edi Weitz
> 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.
Mario S. Mommer
> > (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
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.
Rob Warnock
+---------------
| 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 <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Pascal Costanza
>>"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
mailto:cost...@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Jacek Generowicz
> 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 ?
Pascal Costanza
>>(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.