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! =-----
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
On 12/2/02 8:40 AM, in article ···············@news.t-online.com, "Jochen
Schmidt" <···@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>.
-----= 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! =-----
Chris Gehlker <·······@fastq.com> writes:
> On 12/2/02 8:40 AM, in article ···············@news.t-online.com, "Jochen
> Schmidt" <···@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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On 12/2/02 12:34 PM, in article ···············@avalanche.OCF.Berkeley.EDU,
"Thomas F. Burdick" <···@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.
-----= 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! =-----
Chris Gehlker wrote:
> On 12/2/02 8:40 AM, in article ···············@news.t-online.com, "Jochen
> Schmidt" <···@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)"
ciao,
Jochen
--
http://www.dataheaven.de
In article <···············@news.t-online.com>,
Jochen Schmidt <···@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.
Dorai Sitaram wrote:
> In article <···············@news.t-online.com>,
> Jochen Schmidt <···@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.
ciao,
Jochen
--
http://www.dataheaven.de
····@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
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
Kenny Tilton <·······@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: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Raymond Wiker <·············@fast.no> writes:
> Kenny Tilton <·······@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'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Raymond Wiker <·············@fast.no> writes:
>
> > Kenny Tilton <·······@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?
>>>>> "Joe" == Joe Marshall <···@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
····@goldshoe.gte.com (Dorai Sitaram) writes:
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> >
> >What's a godzillion in Roman numerals?
>
> GODZILLION
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
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Raymond Wiker <·············@fast.no> writes:
>
> > Kenny Tilton <·······@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
Henrik Motakef <··············@web.de> writes:
>
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Raymond Wiker <·············@fast.no> writes:
> >
> > > Kenny Tilton <·······@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 ···@isi.edu
Marco Antoniotti wrote:
>
> Raymond Wiker <·············@fast.no> writes:
>
> > Kenny Tilton <·······@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
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.
On Wed, 04 Dec 2002 23:45:21 +0000, Donald Fisk wrote:
> Marco Antoniotti wrote:
>>
>> Raymond Wiker <·············@fast.no> writes:
>>
>> > Kenny Tilton <·······@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.
--
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>"))
Paul Foley wrote:
> On Wed, 04 Dec 2002 23:45:21 +0000, Donald Fisk wrote:
>
>
>>Marco Antoniotti wrote:
>>
>>>Raymond Wiker <·············@fast.no> writes:
>>>
>>>
>>>>Kenny Tilton <·······@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.
--
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
On 03 Dec 2002 16:01:36 +0100, Raymond Wiker wrote:
> Kenny Tilton <·······@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>"))
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.
Donald Fisk <················@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. ;)
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
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Chris Gehlker <·······@fastq.com> wrote in message news:<······················@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.
On 12/2/02 7:19 PM, in article
····························@posting.google.com, "Kaz Kylheku"
<···@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.
-----= 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! =-----
Chris Gehlker <·······@fastq.com> wrote in message news:<······················@fastq.com>...
> On 12/2/02 7:19 PM, in article
> ····························@posting.google.com, "Kaz Kylheku"
> <···@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.
On 12/4/02 4:41 PM, in article
····························@posting.google.com, "Kaz Kylheku"
<···@ashi.footprints.net> wrote:
> Chris Gehlker <·······@fastq.com> wrote in message
> news:<······················@fastq.com>...
>> On 12/2/02 7:19 PM, in article
>> ····························@posting.google.com, "Kaz Kylheku"
>> <···@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.
-----= 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! =-----
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.
--
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
On 12/4/02 7:47 PM, in article ················@nyc.rr.com, "Kenny Tilton"
<·······@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.
-----= 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! =-----
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 <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On Thu, Dec 05, 2002 at 05:21:42PM -0800, Thomas F. Burdick wrote:
> How about LEFT and RIGHT? A cons is a pair, right? On the other
Hrm, sounds better than HD/TL but... what about a cons cell gives it
orientation?
> 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.
But they are so much nicer than futzing with masks and bitwise
operations that I forgive the names =)
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> On Thu, Dec 05, 2002 at 05:21:42PM -0800, Thomas F. Burdick wrote:
> > How about LEFT and RIGHT? A cons is a pair, right? On the other
>
> Hrm, sounds better than HD/TL but... what about a cons cell gives it
> orientation?
The way they print?
* (print '(left . right))
(left . right)
> > 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.
>
> But they are so much nicer than futzing with masks and bitwise
> operations that I forgive the names =)
Actually, that's what annoyed me so much at first, I loved the
functionality, but had to keep searching for the names in the
hyperspec.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Matthew Danish <·······@andrew.cmu.edu> writes:
>
> > 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?
I have periodically proposed LHS/RHS (left hand side, right hand side)
as alternatives for CAR/CDR if there were a renaming. It has the same
ability to compose as does CAR/CDR and is still just 3 letters long for
the base set of names (and consequently is the same length name for each
side, unlike left and right).
The reason CAR/CDR persist isn't lack of alternatives. It's simple history.
Maybe we should erradicate all history from the language.
Let's get rid of names like LAMBDA next.
Maybe after we finish iwth Lisp we could go after English itself. I
think there are some borrowed terms (not to mention morphemes) here
and there that we could perhaps erradicate and replace with gensymed
noise sequences. Then dictionaries could be smaller because we could
erradicate the need for all that etymological information. Maybe then
finally English would be more popular. Wait a minute. Oops. English
already IS popular, in spite of irregularities and unrationalized
mishmashes of history throughout. Hmmm. Maybe language
irregularities are possible to get past after all. Nevermind.
Kent M Pitman <······@world.std.com> writes:
> ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Matthew Danish <·······@andrew.cmu.edu> writes:
> >
> > > 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?
>
> I have periodically proposed LHS/RHS (left hand side, right hand side)
> as alternatives for CAR/CDR if there were a renaming. It has the same
> ability to compose as does CAR/CDR and is still just 3 letters long for
> the base set of names (and consequently is the same length name for each
> side, unlike left and right).
>
> The reason CAR/CDR persist isn't lack of alternatives. It's simple history.
>
> Maybe we should erradicate all history from the language.
> Let's get rid of names like LAMBDA next.
Just to clarify, I wasn't proposing a revision, and I don't plan on
using lhs/rhs instead of car/cdr in my own code; I was just pointing
out that there is a pair of terms that expresses what a cons cell is
better than car/cdr.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Kent M Pitman <······@world.std.com> writes:
[...snip...]
> The reason CAR/CDR persist isn't lack of alternatives. It's simple history.
>
> Maybe we should erradicate all history from the language.
> Let's get rid of names like LAMBDA next.
>
> Maybe after we finish iwth Lisp we could go after English itself. I
> think there are some borrowed terms (not to mention morphemes) here
> and there that we could perhaps erradicate and replace with gensymed
> noise sequences. Then dictionaries could be smaller because we could
> erradicate the need for all that etymological information. Maybe then
> finally English would be more popular. Wait a minute. Oops. English
> already IS popular, in spite of irregularities and unrationalized
> mishmashes of history throughout. Hmmm. Maybe language
> irregularities are possible to get past after all. Nevermind.
I admit that I had to laugh at this, but...
As a second languare speaker of English and a proud owner of the
abridged (only 350 000 words) OED, I have to put forward my opinion
that English is hardly popular(1) [liked, admired, ...] but certainly
popular(2b) [held by the majority of the general public ...].
This sort of fits in this thread, because it is yet another example of
change in usage with the actual word remaining the same: the sense
(2b) of "popular" is by far the older, deriving straight from Latin
"popularis"; the sense (1) which the OED offers as prevalent is pretty
modern, dating from the early 17th century.
Using the European sense of "modern", here, of course :-)
--
Teemu Kalvas
Kent M Pitman <······@world.std.com> wrote:
+---------------
| The reason CAR/CDR persist isn't lack of alternatives. It's simple history.
|
| Maybe we should erradicate all history from the language.
| Let's get rid of names like LAMBDA next.
+---------------
Yeah, right. (Although I sometimes admit to myself that I kinda like
ML's use of "FN" for anonymous functions...)
+---------------
| Maybe after we finish iwth Lisp we could go after English itself.
+---------------
As in <URL:http://dept.physics.upenn.edu/~heiney/jokes/twain.html>?
[Though <URL:http://users.telerama.com/~joseph/simple.html> is
claimed by other sources to be an actual Mark Twain article, one
of his last.]
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Matthew Danish <·······@andrew.cmu.edu> writes:
> > 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
> How about LEFT and RIGHT?
Or HLRZ and HRRZ for consistency with other function names:
> On the other hand, car and cdr are easy, because they're so
> primitive. Perhaps he has more of an issue with LDB/DPB?
--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10,
Brinkhoff Consulting http://www.brinkhoff.se/ HTTP programming
Lars Brinkhoff <·········@nocrew.org> wrote:
+---------------
| ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
| > > of a better name for CAR and CDR that fully expresses what they are
| > How about LEFT and RIGHT?
|
| Or HLRZ and HRRZ for consistency with other function names:
| >...LDB/DPB...
+---------------
*ROTFLMAO!* Of course, why not?!?
And PUSHJ\ P\,@2\(T1\) instead of FUNCALL, I presume? ;-}
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <···············@apocalypse.OCF.Berkeley.EDU>,
···@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
Bruce Hoult <·····@hoult.org> wrote:
+---------------
····@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 <····@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Bruce Hoult <·····@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.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@avalanche.OCF.Berkeley.EDU>,
···@avalanche.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> > 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.
So you never use let* (as in the original example) then?
The only difference between that and Dylan's "let" [1] is that you can't
put other side-effectfull stuff between the bindings. Well, you *could*
use a progn as the initialization expression for something. But that's
getting excessively ugly.
> 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).
I agree it's not a bad thing. In fact I prefer the whole language to be
similar to CL's LOOP.
-- Bruce
[1] it's not "let", really, it's the syntactic construct of "body",
basically the same as CL's implicit progn.
Bruce Hoult wrote:
> 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.
Ha. I do it all the time. Perhaps exposure to Lisp encourages this
sort of thing, though I'd always regarded it simply as good style
to make the syntactic and semantic scopes of a variable match up.
--
Gareth McCaughan ················@pobox.com
.sig under construc
Chris Gehlker <·······@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.
* 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.
Chris Gehlker <·······@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.
Joe Marshall <···@ccs.neu.edu> writes:
> Chris Gehlker <·······@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
On 12/6/02 7:44 AM, in article ··············@cartan.de, "Nils Goesche"
<······@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.
-----= 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! =-----
Chris Gehlker <·······@fastq.com> writes:
> On 12/6/02 7:44 AM, in article ··············@cartan.de, "Nils Goesche"
> <······@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.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche <······@cartan.de> writes:
> 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.
Yes. It's a bit much telling people not to use certain
keystrokes because another program uses them, but in the
case of emacs, I'm willing to make an exception :-)
so, to anyone who'se writing window managers, KDE and
GNOME environments out there:
(with-rant (:severe)
"STOP TRASHING THE EMACS KEYMAPS!!!"
When trying to use such environments, I either have to give
up or spend hours configuring all the keystrokes shortcut to
stop interfering with emacs. Emacs has many more users than
your new cool wysiwyg new-fangled "product", so /PLEASE/ respect
the hard work invested by tens (hundreds?) of thousands of users
in internalizing the emacs keystrokes.)
In article <··············@optushome.com.au>, Alain Picard wrote:
> Nils Goesche <······@cartan.de> writes:
>> 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.
>
> Yes. It's a bit much telling people not to use certain
> keystrokes because another program uses them, but in the case
> of emacs, I'm willing to make an exception :-) so, to anyone
> who'se writing window managers, KDE and GNOME environments out
> there:
>
> (with-rant (:severe)
>
> "STOP TRASHING THE EMACS KEYMAPS!!!"
>
> When trying to use such environments, I either have to give up
> or spend hours configuring all the keystrokes shortcut to stop
> interfering with emacs. Emacs has many more users than your
> new cool wysiwyg new-fangled "product", so /PLEASE/ respect the
> hard work invested by tens (hundreds?) of thousands of users in
> internalizing the emacs keystrokes.)
:)
(with-tone (:ha-ha-only-serious)
On a normal ascii line, the only safe condition to detect is
a 'BREAK' - everything else having been assigned functions by
Gnu EMACS.
-- Tarl Neustaedter
RISKS Digest, 21 Feb 1995
http://catless.ncl.ac.uk/Risks/16.85.html#subj8)
On the other hand, I feel your pain. I don't use Emacs, but I do
use various home-grown (and admittedly somewhat baroque)
keychords in my window manager, and thus couldn't use various
chords in the Opera browser (until they added a remap facility).
Sadly, fewer people use my keymaps than use Emacs, so I suppose
I'll have less success than the Emacs crowd getting people not to
stomp on them. ;)
-- L
-----= 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! =-----
Nils Goesche <······@cartan.de> writes:
> 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.
I wasn't sure what DontZap might be, and I don't know what
C-M-Backspace does. So, believe it or not, I just typed C-h k
C-M-Backspace, and killed my X server. *sigh* Oh. Right. That's what
DontZap does. :)
Need. More. Coffee.
-Tim
···@tenkan.org (Tim Daly, Jr.) writes:
> Nils Goesche <······@cartan.de> writes:
>
> > 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.
>
> I wasn't sure what DontZap might be, and I don't know what
> C-M-Backspace does. So, believe it or not, I just typed C-h k
> C-M-Backspace, and killed my X server. *sigh* Oh. Right. That's what
> DontZap does. :)
>
> Need. More. Coffee.
Aargh, I was thinking about adding a kindof ``don't try this at
home, kids�� warning but thought that everybody already knows
about it, anyway. Sorry :)
Regards,
--
Nils G�sche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
Chris Gehlker wrote:
> On 12/4/02 7:47 PM, in article ················@nyc.rr.com, "Kenny Tilton"
> <·······@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
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
In article <················@web.de>, Pascal Costanza <········@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.
On 12/5/02 11:09 AM, in article ·····················@129.59.212.53, "sv0f"
<····@vanderbilt.edu> wrote:
> In article <················@web.de>, Pascal Costanza <········@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.
-----= 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! =-----
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.
:)
--
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
On 12/5/02 5:44 AM, in article ················@nyc.rr.com, "Kenny Tilton"
<·······@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!
-----= 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! =-----
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. :)
--
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
On 12/5/02 8:40 AM, in article ··············@nyc.rr.com, "Kenny Tilton"
<·······@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.
-----= 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! =-----
* Kenny Tilton <·······@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.
Kenny Tilton <·······@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.
Jacek Generowicz wrote:
> Kenny Tilton <·······@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.
:)
--
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 <·······@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
On 12/5/02 8:02 AM, in article ··············@vserver.cs.uit.no, "Frode
Vatvedt Fjeld" <······@cs.uit.no> wrote:
> Chris Gehlker <·······@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.
-----= 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! =-----
Chris Gehlker <·······@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
On 12/5/02 9:39 AM, in article ··············@vserver.cs.uit.no, "Frode
Vatvedt Fjeld" <······@cs.uit.no> wrote:
> Chris Gehlker <·······@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?
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 ··············@vserver.cs.uit.no, "Frode
> Vatvedt Fjeld" <······@cs.uit.no> wrote:
>
>> Chris Gehlker <·······@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.
-----= 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! =-----
In article <······················@fastq.com>, Chris Gehlker
<·······@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.
On 12/5/02 4:09 PM, in article ·····················@129.59.212.53, "sv0f"
<····@vanderbilt.edu> wrote:
> In article <······················@fastq.com>, Chris Gehlker
> <·······@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.
-----= 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! =-----
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?
--
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
On 12/5/02 11:07 PM, in article ················@nyc.rr.com, "Kenny Tilton"
<·······@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?
-----= 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! =-----
Chris Gehlker <·······@fastq.com> writes:
> On 12/5/02 11:07 PM, in article ················@nyc.rr.com, "Kenny Tilton"
> <·······@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?
If you're feeling committed to investing much time and effort in CL,
this is good advice. If you're still unsure, also consider getting
MCL 4, and running it under Classic. No, it's not OS X native, and
yes you have to deal with weird issues seeing OS X files from Classic,
but if you're just looking for a cheap platform to learn the language
on, it's all you need.
If you can afford the beta, go for that. But if you're just dabbling,
and don't want to max out your Visa, there's a cheap option, too.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Chris Gehlker wrote:
> On 12/5/02 11:07 PM, in article ················@nyc.rr.com, "Kenny Tilton"
> <·······@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. ;)
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
In article <······················@fastq.com>, Chris Gehlker
<·······@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.
On 12/6/02 9:50 AM, in article ·····················@129.59.212.53, "sv0f"
<····@vanderbilt.edu> wrote:
>
> 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.
I'm really surprised I missed those. I was able to DL them both in PDF. And
now Amazon tells me that they shipped the others that I ordered. So now I
have plenty to keep me busy. Thank you very much.
>
> 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.
I may take you up on that but right now I want to play with what I have for
awhile.
-----= 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! =-----
Chris Gehlker <·······@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 ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
"Duane Rettig" <·····@franz.com> wrote in message
··················@beta.franz.com...
> Chris Gehlker <·······@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 >
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
On 12/5/02 5:53 PM, in article ·············@otis.netspace.net.au, "Coby
Beck" <·····@mercury.bc.ca> wrote:
> 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:
That is my problem and that is good info. Thanks,
I think the root of my problem was Graham who seems to know a lot about Lisp
but sometimes writes about a much smaller language. A case it point is his
discussion of returning multiple values from a function w/o mentioning
nth-value. So a newbie such as I experiments till he finds some awkward way
of doing something, assumes that that is the only way, and concludes that
Lisp is awkward in that area. Another case in point is his discussion of
destructuring-bind where he somehow thinks the notion and the form of a
destructuring lambda list isn't worth mentioning.
I'll stop whining now. With the help of folks here I found plenty of more
complete references where Graham needs supplementing.
-----= 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! =-----
Chris Gehlker <·······@fastq.com> writes:
> On 12/5/02 5:53 PM, in article ·············@otis.netspace.net.au, "Coby
> Beck" <·····@mercury.bc.ca> wrote:
>
> > My guess is his problem is with wanting an nth-value or needing
> > some values after the first one or few.
> I think the root of my problem was Graham who seems to know a lot
> about Lisp but sometimes writes about a much smaller language.
He tends to omit the parts he doesn't like, like CLOS and LOOP.
> So a newbie such as I experiments till he finds some awkward way of
> doing something, assumes that that is the only way, and concludes
> that Lisp is awkward in that area.
This conclusion is almost always wrong :-)
> I'll stop whining now. With the help of folks here I found plenty of
> more complete references where Graham needs supplementing.
Well, Graham's books aren't supposed to be complete references. There
is the HyperSpec for that. The value of a textbook teaching a
language is precisely that it cuts some things and tries to teach a
subset first to get people started, and to show what is Lispy code and
what isn't. Somebody who doesn't know Lisp at all would have a hard
time learning it from the HyperSpec only, I guess.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
"Chris Gehlker" <·······@fastq.com> wrote in message
···························@fastq.com...
> On 12/5/02 5:53 PM, in article ·············@otis.netspace.net.au, "Coby
> Beck" <·····@mercury.bc.ca> wrote:
>
> > 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:
>
> That is my problem and that is good info. Thanks,
>
> I think the root of my problem was Graham who seems to know a lot about
Lisp
> but sometimes writes about a much smaller language.
Paul Graham is without question a Lisp Guru but he is also a self described
hater of Common Lisp. He does not really do justice to the parts he does
not like (IMO)
> A case it point is his
> discussion of returning multiple values from a function w/o mentioning
> nth-value. So a newbie such as I experiments till he finds some awkward
way
Understandable.
> assumes that that is the only way,
a common mistake
> and concludes that Lisp is awkward in that area.
An unconscionable error! ;)
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Chris Gehlker <·······@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
On 12/5/02 3:24 PM, in article ··············@vserver.cs.uit.no, "Frode
Vatvedt Fjeld" <······@cs.uit.no> wrote:
> Chris Gehlker <·······@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.
-----= 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! =-----
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
Jochen Schmidt <···@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
Jochen Schmidt <···@dataheaven.de> writes:
>
> 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?
>
I learn something new every day.. I didn't know you could setf values
like that.
Jock Cooper
--
http://www.fractal-recursions.com
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.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
On 12/5/02 10:06 AM, in article ················@web.de, "Pascal Costanza"
<········@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?"
-----= 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! =-----
Chris Gehlker wrote:
> On 12/5/02 10:06 AM, in article ················@web.de, "Pascal Costanza"
> <········@web.de> wrote:
>
>
>>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?"
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
"Chris Gehlker" <·······@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")
In article <················@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
-----= 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! =-----
Larry Clapp <·····@theclapp.org> writes:
> In article <················@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.
Larry Clapp wrote:
> In article <················@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
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Chris Gehlker <·······@fastq.com> wrote in message news:<······················@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!
> Chris Gehlker <·······@fastq.com> wrote in message news:<······················@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
Kenny Tilton <·······@nyc.rr.com> writes:
> > Chris Gehlker <·······@fastq.com> wrote in message news:<······················@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!
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) :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> Kenny Tilton <·······@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
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
Kenny Tilton <·······@nyc.rr.com> writes:
> Thomas F. Burdick wrote:
> > Kenny Tilton <·······@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)).
Of course! Smalltalk was designed in the US, with the idea of sane
notation in mind. Punctuation has meaning borrowed from English, and
you read it left-to-right. Now, if Xerox PARC were in Cairo, instead
of the South Bay, I would have expected it to read right-to-left.
> 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.
Out of curiosity, who is the proctor you're going to take it from? He
wouldn't also be in the Brooklyn-bridge-selling business, would he?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Chris Gehlker <·······@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: <··········@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).
Alain Picard <·······················@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 <····@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Alain Picard <·······················@optushome.com.au> writes:
> Chris Gehlker <·······@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
Hello!
Alain Picard <·······················@optushome.com.au> wrote:
>[...]
>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??? */
Clearly
(incf (slot-value (the 'foo p) 'blah))
*g* SCNR
>[...]
Kind regards,
Hannah.
"Chris Gehlker" <·······@fastq.com> wrote in message
···························@fastq.com...
> On 12/4/02 7:47 PM, in article ················@nyc.rr.com, "Kenny Tilton"
> <·······@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")
Chris Gehlker <·······@fastq.com> writes:
> 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.
Perhaps this has something to do with the fact that when you get the
syntax wrong in C++, it breaks the semantics, and therefore coding style
questions morph into semantic problems because changing the coding style
can change how the compiler interprets the code?
One of the best examples is >> vs. > > in template instantiations, but
there are lots of other ones, including ones inherited from C like the
dangling else syntax wart or the = vs. == confusion inside if statements.
Most large C and C++ projects seem to have coding standards, in part
because not having and following coding standards results in writing
programs that do subtlely wrong things or that are broken by the next
person modifying the program.
--
Russ Allbery (···@stanford.edu) <http://www.eyrie.org/~eagle/>
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.
int main
( int
argc,char
** argv )
{int
i ; for(i
= 0;i
<=10 ; ++
i) printf
("%d " ,
i);return
0;}
That isn't too hard to figure out simply because it's a downright trivial
program. I didn't have the stomach to write any more in that style.
> 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.
If that's true -- which I haven't checked -- then it could easily
be a matter of sociology rather than of language design. It certainly
isn't true that C++ is free of syntactic difficulties. Consider
a few of the more delightful features:
- the, ah, unfortunate "declaration mimics use" syntax for
type declarations, which requires you to invent typedefs
as soon as you do anything complicated or risk making your
code unreadable for half its audience
- the fact that to instantiate a template class with a templated
parameter you can't say "Foo<Bar<T>>" but need a completely
gratuitous space between the ">"s to make some braindamaged
parser's life infinitesimally simpler
- the lovely way that although
int f() {
T x(123);
// do something with x
}
will make you an object of type T and call a constructor with
the value 123,
int f() {
T x();
// try to do something with x. Oops.
}
will declare a function called x returning an object of type T.
And
int f(int y) {
T x(y);
// try to do something with x. Oops.
}
will declare a function called x returning an object of type T
that takes a formal parameter of the nonexistent type y. Actually,
I don't remember whether that's what happens -- maybe in the
particular case above you're OK -- but I know there's some
circumstance in which saying "T x(y);" is a declaration, not
a definition-with-ctor-arg. The fact that I can't remember
exactly what circumstance is evidence of the problem.
- the bizarre overloading of "static" with about seven different
meanings, related but by no means identical
- the oh-so-natural syntax for declaring pure virtual functions
- the way that if you want a label right at the end of a block,
you need to add a null statement because the poor ickle parser
can't cope otherwise
- the do {...} while (0) hack you need when using C++'s laughable
"macros". And, while I'm on that subject, the excessive number
of, um, *parentheses* they require to be safe (well, as safe as
they can be) against gotchas
- the fact that what should be just about the simplest operation
imaginable -- iterating over a container -- requires you to
write monstrous code like
for (vector<T>::const_iterator i=x.begin(); i != x.end(); ++i) {
// do some stuff with *i
}
which almost always needs further pessimization, because it's
never really "T"; it's "double" or "pair<string,double>" or
something. I'm afraid I quite often find myself writing
for (size_t i=0; i<x.size(); ++i) {
// do something with x[i]
}
because I just can't stand the pain of the STLically correct way.
- the need for inserting "typename" in (what at first sight
appear to be) gratuitous places when defining templated
functions, because C++ can't tell whether something's the
name of a type or not
I could go on and on. It may well be that no one in comp.lang.c++.moderated
talks about things like these. Perhaps everyone's ashamed of them.
I would be. Or maybe extended C++ use tends to make one unable to
distinguish between good and bad syntax.
Note that these aren't complaints along the lines of "C++ should
be more like Lisp". Even assuming that C++ needs to be broadly
the kind of language it is -- statically typed, with templates,
"traditional" infix-and-blocks syntax, blah, blah, blah -- the
syntax is just *such* a mess, *so* much worse than it could have
been if it hadn't been for the requirement to be almost completely
compatible with C and the obsessive "hey, here's a possible sequence
of tokens we haven't given a meaning to yet. Cooool!" mentality
that seems to have afflicted its designers.
And I haven't even *mentioned* trigraphs. :-)
> 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.
By "generics", presumably you mean templates. (Which can do a lot
more than just "generics".) They are indeed broken, but *simply*
broken? No, on two grounds. Firstly, they're broken in baroque and
confusing ways :-). Secondly, they *are*, for all that, one of the
key features of C++. Lots of vital things depend critically on them.
Of course, maybe you're just pulling our collective leg and saying
the opposite of what you believe. In which case I've been trolled,
but there are worse fates.
--
Gareth McCaughan ················@pobox.com
.sig under construc
On 12/6/02 4:08 PM, in article ································@g.local,
"Gareth McCaughan" <················@pobox.com> wrote:
... Lots of good stuff which is clearly insightful and
> By "generics", presumably you mean templates. (Which can do a lot
> more than just "generics".) They are indeed broken, but *simply*
> broken? No, on two grounds. Firstly, they're broken in baroque and
> confusing ways :-). Secondly, they *are*, for all that, one of the
> key features of C++. Lots of vital things depend critically on them.
I meant that they are a completely bad idea. It was very hard for me to
accept this because I had struggled hard to master them and was really proud
of how good I eventually became with them.
One of the reasons that I eventually became disillusioned was they generate
far too much code behind your back. Their is a tendency with templates to
get a program that works but not well. Then, as you start profiling, you
realize that the bottleneck is in the code that the template generated and
you end up taking out the template and doing all that stuff by hand anyway.
Sometimes by that time the design is too far along for you to really try a
different approach.
But the bigger reason that I don't like templates is that the language could
have gone a better way. Stroustrup is a smart guy but he let Stepanov sell
him some snake oil. You use templates when you start repeating yourself,
writing similar code over but changing types. The straightforward solution
would have been to introduce a mechanism to give the programmer some control
over how type safe she wanted each type to be, at least for they types that
she created. Then she could achieve generality by dialing back type safety
"just enough." But instead the C++ designers opted to automate the process
of repeating yourself.
The result, as you probably know, is that programmers follow Meyers' advice
and design templates that handle a few of particular cases and do the rest
of the cases with (void *). Of course this defeats type safety altogether.
Any errors will show up at run time and be in code that you didn't write.
Have fun debugging.
Cox handled generics in Objective C by just modifying the compiler so that
it won't complain if the declared type of a variable is any ancestor of the
actual type it references. Then you do generics by inventing generic types
and telling the compiler that the actual types you actually want to handle
generically are derived from those generic types. Specializations are
deferred till run time when it is easy to determine the actual type of an
object.
Sure you give up the ability to put a user defined type on the stack but you
get:
No additional code generated.
Fine control over the degree of type safety of any method by simply drawing
a tree of types and pulling your declarations off the right node.
Easy debugging and profiling.
Cleaner code
Something easier to understand and explain than templates.
For an example, look at all the enumerators there are in the the supposedly
generic STL. Objective C has precisely one, truly generic, enumerator.
Of course, none of this contradicts your point that if you want to do C++,
you have to do templates. It just makes C++, no beauty to begin with, look
less attractive.
-----= 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! =-----
Chris Gehlker wrote:
[I'd said:]
> > By "generics", presumably you mean templates. (Which can do a lot
> > more than just "generics".) They are indeed broken, but *simply*
> > broken? No, on two grounds. Firstly, they're broken in baroque and
> > confusing ways :-). Secondly, they *are*, for all that, one of the
> > key features of C++. Lots of vital things depend critically on them.
>
> I meant that they are a completely bad idea. It was very hard for me to
> accept this because I had struggled hard to master them and was really proud
> of how good I eventually became with them.
>
> One of the reasons that I eventually became disillusioned was they generate
> far too much code behind your back. Their is a tendency with templates to
> get a program that works but not well. Then, as you start profiling, you
> realize that the bottleneck is in the code that the template generated and
> you end up taking out the template and doing all that stuff by hand anyway.
> Sometimes by that time the design is too far along for you to really try a
> different approach.
I'm not convinced that this is always a problem with the language
rather than with the implementations. (Since Lisp has often been
blamed for the faults of some of its old implementations, this is
a particularly common refrain over here in c.l.l when language
wars are going on, though not usually in the interests of defending
C++!)
I bet it would be possible for a Sufficiently Smart Compiler (tm)
to avoid most of the template bloat by noticing when it's generating
the exact same code for different instantiations, and merging. But
I could easily be wrong here; I haven't thought about it deeply.
> But the bigger reason that I don't like templates is that the language could
> have gone a better way. Stroustrup is a smart guy but he let Stepanov sell
> him some snake oil. You use templates when you start repeating yourself,
> writing similar code over but changing types. The straightforward solution
> would have been to introduce a mechanism to give the programmer some control
> over how type safe she wanted each type to be, at least for they types that
> she created. Then she could achieve generality by dialing back type safety
> "just enough." But instead the C++ designers opted to automate the process
> of repeating yourself.
The prospect of making C++ *less* safe than it already is isn't one
that I find entirely attractive. There's another trick you can do,
when you're using templates for "easy" genericity, which you doubtless
know already:
class Foo_base {
// do some stuff using void* pointers
};
template<class T>
class Foo : private Foo_base {
// delegate lots of operations on T* with nasty casting,
// all inline
};
which stands firmly in the great C++ tradition of making the programmer
do work that the compiler should be able to do, but does give you many
of the type-safety benefits that come from templates without generating
lots of duplicated code. And all the evil casting is localized within
the Foo<T> template.
> Cox handled generics in Objective C by just modifying the compiler so that
> it won't complain if the declared type of a variable is any ancestor of the
> actual type it references. Then you do generics by inventing generic types
> and telling the compiler that the actual types you actually want to handle
> generically are derived from those generic types. Specializations are
> deferred till run time when it is easy to determine the actual type of an
> object.
You can do more or less *that* already in C++ too. The point of using
templates for generics is that -- allegedly! -- it eliminates tons of
runtime overhead, because there's no dynamic dispatch going on. That
this comes at the price of making you put all your code in header files
is just one more instance of a general observation about C++:
The principle "You don't pay for what you don't use", often
cited as fundamental to the design of C++, applies *only* to
paying in CPU cycles at runtime. C++ is absolutely stuffed
with design decisions that make people pay for what they don't
use, mostly in terms of development and debugging time or
source code verbosity.
> Of course, none of this contradicts your point that if you want to do C++,
> you have to do templates. It just makes C++, no beauty to begin with, look
> less attractive.
No disagreement there. :-)
--
Gareth McCaughan ················@pobox.com
.sig under construc
On 12/7/02 6:39 AM, in article ································@g.local,
"Gareth McCaughan" <················@pobox.com> wrote:
> Chris Gehlker wrote:
>
> [I'd said:]
>>> By "generics", presumably you mean templates. (Which can do a lot
>>> more than just "generics".) They are indeed broken, but *simply*
>>> broken? No, on two grounds. Firstly, they're broken in baroque and
>>> confusing ways :-). Secondly, they *are*, for all that, one of the
>>> key features of C++. Lots of vital things depend critically on them.
>>
>> I meant that they are a completely bad idea. It was very hard for me to
>> accept this because I had struggled hard to master them and was really proud
>> of how good I eventually became with them.
>>
>> One of the reasons that I eventually became disillusioned was they generate
>> far too much code behind your back. Their is a tendency with templates to
>> get a program that works but not well. Then, as you start profiling, you
>> realize that the bottleneck is in the code that the template generated and
>> you end up taking out the template and doing all that stuff by hand anyway.
>> Sometimes by that time the design is too far along for you to really try a
>> different approach.
>
> I'm not convinced that this is always a problem with the language
> rather than with the implementations. (Since Lisp has often been
> blamed for the faults of some of its old implementations, this is
> a particularly common refrain over here in c.l.l when language
> wars are going on, though not usually in the interests of defending
> C++!)
>
> I bet it would be possible for a Sufficiently Smart Compiler (tm)
> to avoid most of the template bloat by noticing when it's generating
> the exact same code for different instantiations, and merging. But
> I could easily be wrong here; I haven't thought about it deeply.
This is an intriguing idea. The current generation of compilers don't do
this, at least CodeWarrior, GCC and MSVCC don't, but there is nothing to
suggest that they can't in the future.
>> But the bigger reason that I don't like templates is that the language could
>> have gone a better way. Stroustrup is a smart guy but he let Stepanov sell
>> him some snake oil. You use templates when you start repeating yourself,
>> writing similar code over but changing types. The straightforward solution
>> would have been to introduce a mechanism to give the programmer some control
>> over how type safe she wanted each type to be, at least for they types that
>> she created. Then she could achieve generality by dialing back type safety
>> "just enough." But instead the C++ designers opted to automate the process
>> of repeating yourself.
>
> The prospect of making C++ *less* safe than it already is isn't one
> that I find entirely attractive.
It's a trade-off. You are giving up a controlled amount of type safety in
return for being able to better localize bugs at run time. There's a study
floating around saying that Objective C programs run about a third as many
lines as equivalent C++ programs. The trade off isn't static because as
debuggers get better the balance shifts in favor of the Objective C
approach. Still, if C++ could guarantee that any program that compiled would
run correctly, it would clearly win. But C++ can't come close to
guaranteeing that so the question becomes "if I relax type constraints
judiciously, are enough errors still going to get through that it is worth
it to debug templates. Experience has convinced me that about 99% of my type
errors are simple typos or total brain farts. The ObjC compiler still
catches those.
[big snip]
I've heard the kind of thing I snipped has been called the "folklore" of
C++. C++ hackers have invented and passed on a bunch clever ways of dealing
with deficiencies in the language. It's the folklore that makes C++ usable
and popular. Objective C is a much smaller language so it has much more
folklore. In particular, there are techniques for replicating all of the C++
features missing from ObjC.
>
> The principle "You don't pay for what you don't use", often
> cited as fundamental to the design of C++, applies *only* to
> paying in CPU cycles at runtime. C++ is absolutely stuffed
> with design decisions that make people pay for what they don't
> use, mostly in terms of development and debugging time or
> source code verbosity.
Amen. I don't hate C++. It's not a real fun language but you can have a lot
of fun with it. It's just too verbose.
-----= 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! =-----
From: Joe Marshall
Subject: Re: C++ templates -- was Re: Ruby style
Date:
Message-ID: <8yyznmf4.fsf@ccs.neu.edu>
Chris Gehlker <·······@fastq.com> writes:
> Still, if C++ could guarantee that any program that compiled would
> run correctly, it would clearly win. But C++ can't come close to
> guaranteeing that ...
I would have thought that at least *some* programs would run
correctly. C++ can't guarantee that *any* of them will?
I'll stick to Lisp.
Gareth McCaughan <················@pobox.com> wrote in message news:<································@g.local>...
> I'm not convinced that this is always a problem with the language
> rather than with the implementations. (Since Lisp has often been
> blamed for the faults of some of its old implementations, this is
> a particularly common refrain over here in c.l.l when language
> wars are going on, though not usually in the interests of defending
> C++!)
>
> I bet it would be possible for a Sufficiently Smart Compiler (tm)
> to avoid most of the template bloat by noticing when it's generating
> the exact same code for different instantiations, and merging. But
> I could easily be wrong here; I haven't thought about it deeply.
Actually, all it would take would be a simple post-processor that
would notice that certain blocks in the generated machine code are
identical, and so it can eliminate the duplicates and point their
symbolic labels to the same instruction. But I don't know of any C++
implementations that do even this stupid, simple thing.
It would help when the C++ programmer has already gone through the
effort to create her own template repository---a translation unit
where some template and other type declarations are brought together
and explicitly instantiated.
Under these circumstances, the template's duplicate code is all in one
object file, so the post-processor wouldn't even have to peek into
multiple files, making it a trivial filtering operation. Heck, this
could probably be hacked as a simple filer in Perl over the assembly
language output of GCC. *Duck*.
Kaz Kylheku wrote:
[I said:]
> > I bet it would be possible for a Sufficiently Smart Compiler (tm)
> > to avoid most of the template bloat by noticing when it's generating
> > the exact same code for different instantiations, and merging. But
> > I could easily be wrong here; I haven't thought about it deeply.
>
> Actually, all it would take would be a simple post-processor that
> would notice that certain blocks in the generated machine code are
> identical, and so it can eliminate the duplicates and point their
> symbolic labels to the same instruction. But I don't know of any C++
> implementations that do even this stupid, simple thing.
I conjecture that it isn't in fact that easy: virtual function
calls through the templated type may need different offsets, for
instance. You'd want a compiler that can spot when this is an
issue and do (easy) interprocedural stuff to try to put methods
(er, I mean members; sorry) with the same name in the same place,
or something like that. There are probably a few other varieties
of mildly unexpected pain. But, indeed, it doesn't feel like it
should be too hard.
> It would help when the C++ programmer has already gone through the
> effort to create her own template repository---a translation unit
> where some template and other type declarations are brought together
> and explicitly instantiated.
>
> Under these circumstances, the template's duplicate code is all in one
> object file, so the post-processor wouldn't even have to peek into
> multiple files, making it a trivial filtering operation. Heck, this
> could probably be hacked as a simple filer in Perl over the assembly
> language output of GCC. *Duck*.
Owwwwww.
--
Gareth McCaughan ················@pobox.com
.sig under construc
·······@fastq.com (Chris Gehlker) wrote on 07.12.02 in <······················@fastq.com>:
> For an example, look at all the enumerators there are in the the supposedly
> generic STL. Objective C has precisely one, truly generic, enumerator.
Oh? And here I thought NSEnumerator had lots of subclasses ...
Anyway, an NSEnumerator has only a nextObject and an allObjects method,
approximately equivalent to a C++ input iterator - nothing exists like an
output iterator, let alone the more common variants. Except, of course,
for naked pointers which do not integrate with NSEnumerator *at all*.
There's a reason C++ doesn't need to have an equivalent to NSValue.
Don't get me wrong, Objective C is a nice language - but that doesn't mean
it does much of anything better than C++.
The syntax is at least as ugly as that of C++, for example, mixing the
completely incompatible styles of C and Smalltalk[1]. And don't let me
start about NSExceptions and C preprocessor abuse!
The one thing Objective C does that C++ doesn't is Smalltalk-style
"compatibility is defined by what you implement" binding. Which can be
nice, or can be a serious efficiency and correctness problem, depending on
what you are trying to do.
Of course, you can have the worst of both worlds with Objective C++ ...
[1] If you haven't seen it, here's a small example:
Method call: [someobject myMethod: a otherParam: b andMore: c];
Function call: myfunction(someObject, a, b, c);
Yes, that really is the same language. No, you can't mix those two
styles (though you can, of course, use one as a parameter for the
other).
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery (···@stanford.edu)
On 12/8/02 5:17 AM, in article ···········@khms.westfalen.de, "Kai
Henningsen" <················@khms.westfalen.de> wrote:
> ·······@fastq.com (Chris Gehlker) wrote on 07.12.02 in
> <······················@fastq.com>:
>
>> For an example, look at all the enumerators there are in the the supposedly
>> generic STL. Objective C has precisely one, truly generic, enumerator.
>
> Oh? And here I thought NSEnumerator had lots of subclasses ...
This is absolutely correct. I thought it was a class cluster but it's a
genuine abstract class. An even more fundamental mistake was that, like C++,
you have to pay attention to the differences between the various forms, ie
dictionaries/maps are different from other containers. I still believe that
enumerators and the containers they enumerate are more orthogonal in ObjC
than in C++, but neither is perfect.
> Anyway, an NSEnumerator has only a nextObject and an allObjects method,
> approximately equivalent to a C++ input iterator - nothing exists like an
> output iterator, let alone the more common variants. Except, of course,
> for naked pointers which do not integrate with NSEnumerator *at all*.
> There's a reason C++ doesn't need to have an equivalent to NSValue.
I'm confused here. Could be this flu I'm afflicted with.
-----= 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! =-----
Gareth McCaughan wrote:
> Chris Gehlker wrote:
>
>> Compare the C++ discussion where there simply aren't syntactical
>> issues.
>
> If that's true -- which I haven't checked -- then it could easily
> be a matter of sociology rather than of language design. It certainly
> isn't true that C++ is free of syntactic difficulties. Consider
> a few of the more delightful features:
(Lots of good examples snipped).
You didn't mention my particular favourite. See this thread:
http://groups.google.com/groups?threadm=abcent%24h99ph%241%40ID-14036.news.dfncis.de
concerning this code:
template <class T, class H>
typename H::template Rebind<T>::Result& Field(H& obj)
{
return obj;
}
Jeremy.
Gareth McCaughan <················@pobox.com> writes:
> Jeremy Yallop wrote:
>
> > You didn't mention my particular favourite. See this thread:
> >
> > http://groups.google.com/groups?threadm=abcent%24h99ph%241%40ID-14036.news.dfncis.de
> >
> > concerning this code:
> >
> > template <class T, class H>
> > typename H::template Rebind<T>::Result& Field(H& obj)
> > {
> > return obj;
> > }
>
> Ooo, lovely. :-)
I wrote a post explaining one of my "favourite" C++ features, but then
I noticed that it was more complicated than I'd written and my post
got longer and longer to the point where it would have been ridiculous
in a lisp newsgroup[1] -- which is illuminating, in a way.
Cheers,
M.
[1] As in, even more ridiculously off-topic than this post.
--
(Of course SML does have its weaknesses, but by comparison, a
discussion of C++'s strengths and flaws always sounds like an
argument about whether one should face north or east when one
is sacrificing one's goat to the rain god.) -- Thant Tessman
From: Kenny Tilton
Subject: Re: Syntactic pain in C++ -- was Re: Ruby style
Date:
Message-ID: <3DF22BF7.2070204@nyc.rr.com>
Michael Hudson wrote:
> I wrote a post explaining one of my "favourite" C++ features, but then
> I noticed that it was more complicated than I'd written and my post
> got longer and longer to the point where it would have been ridiculous
> in a lisp newsgroup[1] -- which is illuminating, in a way.
No, this is important stuff. It's one thing for me to tell my boss Tom
(and hopefully soon investors) that there is no way me and another guy
could have written his system in two years with C++, but I dropped
Stroustrup and ran screaming for a dynamic language after three
chapters. wha-do-i-know?
Hearing from hardcore C++ types that things are not perfect in that
domain carries a lot more weight.
Tom is very happy with the system, demos produce rave reviews (and don't
break), he knows similar efforts by others ran for five years, cost 30
times as much, and delivered 10% of what our system does -- and he
/still/ asks me every three months or so how hard it would be to port to
C++. :)
That's the power of the herd instinct: not only is it hard to cut the
unpersuaded from the herd, even a happy user doesn't get it. Here is Tom
all safe, warm, and well-fed, but alone. He sees the herd all huddled
together out there on the barren hardtack and worries.
The problem for Lisp is that that is not about Tom, it is about human
nature. So Lispers need all the info we can get to contrast Lisp with C++.
One thing that works for me is not to say the system could not be done
in C++, rather to say two guys sitting in a kitchen, starting from
scratch, working without a spec, and with no experience in document
management could not have done it in C++. It was way too undefined a
situation; a solution had to be found over the keyboard. If we had used
C++, we would have died.
He /kinda/ buys that. :)
--
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
Gareth McCaughan <················@pobox.com> writes:
> - the fact that what should be just about the simplest operation
> imaginable -- iterating over a container -- requires you to
> write monstrous code like
>
> for (vector<T>::const_iterator i=x.begin(); i != x.end(); ++i) {
> // do some stuff with *i
> }
>
> which almost always needs further pessimization, because it's
> never really "T"; it's "double" or "pair<string,double>" or
> something. I'm afraid I quite often find myself writing
>
> for (size_t i=0; i<x.size(); ++i) {
> // do something with x[i]
> }
>
> because I just can't stand the pain of the STLically correct way.
Ah, but the politically correct way is even worse. The creators of the STL
realized that encapsulating something like "do some stuff with *i" in
a function might be a good idea (just as it is in Lisp), so all the generic
algorithms use a functional style:
void
do_some_stuff_with(vector<T>::value_type i)
{
// do some stuff with i
}
// ... far away in a totally different function ...
for_each(x.begin(), x.end(), do_some_stuff_with);
They also realized that, because C and C++ don't have nestable functions,
you must use something else if you need a closure:
class do_some_stuff_with : public unary_function<yada yada yada>
{
do_some_stuff_with(int x)
: x_(x)
{
// nothing to see here
}
void
operator()(vector<T>::value_type i)
{
// do some stuff with i and x_
}
private:
int x_;
};
// ... far away in a totally different function ...
for_each(x.begin(), x.end(), do_some_stuff_with(other_value));
Fine. But if you want to use the generic algorithms for a one-off task,
you have to define an otherwise useless class, because (a) C++ doesn't have
lambda[1], and (b) the above approach doesn't work with locally defined
classes. Duh.
Bye,
Jens.
[1] If C++ *had* lambda, the above would probably end up as something like
for_each(x.begin(),
x.end(),
lambda<void>(vector<T>::value_type i)
{
// do some stuff with x and other_value
});
Arrgh.
--
··········@acm.org phone:+49-7031-464-7698 (TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
Jens Kilian <···········@agilent.com> writes:
> C++ doesn't have lambda[1]
But it's coming ... http://www.boost.org/libs/lambda/doc/
I wept mixed tears of laughter and of pain when I first saw this.
> [1] If C++ *had* lambda, the above would probably end up as something like
>
> for_each(x.begin(),
> x.end(),
> lambda<void>(vector<T>::value_type i)
> {
> // do some stuff with x and other_value
> });
>
> Arrgh.
No, I'm afraid the meaning of that would be far too obvious.
Chris Gehlker <·······@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.
Joe Marshall <···@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)
+ Espen Vestre <·····@*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?
Harald Hanche-Olsen <······@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
Harald Hanche-Olsen <······@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)
Espen Vestre <·····@*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
In article <···············@pc150.maths.bris.ac.uk>, Michael Hudson
<···@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?
Michael Hudson <···@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)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Michael Hudson <···@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
> ;-)
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.
Edi Weitz <···@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)
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
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
Kenny Tilton <·······@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: ·············@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/
In article <··············@raw.grenland.fast.no>, Raymond Wiker
<·············@fast.no> wrote:
>a woman of 90-odd years as their bouncer.
"bouncer"
Anyone else think of a geriatric stripper wrapped around a
metal pole?
(I really need to keep these thoughts to myself.)
···@ashi.footprints.net (Kaz Kylheku) writes:
> Chris Gehlker <·······@fastq.com> wrote in message news:<······················@fastq.com>...
> > On 12/2/02 7:19 PM, in article
> > ····························@posting.google.com, "Kaz Kylheku"
> > <···@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.
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.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
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
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
On 12/2/02 1:46 PM, in article ··············@ID-167393.news.dfncis.de, "JB"
<······@hotmail.com> 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.
>
> 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.
Of course! My Ruby is version 1.67 but my CL is only at version 0.13.
-----= 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! =-----