Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Ruby style

14 views
Skip to first unread message

Chris Gehlker

unread,
Dec 2, 2002, 10:30:42 AM12/2/02
to
I thought all Lisp predicates ended with 'p' but now I'm seeing some that
adopt the Ruby convention and end with '?'. What I haven't seen is the other
Ruby convention that the names of all destructive operators should end with
'!'. I think that would be a good idea, at least for future definitions.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

Jochen Schmidt

unread,
Dec 2, 2002, 10:40:21 AM12/2/02
to
Chris Gehlker wrote:

> I thought all Lisp predicates ended with 'p' but now I'm seeing some that
> adopt the Ruby convention and end with '?'. What I haven't seen is the
> other Ruby convention that the names of all destructive operators should
> end with '!'. I think that would be a good idea, at least for future
> definitions.

Thats what I know as a Scheme convention. I suppose Ruby got it from there.

I think it is better to use the conventions of the language itself and will
use 'p', '-p' and 'n' when I think it fits.

As a matter of taste I prefer calling a zero testing predicate "ZEROP" with
pronounced 'p' and spoken as one syllable instead of "ZERO?" with
pronounciation like a question.
If I just want to talk about the predicate I do not want to let it sound
like a question.

A similar rant goes to the use of '!' (how do you pronounce it? Or do you
then say "SET BASH"?)

just my 0.02 Euro...

ciao,
Jochen

--
http://www.dataheaven.de

Pascal Costanza

unread,
Dec 2, 2002, 10:55:23 AM12/2/02
to
Chris Gehlker wrote:
> I thought all Lisp predicates ended with 'p' but now I'm seeing some that
> adopt the Ruby convention and end with '?'. What I haven't seen is the other
> Ruby convention that the names of all destructive operators should end with
> '!'. I think that would be a good idea, at least for future definitions.

In Scheme, the ?/! convention is generally used while in Common Lisp,
predicates usually end with p. People won't like it if you mix that up.


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)

Chris Gehlker

unread,
Dec 2, 2002, 11:16:55 AM12/2/02
to
On 12/2/02 8:40 AM, in article asfuto$r8s$04$1...@news.t-online.com, "Jochen
Schmidt" <j...@dataheaven.de> wrote:

> Chris Gehlker wrote:
>
>> I thought all Lisp predicates ended with 'p' but now I'm seeing some that
>> adopt the Ruby convention and end with '?'. What I haven't seen is the
>> other Ruby convention that the names of all destructive operators should
>> end with '!'. I think that would be a good idea, at least for future
>> definitions.
>
> Thats what I know as a Scheme convention. I suppose Ruby got it from there.

Aha! I didn't know that about Scheme. I suspect you are right about Ruby
getting it there. BTW, are Scheme coders called schemers?


>
> I think it is better to use the conventions of the language itself and will
> use 'p', '-p' and 'n' when I think it fits.

I'm not familiar with the 'n' convention. Would you elaborate?


>
> As a matter of taste I prefer calling a zero testing predicate "ZEROP" with
> pronounced 'p' and spoken as one syllable instead of "ZERO?" with
> pronounciation like a question.
> If I just want to talk about the predicate I do not want to let it sound
> like a question.

I think the '!' is much more useful than the '?' for two reasons. First, as
you say, Lisp already has a perfectly useful convention for naming
predicates. Second, I think it's generally more obvious from context when
something is a predicate than when it is destructive.

> A similar rant goes to the use of '!' (how do you pronounce it? Or do you
> then say "SET BASH"?)

Typically the ! is silent. I have heard <name>! pronounced
'destructive-<name>' when there was a safe function called <name>.

Donald Fisk

unread,
Dec 2, 2002, 1:58:56 PM12/2/02
to
Jochen Schmidt wrote:
>
> Chris Gehlker wrote:
>
> > I thought all Lisp predicates ended with 'p' but now I'm seeing some that
> > adopt the Ruby convention and end with '?'. What I haven't seen is the
> > other Ruby convention that the names of all destructive operators should
> > end with '!'. I think that would be a good idea, at least for future
> > definitions.
>
> Thats what I know as a Scheme convention. I suppose Ruby got it from there.

It is a Scheme convention, and seeing as Common Lisp is closer to Scheme
and Scheme's been around a lot longer than Ruby, it's almost certainly
from Scheme.

> A similar rant goes to the use of '!' (how do you pronounce it? Or do you
> then say "SET BASH"?)

"set bang". I cannot recall how '?' is pronounced.

> Jochen

Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs, sex, and rock & roll. Late nights at Berkeley, coding in
Lisp fueled by LSD. Java evokes a vision of a stereotypical nerd,
with no life or social skills.

Thomas F. Burdick

unread,
Dec 2, 2002, 2:34:08 PM12/2/02
to
Chris Gehlker <geh...@fastq.com> writes:

> On 12/2/02 8:40 AM, in article asfuto$r8s$04$1...@news.t-online.com, "Jochen
> Schmidt" <j...@dataheaven.de> wrote:
>
> > Chris Gehlker wrote:
> >
> >> I thought all Lisp predicates ended with 'p' but now I'm seeing some that
> >> adopt the Ruby convention and end with '?'. What I haven't seen is the
> >> other Ruby convention that the names of all destructive operators should
> >> end with '!'. I think that would be a good idea, at least for future
> >> definitions.
> >
> > Thats what I know as a Scheme convention. I suppose Ruby got it from there.
>
> Aha! I didn't know that about Scheme. I suspect you are right about Ruby
> getting it there. BTW, are Scheme coders called schemers?
> >
> > I think it is better to use the conventions of the language itself and will
> > use 'p', '-p' and 'n' when I think it fits.
>
> I'm not familiar with the 'n' convention. Would you elaborate?

Prefixing "n" gives you the destructive version of a function. I'm of
mixed feelings about this, because is screws up sorting (eg,
permute-list and npermute-list will not be near each other in an
alphabetical list of symbols, which also means that if I type
permu-li<TAB>, I will only see the non-destructive version, whereas a
postfix convention shows me both). The "n" stands for "non-consing",
I believe.

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

Jochen Schmidt

unread,
Dec 2, 2002, 2:55:05 PM12/2/02
to
Chris Gehlker wrote:

> On 12/2/02 8:40 AM, in article asfuto$r8s$04$1...@news.t-online.com, "Jochen
> Schmidt" <j...@dataheaven.de> wrote:
>
>> Chris Gehlker wrote:
>>
>>> I thought all Lisp predicates ended with 'p' but now I'm seeing some
>>> that adopt the Ruby convention and end with '?'. What I haven't seen is
>>> the other Ruby convention that the names of all destructive operators
>>> should end with '!'. I think that would be a good idea, at least for
>>> future definitions.
>>
>> Thats what I know as a Scheme convention. I suppose Ruby got it from
>> there.
>
> Aha! I didn't know that about Scheme. I suspect you are right about Ruby
> getting it there. BTW, are Scheme coders called schemers?

No I think they are called "students" ;-)


>> I think it is better to use the conventions of the language itself and
>> will use 'p', '-p' and 'n' when I think it fits.
>
> I'm not familiar with the 'n' convention. Would you elaborate?

There are several functions in Common Lisp which have "n" as a prefix. AFAIR
this means "non-consing". The "non-consing" alternative to REVERSE is for
example NREVERSE. The n-prefix convention seems to be less strict than the
p/-p convention as APPEND/NCONC or REMOVE/DELETE show. NCONC at least has
still the "non-consing" prefix but I do not really know why they did not
call it NAPPEND. I suppose for backward compatibility.

>> As a matter of taste I prefer calling a zero testing predicate "ZEROP"
>> with pronounced 'p' and spoken as one syllable instead of "ZERO?" with
>> pronounciation like a question.
>> If I just want to talk about the predicate I do not want to let it sound
>> like a question.
>
> I think the '!' is much more useful than the '?' for two reasons. First,
> as you say, Lisp already has a perfectly useful convention for naming
> predicates. Second, I think it's generally more obvious from context when
> something is a predicate than when it is destructive.
>
>> A similar rant goes to the use of '!' (how do you pronounce it? Or do you
>> then say "SET BASH"?)
>
> Typically the ! is silent. I have heard <name>! pronounced
> 'destructive-<name>' when there was a safe function called <name>.

IMHO marking destructive functions is less important than marking predicate
names. Maybe such a convention is more suitable to scheme were destructive
functions are considered as stylistically poor. CL is less constrained by
ideas about stylistic pureness.

Many sideeffects are also already marked by names like "(setf
accessor-name)"

Chris Gehlker

unread,
Dec 2, 2002, 3:27:22 PM12/2/02
to
On 12/2/02 12:34 PM, in article xcvof84...@avalanche.OCF.Berkeley.EDU,

"Thomas F. Burdick" <t...@avalanche.OCF.Berkeley.EDU> wrote:

> Prefixing "n" gives you the destructive version of a function. I'm of
> mixed feelings about this, because is screws up sorting (eg,
> permute-list and npermute-list will not be near each other in an
> alphabetical list of symbols, which also means that if I type
> permu-li<TAB>, I will only see the non-destructive version, whereas a
> postfix convention shows me both). The "n" stands for "non-consing",
> I believe.

I'm glad to learn that there is a convention. I'm as puzzled as you are that
a prefix notation was chosen.

JB

unread,
Dec 2, 2002, 3:46:01 PM12/2/02
to
Chris Gehlker wrote:

> I thought all Lisp predicates ended with 'p' but now I'm
> seeing some that adopt the Ruby convention and end with
> '?'. What I haven't seen is the other Ruby convention that
> the names of all destructive operators should end with
> '!'. I think that would be a good idea, at least for
> future definitions.

Yes. This is because Ruby is much older than Scheme or Lisp.
Lisp and Scheme have learnt a lot from Ruby and Python but
they (Lisp and Scheme) have not caught up with their great
predecessors completely.
--
JB

Chris Gehlker

unread,
Dec 2, 2002, 4:11:55 PM12/2/02
to
On 12/2/02 1:46 PM, in article asgg59$rcej1$1...@ID-167393.news.dfncis.de, "JB"
<jbl...@hotmail.com> wrote:

Of course! My Ruby is version 1.67 but my CL is only at version 0.13.

Kent M Pitman

unread,
Dec 2, 2002, 4:33:23 PM12/2/02
to
Donald Fisk <hibou000...@enterprise.net> writes:

> I cannot recall how '?' is pronounced.

"pee".

Those of us who adhere to this convention get auditory compatibility
between the Lisp and Scheme camp. ;)

Dorai Sitaram

unread,
Dec 2, 2002, 4:45:41 PM12/2/02
to
In article <asgdru$s75$06$1...@news.t-online.com>,

Jochen Schmidt <j...@dataheaven.de> wrote:
>Chris Gehlker wrote:
>>
>> I think the '!' is much more useful than the '?' for two reasons. First,
>> as you say, Lisp already has a perfectly useful convention for naming
>> predicates. Second, I think it's generally more obvious from context when
>> something is a predicate than when it is destructive.
>
>IMHO marking destructive functions is less important than marking predicate
>names. Maybe such a convention is more suitable to scheme were destructive
>functions are considered as stylistically poor. CL is less constrained by
>ideas about stylistic pureness.

Having to mark a predicate (whether with -p or ?)
is inevitable because otherwise many names would become
identical with the related name for a constructor
procedure. Eg, list vs list?, cons vs consp, and many
user-defined procedures as well. You have to
differentiate these nomenclaturally _somehow_. A small
postfix may be the most painless way to do this. CL
does away with the -p when no ambiguity would result
(eg, null, eq, >, string<=, string-less), refuting the
notion that predicates need to have a typographic
marker.

Marking a destructive operator is more of a
deliberate decision -- the marker is clearly consuming
typographic space for the human reader's benefit. It
hints of things outside of the expression immediately
at hand. Unlike you, I view it as useful info, not a
scold for having used such an operator at all. One
wants to know that side-effects are taking place, even
if one wants side-effects.

Jochen Schmidt

unread,
Dec 2, 2002, 5:30:26 PM12/2/02
to
Dorai Sitaram wrote:

> In article <asgdru$s75$06$1...@news.t-online.com>,
> Jochen Schmidt <j...@dataheaven.de> wrote:
>>Chris Gehlker wrote:
>>>
>>> I think the '!' is much more useful than the '?' for two reasons. First,
>>> as you say, Lisp already has a perfectly useful convention for naming
>>> predicates. Second, I think it's generally more obvious from context
>>> when something is a predicate than when it is destructive.
>>
>>IMHO marking destructive functions is less important than marking
>>predicate names. Maybe such a convention is more suitable to scheme were
>>destructive functions are considered as stylistically poor. CL is less
>>constrained by ideas about stylistic pureness.
>
> Having to mark a predicate (whether with -p or ?)
> is inevitable because otherwise many names would become
> identical with the related name for a constructor
> procedure. Eg, list vs list?, cons vs consp, and many
> user-defined procedures as well. You have to
> differentiate these nomenclaturally _somehow_. A small
> postfix may be the most painless way to do this. CL
> does away with the -p when no ambiguity would result
> (eg, null, eq, >, string<=, string-less), refuting the
> notion that predicates need to have a typographic
> marker.

Yes that was actually my reasoning too.

> Marking a destructive operator is more of a
> deliberate decision -- the marker is clearly consuming
> typographic space for the human reader's benefit. It
> hints of things outside of the expression immediately
> at hand. Unlike you, I view it as useful info, not a
> scold for having used such an operator at all. One
> wants to know that side-effects are taking place, even
> if one wants side-effects.

I did not say that using such a marker is useless. I only argued that
it might not be very important. Using such markers makes sense when one
does not really know what a function does. If I see DELETE used instead of
REMOVE I immediately know that I should take care because DELETE is a
destructive function. I think that it does not make very much sense to try
to understand code without knowing what a function does. The exclamation
mark describes only that it is destructive "in some way" - it says nothing
about what the function really does - so one would likely read the
docstring or other documentation anyway before using or really
understanding it. So the difference betwen the predicate marking and the
"destructive function" marking is that one is done because of common name
collisions and the other is done to document some attribut about the
semantics of a function.

Kaz Kylheku

unread,
Dec 2, 2002, 9:19:20 PM12/2/02
to
Chris Gehlker <geh...@fastq.com> wrote in message news:<BA10CAB2.23F8A%geh...@fastq.com>...

> I thought all Lisp predicates ended with 'p' but now I'm seeing some that
> adopt the Ruby convention and end with '?'. What I haven't seen is the other
> Ruby convention that the names of all destructive operators should end with
> '!'. I think that would be a good idea, at least for future definitions.

You need to get some fact straight. Firstly, Ruby is a dumbed-down
imitation of Lisp with a bad syntax. Secondly, if you see a Lisp
programmer using the ? convention, chances are that it was observed
from Scheme, rather than Ruby. Thirdly, the characters ? and ! are
useful for macro dispatch, which is programmable in Lisp, unlike in
Scheme, which is one good reason for the p convention. Lastly, when
you have the notion of a generalized place, you then have one generic
assignment operator. In Lisp it's called SETF. There is no need for a
destructive operation for updating the substructures of each data
type. As far as destructive methods in object oriented programming go,
their names should be chosen to reflect how they mutate an object; you
don't need a ! suffix to understand that (defmethod resize ((w
window)) ...) probably does something to the object w.

Michael Hudson

unread,
Dec 3, 2002, 6:13:09 AM12/3/02
to
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> Having to mark a predicate (whether with -p or ?)
> is inevitable because otherwise many names would become
> identical with the related name for a constructor
> procedure.

I wish there was an equivalent convention in C++; I recall getting
spectacularly confused by a function called "AcceptQuery" that I
thought was a command (i.e. ProcessQuery) , but actually was a
function (i.e. DoWeWantThisQuery).

I suppose this wouldn't happen if we programmed in latin.

Cheers,
M.

--
We've had a lot of problems going from glibc 2.0 to glibc 2.1.
People claim binary compatibility. Except for functions they
don't like. -- Peter Van Eynde, comp.lang.lisp

Kenny Tilton

unread,
Dec 3, 2002, 6:48:27 AM12/3/02
to

Michael Hudson wrote:
> I suppose this wouldn't happen if we programmed in latin.

Romans, go home?

:)

--

kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd

Chris Gehlker

unread,
Dec 3, 2002, 8:04:33 AM12/3/02
to
On 12/2/02 7:19 PM, in article
cf333042.02120...@posting.google.com, "Kaz Kylheku"
<k...@ashi.footprints.net> wrote:

> You need to get some fact straight. Firstly, Ruby is a dumbed-down
> imitation of Lisp with a bad syntax.

That's just silly. Ruby is a dumbed-down imitation of *Smalltalk* with a bad
syntax.

Raymond Wiker

unread,
Dec 3, 2002, 10:01:36 AM12/3/02
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> Michael Hudson wrote:
> > I suppose this wouldn't happen if we programmed in latin.
>
> Romans, go home?

"Romani eunt domum"?

--- or does that mean "People called Romans they go the house"?

--
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/

Marco Antoniotti

unread,
Dec 3, 2002, 11:03:44 AM12/3/02
to

Raymond Wiker <Raymon...@fast.no> writes:

> Kenny Tilton <kti...@nyc.rr.com> writes:
>
> > Michael Hudson wrote:
> > > I suppose this wouldn't happen if we programmed in latin.
> >
> > Romans, go home?
>
> "Romani eunt domum"?

Now now now! Please write it down correctly on the wall one
godzillion times. :)

Cheers


--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.

Joe Marshall

unread,
Dec 3, 2002, 11:18:25 AM12/3/02
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> Raymond Wiker <Raymon...@fast.no> writes:
>
> > Kenny Tilton <kti...@nyc.rr.com> writes:
> >
> > > Michael Hudson wrote:
> > > > I suppose this wouldn't happen if we programmed in latin.
> > >
> > > Romans, go home?
> >
> > "Romani eunt domum"?
>
> Now now now! Please write it down correctly on the wall one
> godzillion times. :)

What's a godzillion in Roman numerals?

Dorai Sitaram

unread,
Dec 3, 2002, 12:43:21 PM12/3/02
to
In article <vg2b13...@ccs.neu.edu>, Joe Marshall <j...@ccs.neu.edu> wrote:
>
>What's a godzillion in Roman numerals?

GODZILLION

Michael Hudson

unread,
Dec 3, 2002, 12:58:56 PM12/3/02
to
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

BZZT! You all lose a large pile of claiming-not-to-be-a-geek points.

Cheers,
M.
(who didn't expect a mention of latin to bring up monty python quotes,
oh no)

--
There are 'infinite' number of developed artifacts and one cannot
develop appreciation for them all. It would be all right to not
understand something, but it would be imbecilic to put judgements
on things one don't understand. -- Xah, comp.lang.lisp

Tim Lavoie

unread,
Dec 3, 2002, 1:13:09 PM12/3/02
to
>>>>> "Joe" == Joe Marshall <j...@ccs.neu.edu> writes:

Joe> What's a godzillion in Roman numerals?


Really, really long. Now for a challenge, try and write the number zero.

--
If you live to the age of a hundred you have it made because very few
people die past the age of a hundred.
-- George Burns

Paul Foley

unread,
Dec 3, 2002, 6:35:55 PM12/3/02
to
On 03 Dec 2002 16:01:36 +0100, Raymond Wiker wrote:

> Kenny Tilton <kti...@nyc.rr.com> writes:
>> Michael Hudson wrote:
>> > I suppose this wouldn't happen if we programmed in latin.
>>
>> Romans, go home?

> "Romani eunt domum"?

> --- or does that mean "People called Romans they go the house"?

It means "the Romans are going home".

Brian's version was "Romanes eunt domus"

--
Men are born ignorant, not stupid; they are made stupid by education.
-- Bertrand Russell
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))

Henrik Motakef

unread,
Dec 4, 2002, 1:53:48 AM12/4/02
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> Raymond Wiker <Raymon...@fast.no> writes:
>
> > Kenny Tilton <kti...@nyc.rr.com> writes:
> >
> > > Michael Hudson wrote:
> > > > I suppose this wouldn't happen if we programmed in latin.
> > >
> > > Romans, go home?
> >
> > "Romani eunt domum"?
>
> Now now now! Please write it down correctly on the wall one
> godzillion times. :)

Oh well. Python reference thread time again. I guess nobody expected
it.

Regards
Henrik

Donald Fisk

unread,
Dec 4, 2002, 6:45:21 PM12/4/02
to
Marco Antoniotti wrote:
>
> Raymond Wiker <Raymon...@fast.no> writes:
>
> > Kenny Tilton <kti...@nyc.rr.com> writes:
> >
> > > Michael Hudson wrote:
> > > > I suppose this wouldn't happen if we programmed in latin.
> > >
> > > Romans, go home?
> >
> > "Romani eunt domum"?
>
> Now now now! Please write it down correctly on the wall one
> godzillion times. :)

And so he should. It should be "Romani ite domum". Eunt is
3rd person plural subjunctive, whereas it should be imperative
plural:

(dotimes (i GODZILLION) (format t "Romani ite domum~%"))

Tsk! The youth of today.

> Marco Antoniotti

Kaz Kylheku

unread,
Dec 4, 2002, 6:41:46 PM12/4/02
to
Chris Gehlker <geh...@fastq.com> wrote in message news:<BA11F9F1.24000%geh...@fastq.com>...

> On 12/2/02 7:19 PM, in article
> cf333042.02120...@posting.google.com, "Kaz Kylheku"
> <k...@ashi.footprints.net> wrote:
>
> > You need to get some fact straight. Firstly, Ruby is a dumbed-down
> > imitation of Lisp with a bad syntax.
>
> That's just silly. Ruby is a dumbed-down imitation of *Smalltalk* with a bad
> syntax.

So what you are saying is that Smalltalk doesn't have bad syntax already.

Chris Gehlker

unread,
Dec 4, 2002, 8:48:06 PM12/4/02
to
On 12/4/02 4:41 PM, in article

> Chris Gehlker <geh...@fastq.com> wrote in message
> news:<BA11F9F1.24000%geh...@fastq.com>...
>> On 12/2/02 7:19 PM, in article
>> cf333042.02120...@posting.google.com, "Kaz Kylheku"
>> <k...@ashi.footprints.net> wrote:
>>
>>> You need to get some fact straight. Firstly, Ruby is a dumbed-down
>>> imitation of Lisp with a bad syntax.
>>
>> That's just silly. Ruby is a dumbed-down imitation of *Smalltalk* with a bad
>> syntax.
>
> So what you are saying is that Smalltalk doesn't have bad syntax already.

It's pretty funny when Lispers criticize *any* other language for it's
syntax. Well, maybe they can criticize Perl.

Kenny Tilton

unread,
Dec 4, 2002, 9:47:06 PM12/4/02
to

Chris Gehlker wrote:
> It's pretty funny when Lispers criticize *any* other language for it's
> syntax. Well, maybe they can criticize Perl.

What don't you like about Lisp's syntax? I don't know of anything better
or that even comes close. Maybe Prolog. Not that I know every language.
Just curious how Lisp comes in next-to-last in your book.

Thomas F. Burdick

unread,
Dec 4, 2002, 10:12:00 PM12/4/02
to
k...@ashi.footprints.net (Kaz Kylheku) writes:

If he isn't, I'll say it. I doesn't. It has more syntax than Lisp,
yes, but it's simple, striaghtforward, intuitive once you get a basic
feel for it, and it all fits on a sheet of A4 paper! No weird
precedence rules, and no statements: none of that bullshit.

Paul Foley

unread,
Dec 4, 2002, 10:30:26 PM12/4/02
to
On Wed, 04 Dec 2002 23:45:21 +0000, Donald Fisk wrote:

> Marco Antoniotti wrote:
>>
>> Raymond Wiker <Raymon...@fast.no> writes:
>>
>> > Kenny Tilton <kti...@nyc.rr.com> writes:
>> >
>> > > Michael Hudson wrote:
>> > > > I suppose this wouldn't happen if we programmed in latin.
>> > >
>> > > Romans, go home?
>> >
>> > "Romani eunt domum"?
>>
>> Now now now! Please write it down correctly on the wall one
>> godzillion times. :)

> And so he should. It should be "Romani ite domum". Eunt is
> 3rd person plural subjunctive, whereas it should be imperative
> plural:

Eunt is indicative, not subjunctive.

[The subjunctive works though: "Romani eant domum" means pretty much
the same as "Romani ite domum"]


In case you missed it, this is a reference to a scene in Monty
Python's Life of Brian in which Brian sneaks out at night to write
"Romanes eunt domus" on a wall; one of the Roman soldiers catches him
at it, gives him a grammar lesson [though he tells him "domum" is
locative case, which it's not...] and has him write out the corrected
form ("Romani ite domum") a hundred times.

Frank A. Adrian

unread,
Dec 4, 2002, 10:53:41 PM12/4/02
to
Kaz Kylheku wrote:

> So what you are saying is that Smalltalk doesn't have bad syntax already.

Its syntax is better than Ruby's, worse than Lisp's...

faa

Kenny Tilton

unread,
Dec 5, 2002, 12:50:19 AM12/5/02
to

Paul Foley wrote:
> On Wed, 04 Dec 2002 23:45:21 +0000, Donald Fisk wrote:
>
>
>>Marco Antoniotti wrote:
>>
>>>Raymond Wiker <Raymon...@fast.no> writes:
>>>
>>>
>>>>Kenny Tilton <kti...@nyc.rr.com> writes:
>>>>
>>>>
>>>>>Michael Hudson wrote:
>>>>>
>>>>>>I suppose this wouldn't happen if we programmed in latin.
>>>>>
>>>>>Romans, go home?
>>>>
>>>> "Romani eunt domum"?
>>>
>>>Now now now! Please write it down correctly on the wall one
>>>godzillion times. :)
>>
>
>>And so he should. It should be "Romani ite domum". Eunt is
>>3rd person plural subjunctive, whereas it should be imperative
>>plural:
>
>
> Eunt is indicative, not subjunctive.
>
> [The subjunctive works though: "Romani eant domum" means pretty much
> the same as "Romani ite domum"]
>

Oh, Christ, now I have no choice but to boot up the damn movie and get
the straight dope from Cleese.

Chris Gehlker

unread,
Dec 5, 2002, 2:10:09 AM12/5/02
to
On 12/4/02 7:47 PM, in article 3DEEBF25...@nyc.rr.com, "Kenny Tilton"
<kti...@nyc.rr.com> wrote:

>
>
> Chris Gehlker wrote:
>> It's pretty funny when Lispers criticize *any* other language for it's
>> syntax. Well, maybe they can criticize Perl.
>
> What don't you like about Lisp's syntax? I don't know of anything better
> or that even comes close. Maybe Prolog. Not that I know every language.
> Just curious how Lisp comes in next-to-last in your book.

I'm not taking this too seriously because the whole subthread started with a
joke but note a couple of things about Lisp. It is the only language I know
of that needs a specialized set of layout rules to make it readable. Take a
Lisp program and put it in a normal text mode and it becomes gibberish.
Python is somewhat that way but one has considerable flexibility in
formatting Python before it becomes unreadable. Lisp needs the meta syntax
of something like ilisp to even be usable.

In his "History of Lisp" McCarthy says that he intended to clean up the
syntax before Lisp became a production language but it got out in the world.
I figure that if McCarthy wasn't happy with the syntax, it would be
presumptuous of me to like it.

Parens are hard to type.

Some frequently used operators have names left over from the assembler for a
defunct machine.

There's just too much off it. Most of the HyperSpec is just syntax. Compare
Smalltalk. It's entire syntax fits on a couple of pages.

Some frequently used operators, i.e. Do, require the user to put required
parameters in lists that are there just in case the user wanted to use
optional parameters. Others use a perfectly good keyword system. The keyword
system is nice and self documenting but this other, older?, method is
arbitrary.

The syntax for returning multiple values from a function and for receiving
them is awkward and inflexible.

There is no clue, other than sometimes the name, as to whether a function is
a reader or a setter.

In short, Lisp has a reputation for being hard. Where did it get this
reputation? Hardly from its semantics. AFAICT, the semantics of Lisp are
clear and straightforward. It's just the syntax that is confusing.

If you don't believe me, and I don't really expect you to, compare any
random set of postings here with those on any of the big C++ groups. Look at
how many discussions here are about syntax, compared to those that are about
semantics. Compare the C++ discussion where there simply aren't syntactical
issues.

Am I saying that there is an inevitable trade-off between syntactic
complexity and semantic purity? I don't know. It's an interesting question,
though. I do believe that it takes a big language to write a small program
but most of the semantic muddiness of C++ seems to come from the part of the
language, generics, that strikes me as simply broken.

Matthew Danish

unread,
Dec 5, 2002, 3:22:37 AM12/5/02
to
On Thu, Dec 05, 2002 at 12:10:09AM -0700, Chris Gehlker wrote:
> I'm not taking this too seriously because the whole subthread started with a
> joke but note a couple of things about Lisp. It is the only language I know
> of that needs a specialized set of layout rules to make it readable. Take a
> Lisp program and put it in a normal text mode and it becomes gibberish.
> Python is somewhat that way but one has considerable flexibility in
> formatting Python before it becomes unreadable. Lisp needs the meta syntax
> of something like ilisp to even be usable.

Seeing that Python is probably one of the few languages that actually
enforces a layout style, your lack of imagination is sheerly incredible.
Perhaps you should browse the obfuscated code contests for a number of
languages to refresh your memory on how important formatting conventions
really are for any language--Lisp or other.

> In his "History of Lisp" McCarthy says that he intended to clean up the
> syntax before Lisp became a production language but it got out in the world.
> I figure that if McCarthy wasn't happy with the syntax, it would be
> presumptuous of me to like it.

The reason why he never ``cleaned up the syntax'' is because people
liked it as it was, and didn't want his crappy M-expressions.

> Parens are hard to type.

Then fix your keybindings. It is common to remap [] to ().

How people get by typing crap like !@#$%^&*{} all day is beyond me.

> Some frequently used operators have names left over from the assembler for a
> defunct machine.

This I don't argue but on the other hand, I haven't been able to think
of a better name for CAR and CDR that fully expresses what they are; and
neither has generations of language designers apparently. All I've seen
are HD/HEAD and TL/TAIL, FST and SND, and none of these really expresses
what a CONS cell is, or what its CAR and CDR are.

I would also say that the vast majority of functions have more
descriptive names, it is just the old core of traditional ones that do
not. There seems to be a tendency in the Lisp community these days to
use more descriptive names over short cryptic ones.

> There's just too much off it. Most of the HyperSpec is just syntax. Compare
> Smalltalk. It's entire syntax fits on a couple of pages.

When your language permits syntactic abstraction then syntax becomes
part of the interface definition. Shall we throw out macros and
complex-lambda-lists, then, and lose all benefits from them? Just so we
can squeeze every possible way of thinking into a single syntax?
(*cough*Java)

But if you think most of the Hyperspec is ``just syntax'' then you
probably haven't understood any of it. Or Lisp syntax, for that matter.

> Some frequently used operators, i.e. Do, require the user to put required
> parameters in lists that are there just in case the user wanted to use
> optional parameters. Others use a perfectly good keyword system. The keyword
> system is nice and self documenting but this other, older?, method is
> arbitrary.

I don't see what you're saying about DO in particular. How else do you
plan to disambiguate the variable-stepping-forms, the
termination-test-form and the body?

(do (variable-stepping-forms*)
termination-test-form
body-forms*)

> The syntax for returning multiple values from a function and for receiving
> them is awkward and inflexible.

I agree that the name MULTIPLE-VALUE-BIND is annoyingly long, but that's
what name-completion is for. I don't see how you can claim it is
inflexible though.

Try doing (multiple-value-bind (a b) 1 ...) in SML.

> There is no clue, other than sometimes the name, as to whether a function is
> a reader or a setter.

This is why SETF was invented.

> In short, Lisp has a reputation for being hard. Where did it get this
> reputation? Hardly from its semantics. AFAICT, the semantics of Lisp are
> clear and straightforward. It's just the syntax that is confusing.

The syntax is only confusing to someone who cannot grasp nested
expressions. I would say that someone cannot grasp nested expressions
cannot grasp higher-level abstractions and thus cannot be an effective
programmer anyway. Learning Lisp forces you to deal with higher-level
abstractions, and thus you learn to become a better programmer.

> If you don't believe me, and I don't really expect you to, compare any
> random set of postings here with those on any of the big C++ groups. Look at
> how many discussions here are about syntax, compared to those that are about
> semantics. Compare the C++ discussion where there simply aren't syntactical
> issues.

Because they are stuck with a single syntax, for better or (more likely)
worse? Whereas Lispers can mold the syntax to their own purposes, so of
course that becomes a point of discussion.

If you don't believe me, and I don't really expect you to, compare any

random set of discussions here [1] with those in any of the major
totalitarianistic countries. Look at how many discussions here are
about government, compared to those that are about farming. Compare the
totalitarianistic country where there simply aren't governmental issues
[to discuss].

[1] Where ``here'' would presumably be a democratic country.

> Am I saying that there is an inevitable trade-off between syntactic
> complexity and semantic purity? I don't know. It's an interesting question,
> though. I do believe that it takes a big language to write a small program
> but most of the semantic muddiness of C++ seems to come from the part of the
> language, generics, that strikes me as simply broken.

Show me how C++ can simply and easily express the semantics of the
syntactic construct WITH-OPEN-FILE the way that Lisp does.

Then, while you are performing this daredevil feat, explain to me that
allowing syntactic abstraction is a mistake.

--
; 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."

Frode Vatvedt Fjeld

unread,
Dec 5, 2002, 4:03:14 AM12/5/02
to
Chris Gehlker <geh...@fastq.com> writes:

> In his "History of Lisp" McCarthy says that he intended to clean up
> the syntax before Lisp became a production language but it got out
> in the world. I figure that if McCarthy wasn't happy with the
> syntax, it would be presumptuous of me to like it.

While this paragraph makes it clear that you're talking about LISP 1.5
or something of that era, most of your other remarks still reveal that
you are quite ill-informed about lisp in general.

> [..] The syntax for returning multiple values from a function and


> for receiving them is awkward and inflexible.

I didn't know that old lisps had multiple values, so presumably this
is CL you're talking about. I'm very intrigued to know what is awkward
about Common Lisp's multiple values. Really. How would it be better,
according to you? I don't know any language where this is designed
more elegantly. Are you missing C's "flexibility" of having to pass
pointers to variables to hold extra values? Or the wonderfullness of
receiving errno in a global variable? Or Python's pathetic attempt at
simulating multiple values?

> There is no clue, other than sometimes the name, as to whether a
> function is a reader or a setter.

Look at the two function names "foo" and "(setf foo)". Make a guess as
to which is a reader and which is a setter. I don't know any language
that provides a better mechanism for clues in this regard.

--
Frode Vatvedt Fjeld, baittaker.

Coby Beck

unread,
Dec 5, 2002, 5:30:07 AM12/5/02
to

"Chris Gehlker" <geh...@fastq.com> wrote in message
news:BA1449E1.2408D%geh...@fastq.com...

> On 12/4/02 7:47 PM, in article 3DEEBF25...@nyc.rr.com, "Kenny Tilton"
> <kti...@nyc.rr.com> wrote:
>
> >
> >
> > Chris Gehlker wrote:
> >> It's pretty funny when Lispers criticize *any* other language for it's
> >> syntax. Well, maybe they can criticize Perl.
> >
> > What don't you like about Lisp's syntax? I don't know of anything better
> > or that even comes close. Maybe Prolog. Not that I know every language.
> > Just curious how Lisp comes in next-to-last in your book.
>
> I'm not taking this too seriously because the whole subthread started with
a
> joke

Just wait and see how funny it gets! ;-)

> but note a couple of things about Lisp. It is the only language I know
> of that needs a specialized set of layout rules to make it readable.

Aside from "indent" and "don't be an idiot" what rules do you mean?

If you want to convince me of this point you'll have to show me some
examples of what you mean. Just to take C as a common language target, I
think it quickly gets very obfuscated if you put your {}'s in unusual
places, if you put multiple statements on one line and if you don't indent
properly. How about deeply nested expressions in C? There is a reason no
one does it. Plus, I don't know any language that is still readable if you
screw up the indentation (I don't know that many languages though)

> Take a
> Lisp program and put it in a normal text mode and it becomes gibberish.
> Python is somewhat that way but one has considerable flexibility in
> formatting Python before it becomes unreadable. Lisp needs the meta syntax
> of something like ilisp to even be usable.

Lisp just needs one more level of indentation per extra level of nesting.
What else?

>
> In his "History of Lisp" McCarthy says that he intended to clean up the
> syntax before Lisp became a production language but it got out in the
world.
> I figure that if McCarthy wasn't happy with the syntax, it would be
> presumptuous of me to like it.
>
> Parens are hard to type.

So is % && || != ++ { } $ @ etc... You really want to make noise about two
characters?

>
> Some frequently used operators have names left over from the assembler for
a
> defunct machine.

I assume you mean CAR and CDR and I agree they are quirky. Why not use
FIRST and REST?

>
> There's just too much off it. Most of the HyperSpec is just syntax.

I honestly don't know what you mean...I probably have a different
understanding of "syntax"

> Some frequently used operators, i.e. Do, require the user to put required
> parameters in lists that are there just in case the user wanted to use
> optional parameters. Others use a perfectly good keyword system. The
keyword
> system is nice and self documenting but this other, older?, method is
> arbitrary.

I never use DO and because of that find it hard to read. Just use LOOP,
DOLIST, MAPCAR...

>
> The syntax for returning multiple values from a function and for receiving
> them is awkward and inflexible.

How do you mean? A little akward, I guess, but it is a special thing to do
and not that common. Do you have a suggested improvement?

I'm not trying to be argumentative, I just have such different impressions
than you do and it makes me curious.

--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")


Alain Picard

unread,
Dec 5, 2002, 5:24:22 AM12/5/02
to
Chris Gehlker <geh...@fastq.com> writes:

Maybe this is some elaborate joke I'm not seeing and
I'm being pulled in, but, nevertheless:

> a couple of things about Lisp. It is the only language I know
> of that needs a specialized set of layout rules to make it readable.

I wonder how you explain the heated religious arguments
about "the one true brace style" in the C groups, then.

> Parens are hard to type.

Keyboards can be remapped.

> There's just too much off it. Most of the HyperSpec is just syntax. Compare
> Smalltalk. It's entire syntax fits on a couple of pages.

How's this: Paren + operation + arguments* + Paren.

The Hyperspec is about the _semantics_ of each operation/special form.
Perhaps you don't really know what the word "syntax" means, in the context
of a computer language?

> In short, Lisp has a reputation for being hard.

It has a reputation for not being a language for dummies. I haven't
seen any "Lisp in 21 days" books yet. (Should I write one? ;-)

> Where did it get this reputation? Hardly from its semantics. AFAICT,
> the semantics of Lisp are clear and straightforward. It's just the
> syntax that is confusing.

What can I say? I, and I suspect 99% of lisp programmers, never
have _any_ problems whatsoever with syntax. Now
*(foo*)p->blah++; /* what the hell does _that_ mean??? */

> If you don't believe me, and I don't really expect you to, compare any
> random set of postings here with those on any of the big C++ groups. Look at
> how many discussions here are about syntax, compared to those that are about
> semantics. Compare the C++ discussion where there simply aren't syntactical
> issues.

You're right; I don't believe you.
I've ready c.l.l for about 5 years now, and I don't recall a single
thread about difficult syntax. In fact, a google search on the
words "difficult" and "syntax" in c.l.l. didn't return any relevant hits.
The only one that seemed to come close was this
Message-ID: <5edf2d$8...@Masala.CC.UH.EDU>
and it's 5 years old. Perhaps you could point me to some messages I
could look up.


In summary, Most lispers know that Lisp's crystal clear (and almost
non-existent) syntax is one of the features which make it so powerful
(via the macro system).


Pascal Costanza

unread,
Dec 5, 2002, 5:43:18 AM12/5/02
to
Chris Gehlker wrote:
> On 12/4/02 7:47 PM, in article 3DEEBF25...@nyc.rr.com, "Kenny Tilton"
> <kti...@nyc.rr.com> wrote:

>>What don't you like about Lisp's syntax? I don't know of anything better
>>or that even comes close. Maybe Prolog. Not that I know every language.
>>Just curious how Lisp comes in next-to-last in your book.
>
>
> I'm not taking this too seriously because the whole subthread started with a
> joke but note a couple of things about Lisp. It is the only language I know
> of that needs a specialized set of layout rules to make it readable. Take a
> Lisp program and put it in a normal text mode and it becomes gibberish.
> Python is somewhat that way but one has considerable flexibility in
> formatting Python before it becomes unreadable. Lisp needs the meta syntax
> of something like ilisp to even be usable.

if (yourLanguageIsJava)
System.out.println("You can have nasty errors,");
System.out.println("just because of the syntax");

> In his "History of Lisp" McCarthy says that he intended to clean up the
> syntax before Lisp became a production language but it got out in the world.
> I figure that if McCarthy wasn't happy with the syntax, it would be
> presumptuous of me to like it.

Hint: I guess the inventor of chess wasn't a good chess player.

> Some frequently used operators have names left over from the assembler for a
> defunct machine.

However, they are easy to learn and remember. car and cdr line up well
because they both have three letters. My memory hook is that the "a"
indicates "first element" and the "d" indicates "not the second (b), not
the third (c), but somewhere in the rest of the alphabet". (You know, I
can only count to three. ;-)

And then you can do nice things with combinations of these operators,
like cadr, cdar, cadar, and so on. Some people don't like it, but I
think these are quite useful in exploratory programming mode.

> There's just too much off it. Most of the HyperSpec is just syntax. Compare
> Smalltalk. It's entire syntax fits on a couple of pages.

Huh? The syntax is as simple as can be: Everything is an s-expression,
and the first element of a list determines the meaning of that list.
That's it!

> In short, Lisp has a reputation for being hard. Where did it get this
> reputation? Hardly from its semantics. AFAICT, the semantics of Lisp are
> clear and straightforward. It's just the syntax that is confusing.

...but the syntax and the semantics of Lisp are closely coupled... ?!?


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)

Erik Naggum

unread,
Dec 5, 2002, 5:48:50 AM12/5/02
to
* Chris Gehlker

| If you don't believe me,

On Usenet, nobody /believes/ anybody. Grasping this is /crucial/.

--
Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.

Rob Warnock

unread,
Dec 5, 2002, 6:30:18 AM12/5/02
to
Alain Picard <apicard+die...@optushome.com.au> wrote:
+---------------

| I haven't seen any "Lisp in 21 days" books yet. (Should I write one? ;-)
+---------------

Maybe a (small) group should get together and just translate (if we can
get his permission) Dorai Sitaram's "Teach Yourself Scheme in Fixnum Days"
<URL:http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html> into
Common Lisp syntax and idioms. It would need some work to add special
variables (though it already covers FLUID-LET), the chapter on macros
would be significantly different, and the continuation (call/cc etc.)
stuff would have to be converted to talking about exceptions/conditions
and threads (e.g., the "engines" stuff). On the other hand, the presentations
of some topics would even be simpler (e.g., a lot of the development in
the chapter on "Alists & Tables" could be simplified by changing it to
"Alists & Hash Tables").

All in all I think it'd be a good template to work from.


-Rob

-----
Rob Warnock, PP-ASEL-IA <rp...@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607

Mark Dalgarno

unread,
Dec 5, 2002, 6:20:15 AM12/5/02
to
Alain Picard <apicard+die...@optushome.com.au> writes:

> Chris Gehlker <geh...@fastq.com> writes:

> > Parens are hard to type.
>
> Keyboards can be remapped.

OT but Symbolics keyboards had a layout with some optimisation for
frequently-used Lisp characters e.g. : had its own key.

Chekout the picture at
http://www.abstractscience.freeserve.co.uk/symbolics/photos/IO/.

The : key is near the top-left. ( and ) are to the right of P.

Mark

Kenny Tilton

unread,
Dec 5, 2002, 7:44:20 AM12/5/02
to

Chris Gehlker wrote:
> It is the only language I know
> of that needs a specialized set of layout rules to make it readable.

Hunh? I think 6502 assembler is the only language I've used which did
/not/ require me to indent things just so to make it bearable to look at.

> I figure that if McCarthy wasn't happy with the syntax, it would be
> presumptuous of me to like it.

<g>

> Parens are hard to type.

<g>

> Some frequently used operators have names left over from the assembler for a
> defunct machine.

I /love/ the sense of history I get from using car and cdr.

>
> There's just too much off it. Most of the HyperSpec is just syntax.

Really? i thought it was just a long list of functions, macros, and
special forms. I am still discovering new ones, I guess because I rarely
look at OPC.

> Compare
> Smalltalk. It's entire syntax fits on a couple of pages.

Lisp: (operator [argments]*)

> The syntax for returning multiple values from a function and for receiving
> them is awkward and inflexible.

(values 1 2)? You're pulling our legs, right? :)

> If you don't believe me, and I don't really expect you to, compare any
> random set of postings here with those on any of the big C++ groups.

Ah, C++. I think I actually started laughing as I read Stroustup's (sp?)
annotated C++ and saw the syntax for declaring a function to be a pure
virtual one:

pvfunc = 0;

I think that is also where I put the book down, the language, too.

> Am I saying that there is an inevitable trade-off between syntactic
> complexity and semantic purity?

Ya got it backwards. Without Lisps syntactic simplicity, ya can't get to
complexity.

Brave answer you posted, btw. Thx, things were getting a little sleepy
around here.

:)

Chris Gehlker

unread,
Dec 5, 2002, 9:50:12 AM12/5/02
to
On 12/5/02 5:44 AM, in article 3DEF4B21...@nyc.rr.com, "Kenny Tilton"
<kti...@nyc.rr.com> wrote:

> Brave answer you posted, btw. Thx, things were getting a little sleepy
> around here.

Thanks Kenny. You sort of baited me into it so I'm going to use my reply to
you to summarize my response to the thread so far:

To those who think that the persuasiveness of their argument is somehow
proportional to the vehemence with which they express it, I would point out
that the converse is, in fact, true.

To those who offered various work-arounds for what I asserted were problems
with Lisp's syntax, I would argue that the utility of the work-arounds
demonstrates the existence of the problems.

To the many who said that they find Lisp syntax very simple and elegant
because the proper place to draw the line between syntax and semantics in
Lisp is at the boundary of the S-expression, I would say you win, mostly. If
that's the proper place to draw the line, then Lisp is almost syntax free
and we are discussing nothing. The reason that your argument doesn't prevail
completely is that S-expressions can be trees of arbitrary complexity and it
seems that some of that complexity was elaborated in the language before
the 'optional parameters are keyword parameters rule' came into play. So
there is some cruft even in this trivial syntax.

To those who said, in some form or other, "The fact that you criticize
Lisp's syntax merely demonstrates that you don't understand it. When you do
understand it, you will recognize it as a thing of power and beauty." I
would say:

I'm inclined to believe you. But if everything you say is true, then Lispers
look more rather than less ridiculous when they criticize the syntax of
other languages to users of those languages.

Finally, to those who say "That's my dog and I love her. She saved my family
when my house caught fire. How dare you point out that spot of mange?" I
would say:

Blame Kenny! He made me do it!

Frode Vatvedt Fjeld

unread,
Dec 5, 2002, 10:02:28 AM12/5/02
to
Chris Gehlker <geh...@fastq.com> writes:

> I'm inclined to believe you. But if everything you say is true, then
> Lispers look more rather than less ridiculous when they criticize
> the syntax of other languages to users of those languages.

Why would you assume that anyone who knows lisp doesn't know whatever
other language he's criticizing?

--
Frode Vatvedt Fjeld

Joe Marshall

unread,
Dec 5, 2002, 10:24:54 AM12/5/02
to
Chris Gehlker <geh...@fastq.com> writes:

> It's pretty funny when Lispers criticize *any* other language for it's
> syntax. Well, maybe they can criticize Perl.

Lispers are entitled to criticise *all* other languages for their
syntax.

Kenny Tilton

unread,
Dec 5, 2002, 10:40:59 AM12/5/02
to

Chris Gehlker wrote:
> To the many who said that they find Lisp syntax very simple and elegant
> because the proper place to draw the line between syntax and semantics in

> Lisp is at the boundary of the S-expression...


yes. i think we may mean different things by "syntax". to me syntax gets
weird with extraneous little bits of ad hoc notation, as in the C++
example of "= 0" meaning "pure virtual function. Or in Python, where [1,
2, 3] is a list and [1,2,3,] is a tuple. But to you...


> The reason that your argument doesn't prevail

> completely is that S-expressions can be trees of arbitrary complexity ...

Here I think you are just talking about the readability of a large
quantity of nested expressions, each of which enjoys the same, simple
syntax. That does not make the /syntax/ a problem, that just means the
coder possibly needs to break things up into smaller chunks.

which is not to say a large wadge of code properly formatted cannot be
easily understood. if it is otherwise good code, there is a /lot/ going
on in a large wadge of code. if i am reading it, i probably can break it
down top-down and quickly find the bit i am concerned with.

anyway, this to me is not syntax.

> I'm inclined to believe you. But if everything you say is true, then Lispers
> look more rather than less ridiculous when they criticize the syntax of
> other languages to users of those languages.

To know them is to love them? Nah, the more Python I did the less I
liked it. Mind you, the code /looks/ incredibly clean. But the price one
pays for that is too high.

> Blame Kenny! He made me do it!

I thought I was setting a trap you would easily elude, you kinda dove
into it whooping and hollering. :)

Espen Vestre

unread,
Dec 5, 2002, 10:49:50 AM12/5/02
to
Joe Marshall <j...@ccs.neu.edu> writes:

> > It's pretty funny when Lispers criticize *any* other language for it's
> > syntax. Well, maybe they can criticize Perl.
>
> Lispers are entitled to criticise *all* other languages for their
> syntax.

In fact, lately, while helping my son with mathematics, I'm starting
to wonder if it would be better to teach schoolchildren lisp syntax
rather than standard math syntax. When confronted with complex alge-
braic expressions, children/teenagers often get confused and aren't at
all able to apply all the precedence rules and come up with the
correct parse. It would be interesting to see if young people would
grasp algebra faster if they were taught s-expression-like algebra and
could use their brain to do math instead of doing hard parsing :-)
(and one obvious bonus would be that they would have to learn the
concept of a _function_ at a very early stage, and that they would
know that the basic arithmetic operators (*, +, ...) are functions
(this is pretty hard to understand when you have been brainwashed for
years that they are "reserved words"!)
--
(espen)

Joe Marshall

unread,
Dec 5, 2002, 10:54:21 AM12/5/02
to
Chris Gehlker <geh...@fastq.com> writes:

> I'm not taking this too seriously because the whole subthread started with a
> joke but note a couple of things about Lisp. It is the only language I know
> of that needs a specialized set of layout rules to make it readable. Take a
> Lisp program and put it in a normal text mode and it becomes gibberish.

This is true of *any* block-structured language.

> Python is somewhat that way but one has considerable flexibility in
> formatting Python before it becomes unreadable.

This is less true. Python is whitespace dependent, so hitting M-Q on
a Python program will not only make it unreadable, it will make it
unrunnable.

> Parens are hard to type.

The amount of pressure to depress a paren key is not significantly
different from other key.

> Some frequently used operators have names left over from the assembler for a
> defunct machine.

That's not syntax.


> There's just too much of it. Most of the HyperSpec is just syntax.


> Compare Smalltalk. It's entire syntax fits on a couple of pages.

( operator argument ... ) <= one line

There is some `micro-syntax' involving strings, numbers, symbols, etc.
But the syntax of Lisp is fairly minimal, especially when compared to
popular languages such as Java, C, C++, Perl, PHP, VB, Javascript,
etc.

> The syntax for returning multiple values from a function and for receiving
> them is awkward and inflexible.

(values ....) can't get much simpler than that.

As for flexibility, the common case of getting multiple values when
only one is needed doesn't need any syntax at all.

> If you don't believe me, and I don't really expect you to, compare any
> random set of postings here with those on any of the big C++ groups. Look at
> how many discussions here are about syntax, compared to those that are about
> semantics. Compare the C++ discussion where there simply aren't syntactical
> issues.

I don't believe you. Look on the web and find how many programs that
can correctly parse the full C++ language (produce an abstract syntax
tree from a text source). Producing an abstract syntax tree from Lisp
code is trivial.

Chris Gehlker

unread,
Dec 5, 2002, 11:04:17 AM12/5/02
to
On 12/5/02 8:02 AM, in article 2h1y4wz...@vserver.cs.uit.no, "Frode
Vatvedt Fjeld" <fro...@cs.uit.no> wrote:

I didn't. My point was that the Lisper presumably knows that it takes some
study to understand the virtues of Lisp syntax. That was the assertion of
several Lispers on this thread. The person he is ostensibly addressing
doesn't have this knowledge but has seen Lisp code and knows its reputation
for being obscure. So the Lisper is talking to herself in public and
ignoring the requirements of the audience. It is this behavior that I find
ludicrous. It's not less silly if the person is really talking to the inner
circle, hoping to gain their approval, while superficially addressing a
newbie.

On many lists such behavior is called wanking or whoring, respectively. It
seems to be more tolerated here. I guess I understand that. It's certainly
excusable if indeed people who are more expressive in Lisp are being forced
by PHBs to use something else.

Jacek Generowicz

unread,
Dec 5, 2002, 11:03:10 AM12/5/02
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> to me syntax gets weird with extraneous little bits of ad hoc

> notation, as in [...] Python, where [1, 2, 3] is a list and [1,2,3,]
> is a tuple.

Bzzzt, Kenny!

The tuple would be (1,2,3).

If you're gonna pick on weirdness, at least pick correctly :-)

(1,2,3) is a tuple
(1,2) is a tuple
(1) is the number 1
(1,) is a tuple.

(You can stay consistent by writing _all_ tuples (and lists) with
trailing commas)

IIRC, this changed in some 2.X release.

Dave Pearson

unread,
Dec 5, 2002, 11:34:58 AM12/5/02
to
* Kenny Tilton <kti...@nyc.rr.com>:

> [SNIP] Or in Python, where [1,


> 2, 3] is a list and [1,2,3,] is a tuple. But to you...

Aren't you thinking of how (1) and (1,) are different in python? I'm no
python expert, far from it, but my recollection is that [1,2,3] and [1,2,3,]
are no different.

,----
| >>> len( [1,2] )
| 2
| >>> len( [1,2,] )
| 2
| >>> len( (1) )
| Traceback (innermost last):
| File "<stdin>", line 1, in ?
| TypeError: len() of unsized object
| >>> len( (1,) )
| 1
`----

--
Dave Pearson: | lbdb.el - LBDB interface.
http://www.davep.org/ | sawfish.el - Sawfish mode.
Emacs: | uptimes.el - Record emacs uptimes.
http://www.davep.org/emacs/ | quickurl.el - Recall lists of URLs.

Frode Vatvedt Fjeld

unread,
Dec 5, 2002, 11:39:08 AM12/5/02
to
Chris Gehlker <geh...@fastq.com> writes:

> [..] On many lists such behavior is called wanking or whoring,


> respectively. It seems to be more tolerated here. I guess I
> understand that. It's certainly excusable if indeed people who are
> more expressive in Lisp are being forced by PHBs to use something
> else.

What are you on? This is just about worst, most offensive attitude
I've ever seen from any newbie seeking help in a forum.

I asked you why you found lisp's multiple values hard to use. That's
an offer to help you clear up misconceptions about it. Why not accept
that offer at face value, rather than construing malice and throwing
it back as embarrassing insults like this?

--
Frode Vatvedt Fjeld

Harald Hanche-Olsen

unread,
Dec 5, 2002, 11:41:54 AM12/5/02
to
+ Espen Vestre <espen@*do-not-spam-me*.vestre.net>:

| In fact, lately, while helping my son with mathematics, I'm starting
| to wonder if it would be better to teach schoolchildren lisp syntax
| rather than standard math syntax.

And teach them rules like

(= (* a (+ b c))
(+ (* a b) (* a c)))

and

(= (expt (+ a b) 2)
(+ (expt a 2) (* 2 a b) (expt b 2)))

?

| When confronted with complex algebraic expressions, children/


| teenagers often get confused and aren't at all able to apply all the
| precedence rules and come up with the correct parse.

True, but parsing a formula is a very small part of doing algebra.
Mathematical notation as we know it does a pretty good job at being
sufficiently succinct and easily manipulated, and I for one shudder at
the thought of even such a simple chore as completing a square in such
notation. Besides, we would eventually have to teach the conventional
way either, or they would suddenly find a vast literature being
inaccessible to them.

I think that calculators using algebraic notation with parentheses
should take some of the blame. When calculating an expression either
by hand or using an RPN calculator, you're forced to start at the
bottom of the parse tree and work your way up, and that ought to teach
you the parsing rules pretty fast.

| (and one obvious bonus would be that they would have to learn the
| concept of a _function_ at a very early stage, and that they would
| know that the basic arithmetic operators (*, +, ...) are functions
| (this is pretty hard to understand when you have been brainwashed
| for years that they are "reserved words"!)

The mathematical function concept seems remarkably hard to grasp,
whether or not you include these. It seems most students end up
believing that the graph /is/ the function (at a deeper level they're
right, of course), or that the formula defining the function /is/ the
function (wrong), or both of the above (worse). But, perhaps a bit
more to the point, they have been brainwashed into thinking that
functions take just one (real) argument and so have great difficulty
when confronted with functions of two real arguments, or the notion
that a sequence is just a function over the natural numbers. However,
I am not really convinced that it pays to introduce such notions at a
too early stage. But if they were to learn a little bit of
programming, they would at least learn of functions as they are
defined and used in programming, and that might well pave the way for
better understanding of mathematical concepts later on.

--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?

Pascal Costanza

unread,
Dec 5, 2002, 12:06:20 PM12/5/02
to
Chris Gehlker wrote:


> To those who offered various work-arounds for what I asserted were problems
> with Lisp's syntax, I would argue that the utility of the work-arounds
> demonstrates the existence of the problems.
>
> To the many who said that they find Lisp syntax very simple and elegant
> because the proper place to draw the line between syntax and semantics in
> Lisp is at the boundary of the S-expression, I would say you win, mostly. If
> that's the proper place to draw the line, then Lisp is almost syntax free
> and we are discussing nothing. The reason that your argument doesn't prevail
> completely is that S-expressions can be trees of arbitrary complexity and it
> seems that some of that complexity was elaborated in the language before
> the 'optional parameters are keyword parameters rule' came into play. So
> there is some cruft even in this trivial syntax.

Please keep in mind that compilers/interpreters of all programming
languages have to translate the surface syntax into some intermediate
representation, an abstract syntax tree. You could claim as well that
the surface syntaxes of non-Lisp languages are mainly workarounds for
things that are hard to express directly in abstract syntax trees.
Lisp's syntax is outstanding in that it more or less directly represents
its abstract syntax trees. So yes, it's a correct conclusion to say that
Lisp is almost syntax free - that's one of Lisp's most important
features (if not _the_ most important feature).

> To those who said, in some form or other, "The fact that you criticize
> Lisp's syntax merely demonstrates that you don't understand it. When you do
> understand it, you will recognize it as a thing of power and beauty." I
> would say:
>
> I'm inclined to believe you. But if everything you say is true, then Lispers
> look more rather than less ridiculous when they criticize the syntax of
> other languages to users of those languages.

You seem to think that syntax is a purely aesthetic and superficial
element of a programming language, and everything that improves the
readability of the syntax of a language is an advantage per se, because
it doesn't break the language. However, in Lisp the lack of syntax is
the root of a high level of expressiveness that would be damaged by a
purportedly improved syntax. To better understand this you should read
http://www.paulgraham.com/rootsoflisp.html and perhaps
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-453.pdf

When Lispers criticize the syntax of other languages it's mainly because
they have seen the light ;) , and know that any syntax that is superior
to s-expressions on a superficial level would severely violate the far
more important expressive power of Lisp.

Kenny Tilton

unread,
Dec 5, 2002, 12:07:48 PM12/5/02
to

Jacek Generowicz wrote:
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
>
>>to me syntax gets weird with extraneous little bits of ad hoc
>>notation, as in [...] Python, where [1, 2, 3] is a list and [1,2,3,]
>>is a tuple.
>
>
> Bzzzt, Kenny!
>
> The tuple would be (1,2,3).

ah. so what the hell is the trailing comma? i guess i did not get far
enough to get disabused of my theory. Python OK, PyCells were coming
along nicely, but comp.lang.python was too touchy-feely for me so I
dumped the language.

Chris Gehlker

unread,
Dec 5, 2002, 12:26:11 PM12/5/02
to
On 12/5/02 8:40 AM, in article 3DEF748...@nyc.rr.com, "Kenny Tilton"
<kti...@nyc.rr.com> wrote:

>
>
> Chris Gehlker wrote:
>> To the many who said that they find Lisp syntax very simple and elegant
>> because the proper place to draw the line between syntax and semantics in
>> Lisp is at the boundary of the S-expression...
>
>
> yes. i think we may mean different things by "syntax". to me syntax gets
> weird with extraneous little bits of ad hoc notation, as in the C++
> example of "= 0" meaning "pure virtual function. Or in Python, where [1,
> 2, 3] is a list and [1,2,3,] is a tuple. But to you...

My usage:
The semantics of a program are its meaning, what it is trying to do and how
it goes about it. The semantics of a language are those features which make
the semantics of programs apparent by separating them from implementation
details. Thus the semantics of C++ are the inheritance tree plus some
folklore like the rule that declaring a virtual destructor means that the
programmer intends that the class serve as a useful base for subclasses even
it is used concretely in the particular program where it appears.

To say that C++ has poor semantics is merely an abstract way of saying that
the program reveals some of it meaning in it's inheritance diagram but most
of the meaning is in the message flow diagram that the programmer is
encouraged to staple onto the source listing. To say that Lisp has good
semantics merely means that such extra linguistic crutches aren't needed.

Now my usage is admittedly vague compared to the bright line provided by the
boundary of the S-expression. The danger of the latter distinction, though,
is it may make the set of interesting things to say about Lisp syntax so
small that the distinction between syntax and semantics becomes useless.

>
>> The reason that your argument doesn't prevail
>> completely is that S-expressions can be trees of arbitrary complexity ...
>
> Here I think you are just talking about the readability of a large
> quantity of nested expressions, each of which enjoys the same, simple
> syntax. That does not make the /syntax/ a problem, that just means the
> coder possibly needs to break things up into smaller chunks.
>
> which is not to say a large wadge of code properly formatted cannot be
> easily understood. if it is otherwise good code, there is a /lot/ going
> on in a large wadge of code. if i am reading it, i probably can break it
> down top-down and quickly find the bit i am concerned with.
>
> anyway, this to me is not syntax.

My point was much more trivial. I don't even want to explicate unless you
are really curious.

>
>> I'm inclined to believe you. But if everything you say is true, then Lispers
>> look more rather than less ridiculous when they criticize the syntax of
>> other languages to users of those languages.
>
> To know them is to love them? Nah, the more Python I did the less I
> liked it. Mind you, the code /looks/ incredibly clean. But the price one
> pays for that is too high.

I had the same experience with Python. My point, which I perhaps expressed
too harshly to another poster, was that Lisp looks obscure to the
superficial observer. Lispers should remember that everyone starts as a
newbie.

>> Blame Kenny! He made me do it!
>
> I thought I was setting a trap you would easily elude, you kinda dove
> into it whooping and hollering. :)

What, you expect honesty and accountability on usenet? Having walked
willy-nilly into your elephant pit, I am trying desperately to shift
responsibility. I aspire to be a PHB myself someday.

sv0f

unread,
Dec 5, 2002, 1:09:42 PM12/5/02
to
In article <3DEF2DC6...@web.de>, Pascal Costanza <cost...@web.de> wrote:

>Chris Gehlker wrote:

>> Some frequently used operators have names left over from the assembler for a
>> defunct machine.
>
>However, they are easy to learn and remember. car and cdr line up well
>because they both have three letters. My memory hook is that the "a"
>indicates "first element" and the "d" indicates "not the second (b), not
>the third (c), but somewhere in the rest of the alphabet". (You know, I
>can only count to three. ;-)
>
>And then you can do nice things with combinations of these operators,
>like cadr, cdar, cadar, and so on. Some people don't like it, but I
>think these are quite useful in exploratory programming mode.

Chris,

CAR and CDR are not just leftover cruft.

There are pragmatic reasons for their use, as Pascal nicely describes.

Many programmers also use them to express intent. For example, when I
see CAR and CDR, I assume a CONS data structure is being manipulated.
When I see the functionally-equivalent FIRST and REST used instead, I
assume a list data structure is in play. (You do know about FIRST and
REST, right?)

And, as Kenny wrote in a separate sub-thread, using CAR and CDR ties
you into the Lisp tradition, and this feels good. As Levi-Strauss,
the structuralist anthropologist once wrote:
We should not underestimate rites or their history. A society
can only maintain itself if its members are unconditionally
attached to its values. For this to occur, these values must
have a sensuous aspect that protects them against reasonšs
attempts to undermine them.

Chris, instead of laughing at the continued existence and usage of
CAR and CDR, you might ask yourself why Lispers keep them around,
even as other older constructions have been cast aside.

Chris Gehlker

unread,
Dec 5, 2002, 1:33:21 PM12/5/02
to
On 12/5/02 9:39 AM, in article 2hvg28x...@vserver.cs.uit.no, "Frode
Vatvedt Fjeld" <fro...@cs.uit.no> wrote:

This upset me so much that I went back and looked up the original message.
Here it is in its entirety:

> On 12/5/02 8:02 AM, in article 2h1y4wz...@vserver.cs.uit.no, "Frode
> Vatvedt Fjeld" <fro...@cs.uit.no> wrote:
>
>> Chris Gehlker <geh...@fastq.com> writes:
>>
>>> I'm inclined to believe you. But if everything you say is true, then
>>> Lispers look more rather than less ridiculous when they criticize
>>> the syntax of other languages to users of those languages.
>>
>> Why would you assume that anyone who knows lisp doesn't know whatever
>> other language he's criticizing?
>
> I didn't. My point was that the Lisper presumably knows that it takes some
> study to understand the virtues of Lisp syntax. That was the assertion of
> several Lispers on this thread. The person he is ostensibly addressing
> doesn't have this knowledge but has seen Lisp code and knows its reputation
> for being obscure. So the Lisper is talking to herself in public and
> ignoring the requirements of the audience. It is this behavior that I find
> ludicrous. It's not less silly if the person is really talking to the inner
> circle, hoping to gain their approval, while superficially addressing a
> newbie.
>

> On many lists such behavior is called wanking or whoring, respectively. It
> seems to be more tolerated here. I guess I understand that. It's certainly
> excusable if indeed people who are more expressive in Lisp are being forced
> by PHBs to use something else.
>

Do you see a personal attack in there? You asked me why I was making a
assumption about the knowledge of some hypothetical third party and I
explained. I honestly was not talking about you and I regret that you took
it that way. Please re-read the message, giving me a little bit of the
benefit of the doubt. If you still aren't satisfied, lets at lest take this
to private email.

As to the multiple values issue, you post was I heads-up that maybe I didn't
understand. I had believed that the the caller need to know both the number
and order of the values returned by the callee. After I read your post I did
some experimenting and discovered that the caller can ignore the tail of the
returned values but, AFAICT, can't ignore an intervening return without
generating a warning. And the mechanism does seem awkward compared to the
one line multiple assignment found in some languages. So, in short, you
already demonstrated that my understanding was incomplete and I simply
wanted to finish exploring on my own before responding.

Chris Gehlker

unread,
Dec 5, 2002, 2:43:38 PM12/5/02
to
On 12/5/02 10:06 AM, in article 3DEF878C...@web.de, "Pascal Costanza"
<cost...@web.de> wrote:


> Please keep in mind that compilers/interpreters of all programming
> languages have to translate the surface syntax into some intermediate
> representation, an abstract syntax tree. You could claim as well that
> the surface syntaxes of non-Lisp languages are mainly workarounds for
> things that are hard to express directly in abstract syntax trees.
> Lisp's syntax is outstanding in that it more or less directly represents
> its abstract syntax trees. So yes, it's a correct conclusion to say that
> Lisp is almost syntax free - that's one of Lisp's most important
> features (if not _the_ most important feature).

Agreed.

>
>> To those who said, in some form or other, "The fact that you criticize
>> Lisp's syntax merely demonstrates that you don't understand it. When you do
>> understand it, you will recognize it as a thing of power and beauty." I
>> would say:
>>
>> I'm inclined to believe you. But if everything you say is true, then Lispers
>> look more rather than less ridiculous when they criticize the syntax of
>> other languages to users of those languages.
>
> You seem to think that syntax is a purely aesthetic and superficial
> element of a programming language, and everything that improves the
> readability of the syntax of a language is an advantage per se, because
> it doesn't break the language. However, in Lisp the lack of syntax is
> the root of a high level of expressiveness that would be damaged by a
> purportedly improved syntax. To better understand this you should read
> http://www.paulgraham.com/rootsoflisp.html and perhaps
> ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-453.pdf
>

My remarks were much more superficial than that. They were addressed only to
the perceptions of lisp outsiders.

> When Lispers criticize the syntax of other languages it's mainly because
> they have seen the light ;) , and know that any syntax that is superior
> to s-expressions on a superficial level would severely violate the far
> more important expressive power of Lisp.

Which is precisely what Lispers *should* say. Even something like "all rules
of syntax tend to inhibit the expressive power of the language" informs the
listener that there are more important issues than superficial readability.
The problem with statements like "The syntax of language X sucks compared to
Lisp" is that it invites the hearer to look at a random glob of language X,
compare it to a random glob of Lisp, and respond "What the f*** are you
smoking?"

Chris Gehlker

unread,
Dec 5, 2002, 2:58:39 PM12/5/02
to
On 12/5/02 11:09 AM, in article none-05120...@129.59.212.53, "sv0f"
<no...@vanderbilt.edu> wrote:

> In article <3DEF2DC6...@web.de>, Pascal Costanza <cost...@web.de> wrote:
>
>> Chris Gehlker wrote:
>
>>> Some frequently used operators have names left over from the assembler for a
>>> defunct machine.
>>
>> However, they are easy to learn and remember. car and cdr line up well
>> because they both have three letters. My memory hook is that the "a"
>> indicates "first element" and the "d" indicates "not the second (b), not
>> the third (c), but somewhere in the rest of the alphabet". (You know, I
>> can only count to three. ;-)
>>
>> And then you can do nice things with combinations of these operators,
>> like cadr, cdar, cadar, and so on. Some people don't like it, but I
>> think these are quite useful in exploratory programming mode.
>
> Chris,
>
> CAR and CDR are not just leftover cruft.
>
> There are pragmatic reasons for their use, as Pascal nicely describes.
>
> Many programmers also use them to express intent. For example, when I
> see CAR and CDR, I assume a CONS data structure is being manipulated.
> When I see the functionally-equivalent FIRST and REST used instead, I
> assume a list data structure is in play. (You do know about FIRST and
> REST, right?)

I new they, FIRST and REST, existed but I didn't know anything about the
semantic significance of the distinction. That is very useful to know. Half
of learning any language is learning the folklore ( I think that's a
Stroustrup paraphrase) and this seems like a good place to do it.

> And, as Kenny wrote in a separate sub-thread, using CAR and CDR ties
> you into the Lisp tradition, and this feels good. As Levi-Strauss,
> the structuralist anthropologist once wrote:
> We should not underestimate rites or their history. A society
> can only maintain itself if its members are unconditionally
> attached to its values. For this to occur, these values must
> have a sensuous aspect that protects them against reasonšs
> attempts to undermine them.
>
> Chris, instead of laughing at the continued existence and usage of
> CAR and CDR, you might ask yourself why Lispers keep them around,
> even as other older constructions have been cast aside.

Kenny made me do it.

Pascal Costanza

unread,
Dec 5, 2002, 3:37:57 PM12/5/02
to

Good point.

Very recently, I have given this kind of reasoning in comp.lang.python,
and it seems to me that at least some people have got it. Based on that
experience I agree: Don't tell "them" that "their" stuff is worse and
"our" stuff is better, but explain the deeper reasons why "our" stuff is
the way it is. I think most people confronted with Lisp see its syntax
as a kind of historical accident at first, and based on this perception,
it's too tempting for them to come up with misguided suggestions for
improvement. It's only when they realize that the syntax is the way it
is because it allows one to represent both code and data equally well
that their mindset starts to change. (I have gone through these stages
as well.)


Pascal

--
Given any rule, however ‘fundamental’ or ‘necessary’ for science, there
are always circumstances when it is advisable not only to ignore the
rule, but to adopt its opposite. - Paul Feyerabend

Michael Hudson

unread,
Dec 5, 2002, 3:54:20 PM12/5/02
to
Harald Hanche-Olsen <han...@math.ntnu.no> writes:

> But if they were to learn a little bit of programming, they would at
> least learn of functions as they are defined and used in
> programming, and that might well pave the way for better
> understanding of mathematical concepts later on.

In (maths) tutorials this year, I've often wished I could use
programming examples to explain why (for a sets A and B say)

A \union B <=> (x \in A) \or (x \in B)

is nonsense.

"No! <=> takes /propositions/ on either side! What you've written is
like (/ 1 "bob")... Oh, never mind..."

Almost all mathematicians would benefit from knowing more programming.
Almost all programmers would benefit from knowing more mathematics.

Such is life.

Cheers,
M.

--
ROOSTA: Ever since you arrived on this planet last night you've
been going round telling people that you're Zaphod
Beeblebrox, but that they're not to tell anyone else.
-- The Hitch-Hikers Guide to the Galaxy, Episode 7

Duane Rettig

unread,
Dec 5, 2002, 4:00:01 PM12/5/02
to
Chris Gehlker <geh...@fastq.com> writes:

> As to the multiple values issue, you post was I heads-up that maybe I didn't
> understand. I had believed that the the caller need to know both the number
> and order of the values returned by the callee. After I read your post I did
> some experimenting and discovered that the caller can ignore the tail of the
> returned values but, AFAICT, can't ignore an intervening return without

===============================^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


> generating a warning. And the mechanism does seem awkward compared to the

==^^^^^^^^^^^^^^^^^^^^


> one line multiple assignment found in some languages. So, in short, you
> already demonstrated that my understanding was incomplete and I simply
> wanted to finish exploring on my own before responding.

I don't understand the flagged phrase. Please make this statement clear
with an example.

--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182

Espen Vestre

unread,
Dec 5, 2002, 4:03:08 PM12/5/02
to
Harald Hanche-Olsen <han...@math.ntnu.no> writes:

> And teach them rules like
>
> (= (* a (+ b c))
> (+ (* a b) (* a c)))

well, not really, I guess I was just thinking loud :-)

But still, I think there's something to it: Maybe learning a lisp-like
language at an early stage _in_addition_ to learning the standard
language of math could be helpful?

(Anyway, I think it's about time they stop the anti-new-math crusade that
has been going on for a couple of decades and bring some _logic_ back
in school again. But that's not a c.l.l. topic, and I'm just a biased
logic guy :-))
--
(espen)

Michael Hudson

unread,
Dec 5, 2002, 4:11:47 PM12/5/02
to
Espen Vestre <espen@*do-not-spam-me*.vestre.net> writes:

> (Anyway, I think it's about time they stop the anti-new-math crusade that
> has been going on for a couple of decades and bring some _logic_ back
> in school again. But that's not a c.l.l. topic, and I'm just a biased
> logic guy :-))

For a while, I've been pondering:

The population at large think scientists are a bit strange.
Scientists often think mathematicians are a bit odd.
Most mathematicians think pure maths is for oddballs.
Pure mathematicians think logic is weird. <-----------------.
|
Who do logicians think are the strange ones? |
|
Cheers, |
M. |
(who got as far as Skolem's "paradox" and joined this ------'
line)

--
Exam invigilation - it doesn't come much harder than that, esp if
the book you're reading turns out to be worse than expected.
-- Dirk Bruere, sci.physics.research

Espen Vestre

unread,
Dec 5, 2002, 5:04:40 PM12/5/02
to
Michael Hudson <m...@python.net> writes:

> Pure mathematicians think logic is weird. <-----------------.

Now this is certainly wrong. Logicians _are_ the purest of mathematicians,
after all, they are the ones which can pull the Axiom of Choice away
under the legs of all the lesser mathematicians ;-)
--
(espen)

Edi Weitz

unread,
Dec 5, 2002, 5:22:07 PM12/5/02
to
Espen Vestre <espen@*do-not-spam-me*.vestre.net> writes:

I think the OP was specializing:

scientist -> mathematician -> pure mathematician -> logician

Of course there are people doing pure mathematics (as opposed to
applied mathematics) and not doing logic but rather, say, algebra or
number theory. I've spent a significant part of my life working in set
theory and logic and I /do/ recall (some) other pure mathematicians
thinking of logicians as being a little bit weird... :)

Cheers,
Edi.

Frode Vatvedt Fjeld

unread,
Dec 5, 2002, 5:24:14 PM12/5/02
to
Chris Gehlker <geh...@fastq.com> writes:

> Do you see a personal attack in there?

I saw it as a very rude statement about the comp.lang.lisp community.

> As to the multiple values issue, you post was I heads-up that maybe
> I didn't understand. I had believed that the the caller need to know
> both the number and order of the values returned by the
> callee. After I read your post I did some experimenting and
> discovered that the caller can ignore the tail of the returned
> values but, AFAICT, can't ignore an intervening return without
> generating a warning. And the mechanism does seem awkward compared
> to the one line multiple assignment found in some languages. So, in
> short, you already demonstrated that my understanding was incomplete
> and I simply wanted to finish exploring on my own before responding.

Let me suggest that you look up some documentation and maybe a
tutorial as well as learning by experimentation. Read first, then
experiment to make sure you've got it. Avoid like the plague
preconceptions you bring with you from other languages.

I don't understand what "can't ignore an intervening return without
generating a warning" means. If you're looking for help, you're not
giving us much to work on. The operator for setting multiple values is
called multiple-value-setq. Look it up. Setf offers an alternative
syntax to achieve the same thing.

Do you really consider it good form to post a list of matter-of-factly
"problems" you have with things that you obviously have made very
close to zero effort at acquainting yourself with?

--
Frode Vatvedt Fjeld

Larry Clapp

unread,
Dec 5, 2002, 5:43:20 PM12/5/02
to
In article <3DEF4B21...@nyc.rr.com>, Kenny Tilton wrote:
> Chris Gehlker wrote:
<snip>

>> Compare Smalltalk. It's entire syntax fits on a couple of
>> pages.
>
> Lisp: (operator [argments]*)

I wonder that people claim that Lisp has no syntax. Perhaps I've
misunderstood the usage of the word all this time.

Don't DO, LOOP, FORMAT, COND, and DEFUN (to name a few) all have
syntax, albeit simple ones (except possibly for FORMAT :)?

Can't one add new forms with special syntax with macros and read
macros?

I looked up "syntax" at m-w.com, and their definition seems
congruent with my usage above. I Googled around a bit for
"computer syntax", but found nothing to disabuse me of my notion,
or clarify my possible mis-understanding (though I rather liked
this[1] page).

Any thoughts? Have I just taken the "no/little syntax" argument
too literally or too far?

-- Larry


[1] http://www.cs.ubc.ca/spider/norm/cs311/syntax.html

sv0f

unread,
Dec 5, 2002, 5:58:58 PM12/5/02
to
In article <7h3lm34...@pc150.maths.bris.ac.uk>, Michael Hudson
<m...@python.net> wrote:

>The population at large think scientists are a bit strange.
>Scientists often think mathematicians are a bit odd.
>Most mathematicians think pure maths is for oddballs.
>Pure mathematicians think logic is weird. <-----------------.
> |
>Who do logicians think are the strange ones? |

Computational theorists?
Intuitionists?

The population at large?

Gym teachers?

sv0f

unread,
Dec 5, 2002, 6:09:02 PM12/5/02
to
In article <BA14EA01.240CC%geh...@fastq.com>, Chris Gehlker
<geh...@fastq.com> wrote:

>After I read your post I did
>some experimenting and discovered that the caller can ignore the tail of the
>returned values but, AFAICT, can't ignore an intervening return without
>generating a warning. And the mechanism does seem awkward compared to the
>one line multiple assignment found in some languages.

Like some others, I don't know what "can't ignore an intervening return
without generating a warning" means. It sounds like you need to:

(1) Read up on the macro NTH-VALUE.
(2) Learn about (DECLARE (IGNORE ...))
(3) Learn how to stifle warnings in your common lisp implementation,
although I'd advise against it. Compilers are smart, and warnings
are often hints that should send you back to your code, CLtL, or the
HyperSpec.

More generally, Chris, you may need to get ahold of some better
documentation on common lisp. A number of existing (in fact,
long-standing) constructs seem to be evading you. Having a copy
of Steele's CLtL2 to browse at your lesiure might reveal them to
you.

Kaz Kylheku

unread,
Dec 5, 2002, 6:42:03 PM12/5/02
to
Chris Gehlker <geh...@fastq.com> wrote in message news:<BA1449E1.2408D%geh...@fastq.com>...
> There's just too much off it. Most of the HyperSpec is just syntax. Compare

> Smalltalk. It's entire syntax fits on a couple of pages.

[ snip ]

> If you don't believe me, and I don't really expect you to, compare any
> random set of postings here with those on any of the big C++ groups. Look at
> how many discussions here are about syntax, compared to those that are about
> semantics. Compare the C++ discussion where there simply aren't syntactical
> issues.

I only have time left today to answer one stupdity, so I pick this
one.

Yes, there are languages that have a hard coded syntax whose
description fits on a couple of pages. But their users still need lots
of functionality in a language, and that has to be provided somehow.
The answer to that is to have a big library consisting of things like
functions, classes and methods. That library has syntax and semantics,
like everything else. That syntax and semantics have to be learned, or
else consulted in the reference manual. Consider:

memcpy(buf1, buf2, size);

That is syntax! You have to know that there are three parameters, and
which one specifies the destination, which one the source and which
one the size. Every argument list is syntax, and a limited, poorly
expressive syntax at that, confined to a simple list without any
nested structure.

Somewhat like Lisp, C++ also has a multiple levels of syntax. The
function call satisfies an outer syntax common to all function calls,
but the specific function being called has its own syntax: the number,
types and meaning of its parameters.

Lisp has a big library of functions, but also of many useful things
that are not functions. So what? The workarounds for not having these
features would be awful.

Suppose I want to format text to a string. In Lisp, I just remember
how to use WITH-OUTPUT-TO-STRING and FORMAT. In C++ I have to #include
the <sstream> header, explicitly construct a string-stream object, and
use some inconvenient operators to do the actual output, and then
manually extract the string. But I suppose I can congratulate myself
for not having used anything outside of the C++ grammar.

Another example iterating over a list. In Lisp, you learn how to use
DOLIST. It's painfully simple. In C++, you open-code a loop, or else
use the for_each function. Don't forget #include <algorithm> for that
one! Oh, and you have to write your own function or functor to
encapsulate the action to be done for each element. And for_each
requires a pair of iterators; so you have to write
for_each(mylist.begin(), mylist.end(), myfunctor) or write your own
wrapper that simplifies the ... the syntax. Oops, I said the dirty S
word again!

Coby Beck

unread,
Dec 5, 2002, 6:57:55 PM12/5/02
to

"Chris Gehlker" <geh...@fastq.com> wrote:

> To those who offered various work-arounds for what I asserted were
problems
> with Lisp's syntax, I would argue that the utility of the work-arounds
> demonstrates the existence of the problems.

Just a little clarification to this sentence: you can only argure that the
utility *to you* of the offered work-arounds demonstrate the existence of
the problem *for you*! I doubt you will disagree with that, you are
handling a very volatile topic pretty well (thanks) but this small change
rather eliminates the point as relevant to anything more than personal
preferences and as such there is nothing to debate about....

about this:


> But if everything you say is true, then Lispers
> look more rather than less ridiculous when they criticize the syntax of
> other languages to users of those languages.

I think that more than most other language communities, Lispers know what
they are talking about when they discuss "foriegn" languages. Probably
because you can make a living knowing nothing but Java or nothing but C++
but it is *very* hard to do the same knowing nothing but Lisp. Besides, how
many programmers learned Lisp first? (hint: not many) The first language
you learn makes a lasting impression and for many permanently shapes their
way of thinking. So whereas in the C++ group, you will hear so many
criticisms of Lisp (right or wrong) by people who have never written or read
a single line of production Lisp code, the C++ and Java bashers here (right
or wrong) are often earning their living with it!

--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")


Kenny Tilton

unread,
Dec 5, 2002, 7:02:36 PM12/5/02
to

Michael Hudson wrote:

> The population at large think scientists are a bit strange.
> Scientists often think mathematicians are a bit odd.
> Most mathematicians think pure maths is for oddballs.
> Pure mathematicians think logic is weird. <-----------------.
> |
> Who do logicians think are the strange ones? |

Since this is a closed system, perhaps this is where it loops back and
logicians think bouncers[1] are strange.

--
[1] I have known some delightful bouncers, including one who weighed
130lbs and liked to say that if trouble ever broke out he would
volunteer to run for help.

Kenny Tilton

unread,
Dec 5, 2002, 7:05:58 PM12/5/02
to

> Chris Gehlker <geh...@fastq.com> wrote in message news:<BA1449E1.2408D%geh...@fastq.com>...
>
>>There's just too much off it. Most of the HyperSpec is just syntax. Compare
>>Smalltalk. It's entire syntax fits on a couple of pages.

...and 3 * 2 + 1 => 9

different precedence for binary, and keyword operators? pshaw!

:)

kt

Jochen Schmidt

unread,
Dec 5, 2002, 7:39:31 PM12/5/02
to
Chris Gehlker wrote:

> As to the multiple values issue, you post was I heads-up that maybe I
> didn't understand. I had believed that the the caller need to know both
> the number and order of the values returned by the callee. After I read
> your post I did some experimenting and discovered that the caller can
> ignore the tail of the returned values but, AFAICT, can't ignore an
> intervening return without generating a warning. And the mechanism does
> seem awkward compared to the one line multiple assignment found in some
> languages. So, in short, you already demonstrated that my understanding
> was incomplete and I simply wanted to finish exploring on my own before
> responding.

One line multiple assignment? Whats wrong with

(let (a b c) (setf (values a b c) (values 1 2 3)) (list a b c))

in CL?

ciao,
Jochen

--
http://www.dataheaven.de

Frode Vatvedt Fjeld

unread,
Dec 5, 2002, 7:51:15 PM12/5/02
to
Jochen Schmidt <j...@dataheaven.de> writes:

> (let (a b c) (setf (values a b c) (values 1 2 3)) (list a b c))

That's almost scary. This is exactly what I wrote to ensure I
remembered the syntax correctly, a little while ago:

(let (a b c) (setf (values a b c) (values 1 2 3)) (values a b c))

--
Frode Vatvedt Fjeld

Coby Beck

unread,
Dec 5, 2002, 7:53:31 PM12/5/02
to

"Duane Rettig" <du...@franz.com> wrote in message
news:4u1hs6...@beta.franz.com...

> Chris Gehlker <geh...@fastq.com> writes:
>
> > As to the multiple values issue, you post was I heads-up that maybe I
didn't
> > understand. I had believed that the the caller need to know both the
number
> > and order of the values returned by the callee. After I read your post I
did
> > some experimenting and discovered that the caller can ignore the tail of
the
> > returned values but, AFAICT, can't ignore an intervening return without
> ===============================^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > generating a warning. And the mechanism does seem awkward compared to
the
> ==^^^^^^^^^^^^^^^^^^^^
> > one line multiple assignment found in some languages. So, in short, you
> > already demonstrated that my understanding was incomplete and I simply
> > wanted to finish exploring on my own before responding.
>
> I don't understand the flagged phrase. Please make this statement clear
> with an example.

My guess is his problem is with wanting an nth-value or needing some values
after the first one or few.

Perhaps there is some good information in here for you, Chris:

CL-USER 30 >
(let ((now (get-universal-time)))
(multiple-value-bind (second minute hour date month year)
(decode-universal-time now)
(format t "~4,'0d-~2,'0d-~2,'0d ~2,'0d:~2,'0d:~2,'0d"
year month date hour minute second))

(let ((minute (nth-value 1 (decode-universal-time now))))
(format t "~&It is ~A minutes and ~A seconds past the hour"
minute
(decode-universal-time now)))

(multiple-value-bind (s m h date month year)
(decode-universal-time now)
(declare (ignore s m h))
(format t "~&~A/~A/~A"
year month date)))

2002-12-06 11:48:17
It is 48 minutes and 17 seconds past the hour
2002/12/6

NIL
CL-USER 31 >

Paul F. Dietz

unread,
Dec 5, 2002, 8:07:15 PM12/5/02
to
Chris Gehlker wrote:

> Do you see a personal attack in there?

Yes.

Paul

Thomas F. Burdick

unread,
Dec 5, 2002, 8:21:42 PM12/5/02
to
Matthew Danish <mda...@andrew.cmu.edu> writes:

> On Thu, Dec 05, 2002 at 12:10:09AM -0700, Chris Gehlker wrote:
>
> > Some frequently used operators have names left over from the assembler for a
> > defunct machine.
>

> This I don't argue but on the other hand, I haven't been able to think
> of a better name for CAR and CDR that fully expresses what they are; and
> neither has generations of language designers apparently. All I've seen
> are HD/HEAD and TL/TAIL, FST and SND, and none of these really expresses
> what a CONS cell is, or what its CAR and CDR are.

How about LEFT and RIGHT? A cons is a pair, right? On the other
hand, car and cdr are easy, because they're so primitive. Perhaps he
has more of an issue with LDB/DPB? I know it took me far too long to
remember what those were called. On the plus side, there aren't many
parts of the language that are stuck with weird old terminology.

> > The syntax for returning multiple values from a function and for receiving
> > them is awkward and inflexible.
>
> I agree that the name MULTIPLE-VALUE-BIND is annoyingly long, but that's
> what name-completion is for. I don't see how you can claim it is
> inflexible though.

Perhaps he means something like the fact that you can't do this:

(let* (((a b c) (values 1 2 3))
(d (+ a b c))
((e f) (round d)))
...)

Of course, you can fix that with the help of macrology. That doesn't
solve the problem completely, because using your own LET *is* somewhat
antisocial. I use my own LET when working on code that can be
antisocial (it's large, or isn't maintained people other than me), but
when I can't, I miss it sometimes.

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

Thomas F. Burdick

unread,
Dec 5, 2002, 8:45:29 PM12/5/02
to
Kenny Tilton <kti...@nyc.rr.com> writes:

I don't know what you're talking about:

3 * 2 + 1 => 7

Now, if you meant:

1 + 2 * 3

that's a different story (9) :)

Thomas A. Russ

unread,
Dec 5, 2002, 7:45:08 PM12/5/02
to
Henrik Motakef <henrik....@web.de> writes:

>
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > Raymond Wiker <Raymon...@fast.no> writes:
> >
> > > Kenny Tilton <kti...@nyc.rr.com> writes:
> > >
> > > > Michael Hudson wrote:
> > > > > I suppose this wouldn't happen if we programmed in latin.
> > > >
> > > > Romans, go home?
> > >
> > > "Romani eunt domum"?
> >
> > Now now now! Please write it down correctly on the wall one
> > godzillion times. :)
>
> Oh well. Python reference thread time again. I guess nobody expected
> it.

I thought is was the Spanish Inquistion that nobody expected.

--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu

Chris Gehlker

unread,
Dec 5, 2002, 11:14:41 PM12/5/02
to
On 12/5/02 3:24 PM, in article 2hlm34x...@vserver.cs.uit.no, "Frode
Vatvedt Fjeld" <fro...@cs.uit.no> wrote:

> Chris Gehlker <geh...@fastq.com> writes:
>
>> Do you see a personal attack in there?
>
> I saw it as a very rude statement about the comp.lang.lisp community.

I'll take that as a "no." Thanks for helping set the record straight.

Chris Gehlker

unread,
Dec 6, 2002, 12:05:46 AM12/6/02
to
On 12/5/02 4:09 PM, in article none-05120...@129.59.212.53, "sv0f"
<no...@vanderbilt.edu> wrote:

> In article <BA14EA01.240CC%geh...@fastq.com>, Chris Gehlker
> <geh...@fastq.com> wrote:
>
>> After I read your post I did
>> some experimenting and discovered that the caller can ignore the tail of the
>> returned values but, AFAICT, can't ignore an intervening return without
>> generating a warning. And the mechanism does seem awkward compared to the
>> one line multiple assignment found in some languages.
>
> Like some others, I don't know what "can't ignore an intervening return
> without generating a warning" means. It sounds like you need to:
>
> (1) Read up on the macro NTH-VALUE.
> (2) Learn about (DECLARE (IGNORE ...))
> (3) Learn how to stifle warnings in your common lisp implementation,
> although I'd advise against it. Compilers are smart, and warnings
> are often hints that should send you back to your code, CLtL, or the
> HyperSpec.

Exactly right. This is what I didn't know.

> More generally, Chris, you may need to get ahold of some better
> documentation on common lisp. A number of existing (in fact,
> long-standing) constructs seem to be evading you. Having a copy
> of Steele's CLtL2 to browse at your lesiure might reveal them to
> you.

Right now it's harder than you think. I made a joke earlier about how
popular Lisp must be because the books stores are all out of introductory
Lisp books but the joke was on me because other than Graham they really are
out. And Graham will say "This is how it works" when he should say "This is
the simplest way it works, other options are available."

The references are great once you have a clue what you are looking for but
they don't pretend to be tutorials.

I haven't even settled on an implementation yet. I thought it was a good
idea to get a better handle on the language before I did that. I mostly
alternate between OpenMCL and Clisp. Both have things that I miss in the
other. Except for trace and the print family I don't know how to debug and I
certainly can't profile. I still have to look at my cheat sheet for some of
the lesser used emacs commands.

Kenny Tilton

unread,
Dec 6, 2002, 12:50:26 AM12/6/02
to

Thomas F. Burdick wrote:
> Kenny Tilton <kti...@nyc.rr.com> writes:

> I don't know what you're talking about:
>
> 3 * 2 + 1 => 7
>
> Now, if you meant:
>
> 1 + 2 * 3
>
> that's a different story (9) :)
>

What?! It's been a while. They go left to right?! I have been doing Lisp
too long, I saw in my mind (3 * (2 + 1)).

The good news is that obviously i am a burnt-out case and am no longer
capable of programming a computer. I'm going on steroids and prepping
for the Certified Bouncer Exam.

--

Kenny Tilton

unread,
Dec 6, 2002, 1:07:02 AM12/6/02
to
Chris Gehlker wrote:
> ... the books stores are all out of introductory
> Lisp books but the joke was on me because...

You never heard of Amazon? Jesus H Christ!!!!!!

:)

Have you found the HyperSpec yet?

> I haven't even settled on an implementation yet. I thought it was a good
> idea to get a better handle on the language before I did that. I mostly
> alternate between OpenMCL and Clisp.

Max out your Visa and get the MCL beta at one-third off.

> Except for trace and the print family I don't know how to debug ...

well those are how i debug, plus i know what to do in a backtrace.

> and I
> certainly can't profile.

(time <form>) is a start, unless the hairy syntax is too much for you.
:) Can you believe the language comes with time?

Raymond Wiker

unread,
Dec 6, 2002, 3:16:26 AM12/6/02
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> [1] I have known some delightful bouncers, including one who weighed
> 130lbs and liked to say that if trouble ever broke out he would
> volunteer to run for help.

In Stavanger, Norway, there is a pub of sorts that has
(had?) a woman of 90-odd years as their bouncer.

--
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/

Espen Vestre

unread,
Dec 6, 2002, 3:24:20 AM12/6/02
to
Edi Weitz <e...@agharta.de> writes:

> I think the OP was specializing:
>
> scientist -> mathematician -> pure mathematician -> logician

yes, I deliberately misunderstood that ;-)

> number theory. I've spent a significant part of my life working in set
> theory and logic and I /do/ recall (some) other pure mathematicians
> thinking of logicians as being a little bit weird... :)

all logicians I know are tolerant people, but I guess (*) they usually
think that other logicians are weird, e.g. model theorists think that
type theorists are extraordinary weird.

Which should bring us almost on-topic again, I guess :-)

(*) I don't count myself as a logician, having been a hacker for a living
for the last 8 years, and without a finished Ph.D.
--
(espen)

Bruce Hoult

unread,
Dec 6, 2002, 4:01:25 AM12/6/02
to
In article <xcvbs40...@apocalypse.OCF.Berkeley.EDU>,

t...@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:

> > I agree that the name MULTIPLE-VALUE-BIND is annoyingly long, but that's
> > what name-completion is for. I don't see how you can claim it is
> > inflexible though.
>
> Perhaps he means something like the fact that you can't do this:
>
> (let* (((a b c) (values 1 2 3))
> (d (+ a b c))
> ((e f) (round d)))
> ...)
>
> Of course, you can fix that with the help of macrology. That doesn't
> solve the problem completely, because using your own LET *is* somewhat
> antisocial.

I think it's a bit of a mistake to force "let" and friends to introduce
an explicit level of nesting. The result is that you either end up
confusingly far over on the right hand side, or else have to invent a
whole lot of hard to remember variations on the theme.

Instead, progn (and implicit progns) might have been better to allow
expressions to be mixed arbitrarily with binding forms, with each
binding form creating an implicit scope to the end of the progn.

e.g., the above in Dylan (with one value changed for better
illustration):

begin
let (a, b, c) = values(1.8, 2, 3);
let d = a + b + c;
let (e, f) = round(d);
format-out("%= = %= + %=\n", d, e, f);
end

=>
6.8d0 = 7 + -0.2d0


Scheme actually comes annoyingly close to this if you use "define" other
than at the toplevel. Except that it dosn't do multiple values.

It's interesting that most of the widely-used imperative languages have
switched from "all declarations at the top of the function" to mixing
declarations with statements. It's also interesting that traditional C
has always been much the same as CL, with declarations and nested scopes
going together. When forced to program in C I'll often do things like
this:

void foo(){
do something;
do something else;
{
char tmp[100];
sprintf(tmp, "...", ...);
strcat(dest, tmp);
}
do something more
}

I very seldom see other people's C code doing this sort of thing -- you
normally don't see braces used for scope, without an if() or loop in
sight.

-- Bruce

Pascal Costanza

unread,
Dec 6, 2002, 8:05:06 AM12/6/02
to
Larry Clapp wrote:
> In article <3DEF4B21...@nyc.rr.com>, Kenny Tilton wrote:
>
>>Chris Gehlker wrote:
>
> <snip>
>
>>>Compare Smalltalk. It's entire syntax fits on a couple of
>>>pages.
>>
>>Lisp: (operator [argments]*)
>
>
> I wonder that people claim that Lisp has no syntax. Perhaps I've
> misunderstood the usage of the word all this time.
>
> Don't DO, LOOP, FORMAT, COND, and DEFUN (to name a few) all have
> syntax, albeit simple ones (except possibly for FORMAT :)?

Yes and no. Lisp uses s-expressions, and the first element of an
s-expression determines its meaning. So when you see something like (abc
def :ghi jkl &mno), the :ghi and &mno bits are not part of a special
syntax, but are just parameters within that s-expression. The abc bit
determines how the rest of the expression is interpreted - when it is a
macro or a special operator it has more freedom to interpret the bits
than is the case when it is a (proper) function. That's about it.

Now, people that inherit their mindset from the Algol/C tradition
usually argue that a language should fix a core syntax that cannot be
changed by the programmer, and everything else is
functions/procedures/methods that can be defined by the programmer but
are always recognizable by their (fixed) syntax. (There are exceptions,
but that's roughly it.) They see some advantage in the fact that a
programmer cannot change the core syntax. (Like: Mediocre programmers
cannot inflict any disastrous harm to the core language.)

Lispers have a different mindset. To them, user-defined features are not
second-class citizens but have the same "rights" as language-defined
features. From this perspective, it wouldn't make sense to regard, say,
the domain-specific syntax of the loop macro as part of the Lisp
syntax. That syntax is determined by the loop macro itself, as would be
the case for any other macro, no matter if it were user-defined or
language-defined. You would have some trouble if you were to regard that
as part of the Lisp syntax, because then the Lisp syntax would be
infinite (inluding the syntaxes of all possible not-yet-existent
user-defined macros). I guess that's one thing that people from the
Algol/C world find scary about Lisp at first.


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)

Chris Gehlker

unread,
Dec 6, 2002, 8:32:14 AM12/6/02
to
On 12/5/02 11:07 PM, in article 3DF03F06...@nyc.rr.com, "Kenny Tilton"
<kti...@nyc.rr.com> wrote:

> Chris Gehlker wrote:
>> ... the books stores are all out of introductory
>> Lisp books but the joke was on me because...
>
> You never heard of Amazon? Jesus H Christ!!!!!!

The difference between Amazon and the brick & mortar places is that Amazon
admits they are sold out *after* they get your money. :-(. Did everyone on
this list decide to give Lisp books for Christmas?


>
> :)
>
> Have you found the HyperSpec yet?

Yep


>
>> I haven't even settled on an implementation yet. I thought it was a good
>> idea to get a better handle on the language before I did that. I mostly
>> alternate between OpenMCL and Clisp.
>
> Max out your Visa and get the MCL beta at one-third off.

I guess I better decide before 1/3. Is it that good?

Rob Warnock

unread,
Dec 6, 2002, 8:35:51 AM12/6/02
to
Bruce Hoult <br...@hoult.org> wrote:
+---------------

|t...@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
| > Perhaps he means something like the fact that you can't do this:
| > (let* (((a b c) (values 1 2 3))
| > (d (+ a b c))
| > ((e f) (round d)))
| > ...)
...

| e.g., the above in Dylan (with one value changed for better illustration):
|
| begin
| let (a, b, c) = values(1.8, 2, 3);
| let d = a + b + c;
| let (e, f) = round(d);
| format-out("%= = %= + %=\n", d, e, f);
| end
|
| =>
| 6.8d0 = 7 + -0.2d0
|
| Scheme actually comes annoyingly close to this if you use "define" other
| than at the toplevel. Except that it dosn't do multiple values.
+---------------

PLT Scheme (MzScheme) has "let-values", "let*-values", and "letrec-values",
so the originally-proposed code is fine [assuming a tiny change to the
syntax of the second binding subform]:

(let*-values (((a b c) (values 1 2 3))
((d) (+ a b c)) ; requires parens around var list
((e f) (round d))) ; BUG!
...)

Unfortunately, Scheme's "round" only returns one value!! :-(

(...because Scheme requires strict matching of the arity of
a continuation with the number of values returned through it,
unlike CL's more-convenient silent dropping of excess values.)


-Rob

-----
Rob Warnock, PP-ASEL-IA <rp...@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607

Pascal Costanza

unread,
Dec 6, 2002, 8:40:48 AM12/6/02
to
Chris Gehlker wrote:
> On 12/5/02 11:07 PM, in article 3DF03F06...@nyc.rr.com, "Kenny Tilton"
> <kti...@nyc.rr.com> wrote:

>>Max out your Visa and get the MCL beta at one-third off.
>
>
> I guess I better decide before 1/3. Is it that good?

Try the demo version. It only works in classic mode, but is more or less
the same (only that 5.0b looks much better in Aqua, of course ;). Ask
them to give you a password for the demo version so that you can have
sessions that last longer than 15 mins. They have a very friendly staff.

Use their mailing list to ask more specific questions.

Yes, it's good. ;)

Nils Goesche

unread,
Dec 6, 2002, 9:44:35 AM12/6/02
to
Joe Marshall <j...@ccs.neu.edu> writes:

> Chris Gehlker <geh...@fastq.com> writes:
>
> > Parens are hard to type.
>
> The amount of pressure to depress a paren key is not significantly
> different from other key.

In fact, this is not quite right: It's less. Because if you do it
right and use sexp-editing commands, one key press will produce /two/
parentheses. To be precise, `M-(´, conveniently bound to some other
key -- I take `[´ on American layout, will produce two parentheses,
but once in a while you have to type `M-)´, bound to `]´ here, which
produces no parentheses at all (but spares you some hits to `Enter´).

To Chris: I don't know if you already do that but if you don't, learn
to use M-( and M-), and other sexp editing commands like C-M-k and
C-M-Backspace (DontZap in XF86Config is a must for Linux Lispers ;-).
The number of opening parentheses should always equal the number of
closing parentheses (modulo contents of strings and #\( and the like).
It takes a while to get used to, but then you can hack Lisp code
/really/ fast and never have a problem with parentheses again.

Regards,
--
Nils Gösche
"Don't ask for whom the <CTRL-G> tolls."

PGP key ID 0x0655CFA0

Chris Gehlker

unread,
Dec 6, 2002, 10:17:25 AM12/6/02
to
On 12/6/02 7:44 AM, in article lkisy7n...@cartan.de, "Nils Goesche"
<car...@cartan.de> wrote:

> To Chris: I don't know if you already do that but if you don't, learn
> to use M-( and M-), and other sexp editing commands like C-M-k and
> C-M-Backspace (DontZap in XF86Config is a must for Linux Lispers ;-).
> The number of opening parentheses should always equal the number of
> closing parentheses (modulo contents of strings and #\( and the like).
> It takes a while to get used to, but then you can hack Lisp code
> /really/ fast and never have a problem with parentheses again.

Yes I am trying to learn emacs as as I learn Lisp and emacs is much harder.
In Lisp, when you get a concept, you have it. Emacs takes so much repetition
before anything becomes automatic.

Nils Goesche

unread,
Dec 6, 2002, 10:40:37 AM12/6/02
to
Chris Gehlker <geh...@fastq.com> writes:

> On 12/6/02 7:44 AM, in article lkisy7n...@cartan.de, "Nils Goesche"
> <car...@cartan.de> wrote:
>
> > C-M-Backspace (DontZap in XF86Config is a must for Linux Lispers
> > ;-).

> Yes I am trying to learn emacs as as I learn Lisp and emacs is much


> harder. In Lisp, when you get a concept, you have it. Emacs takes
> so much repetition before anything becomes automatic.

But it /does/ become automatic eventually. I lived for a while
without DontZap in XF86Config and thought: ``Well, I don't really need
C-M-Backspace anyway, so I just won't hit it.´´ But that didn't work.
I hit C-M-Backspace often enough unconsciously to do exactly what it
does in Emacs (thus killing my X server). Apparently there is /some/
logic behind the default key bindings... So I finally added DontZap.

sv0f

unread,
Dec 6, 2002, 11:50:47 AM12/6/02
to
In article <BA157E3A.24238%geh...@fastq.com>, Chris Gehlker
<geh...@fastq.com> wrote:

>> More generally, Chris, you may need to get ahold of some better
>> documentation on common lisp. A number of existing (in fact,
>> long-standing) constructs seem to be evading you. Having a copy
>> of Steele's CLtL2 to browse at your lesiure might reveal them to
>> you.
>
>Right now it's harder than you think. I made a joke earlier about how
>popular Lisp must be because the books stores are all out of introductory
>Lisp books but the joke was on me because other than Graham they really are
>out. And Graham will say "This is how it works" when he should say "This is
>the simplest way it works, other options are available."

David Touretzky's "Common Lisp: A Gentle Introduction to Symbolic
Computation" is available for free download. It's my favorite
newbie book recommendation. The only problem is that it's written
for readers new to programming. You sound like an experienced
programmer new to Lisp, so you may find some parts elementary I
encourage you to read them anyway. It's amazing how many assumptions
that work in other languages don't work in Lisp (but are replaced by
something more wonderful!).

I've seen others recommend David Lamkin's on-line tutorial.

IMO, the best introductory book for programmers new to Common Lisp
is Wade Hennessey's "Common Lisp". Maybe you can find it used on-line?
A comparable book is Robert Wilensky's "Common Lispcraft". Vanderbilt
University's bookstore has a number of new and used copies. If worst
comes to worst, I'd be willing to buy it for and mail it to you if
you'll reimburse me.

Also, you can go to http://www.bestwebbuys.com/ and search for books,
new and used, with "lisp" in the title. You might be pleasantly surprised.

Joe Marshall

unread,
Dec 6, 2002, 12:14:41 PM12/6/02
to
Larry Clapp <la...@theclapp.org> writes:

> In article <3DEF4B21...@nyc.rr.com>, Kenny Tilton wrote:
> > Chris Gehlker wrote:
> <snip>
> >> Compare Smalltalk. It's entire syntax fits on a couple of
> >> pages.
> >
> > Lisp: (operator [argments]*)
>
> I wonder that people claim that Lisp has no syntax. Perhaps I've
> misunderstood the usage of the word all this time.
>
> Don't DO, LOOP, FORMAT, COND, and DEFUN (to name a few) all have
> syntax, albeit simple ones (except possibly for FORMAT :)?

They have an `internal' syntax (yeah, this sounds like a cop-out, but
read on...)

A compiler or interpreter need, at some point, to have a model of the
code which is being compiled or interpreted. This usually takes the
form of an abstract syntax tree where each node in the tree is typed
according to the syntactic construct it represents. Whatever builds
this abstract syntax tree has to know the syntax of the language.

In Lisp, the output of READ is suitable as an abstract syntax tree.
An expression type is determined by looking at the CAR of the list
returned by READ. The interpreter or compiler can dispatch on the CAR
without having to parse the CDR. The READ function can create the
abstract syntax tree without having to parse the `interior' of the
lists it is creating.

To illustrate, imagine a Lisp with some infix notation:

(let ((y 7))

car (x) := car (x) + y)


Now when you try to interpret the expression car (x) := y + 8, you
can't just look at the first element in the list. You have to muck
around a bit and determine that there is a := token embedded within
the list. In addition, the tokens `car (x)' have different parses
where they are used: one is a function call, the other is an
assignment target.

It is this level of syntax that people are talking about. It is true
that the LOOP macro has to do a lot of mucking around, but neither
READ nor EVAL have to do any hard work to determine whether an
expression is a call to the LOOP macro or not.

Thomas F. Burdick

unread,
Dec 6, 2002, 1:59:40 PM12/6/02
to
Bruce Hoult <br...@hoult.org> writes:

> I think it's a bit of a mistake to force "let" and friends to introduce
> an explicit level of nesting. The result is that you either end up
> confusingly far over on the right hand side, or else have to invent a
> whole lot of hard to remember variations on the theme.
>
> Instead, progn (and implicit progns) might have been better to allow
> expressions to be mixed arbitrarily with binding forms, with each
> binding form creating an implicit scope to the end of the progn.
>
> e.g., the above in Dylan (with one value changed for better
> illustration):
>
> begin
> let (a, b, c) = values(1.8, 2, 3);
> let d = a + b + c;
> let (e, f) = round(d);
> format-out("%= = %= + %=\n", d, e, f);
> end
>
> =>
> 6.8d0 = 7 + -0.2d0

Yuck. The body of the LET is the scope of the lexical variables it
introduces. I *like* that the physical structure of the code reflects
the logical structure. Anything else would be very un-Lispy. Take
LOOP for example. Its variables' scopes aren't reflected in the
structure, and that goes along with the very un-Lispy feel of LOOP
(which is not a bad thing, btw).

> Scheme actually comes annoyingly close to this if you use "define" other
> than at the toplevel. Except that it dosn't do multiple values.
>
> It's interesting that most of the widely-used imperative languages have
> switched from "all declarations at the top of the function" to mixing
> declarations with statements. It's also interesting that traditional C
> has always been much the same as CL, with declarations and nested scopes
> going together. When forced to program in C I'll often do things like
> this:
>
> void foo(){
> do something;
> do something else;
> {
> char tmp[100];
> sprintf(tmp, "...", ...);
> strcat(dest, tmp);
> }
> do something more
> }
>
> I very seldom see other people's C code doing this sort of thing -- you
> normally don't see braces used for scope, without an if() or loop in
> sight.

Right, but you see it sometimes, usually from good C programmers.
Most people, when programming in C, do the moral equivalent of:

(defun really-big-function (a b c &aux temp1 temp2 temp3 i j result)
...
result)

I hardly think that's something to aspire to.

It is loading more messages.
0 new messages