"Julian Morrison" <······@extropy.demon.co.uk> wrote in message
······································@news.demon.co.uk...
> (warning: this post might spark a language war; if you hate language wars,
> set the "ignore")
>
> Please tell me the parts of (1)Common Lisp (2) Scheme that are "broken as
> designed".
>
> The reason I ask about the faults is: the good stuff is pretty easy to
> spot by reading the spec, but design faults can be pretty subtle (which is
> why they got in there in the first place, obviously).
Well after all the bickering that's been going on, plus
the fact that I'm a newbie, I'm hesitant to point out
what's been in manuals for years.
CL-USER 2 : 1 > (eq nil (not t))
T
CL-USER 3 : 1 > (eq nil '())
T
CL-USER 4 : 1 > (eq nil ())
T
CL-USER 5 : 1 > (eq nil 0)
NIL
I don't care what you say, this is buggered. Not that I
have a fix, but one of `values' major pluses was that it
allowed functions to distinguish between some of the cases.
Skipping the fact that (= 3 3 3) works but (eq 3 3 3) and
the rest of the ilk fail because they don't take multiple
arguments.
Geoff
From: Tim Moore
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <98b6b7$790$0@216.39.145.192>
On Fri, 9 Mar 2001, Geoffrey Summerhayes wrote:
> Well after all the bickering that's been going on, plus
> the fact that I'm a newbie, I'm hesitant to point out
> what's been in manuals for years.
>
> CL-USER 2 : 1 > (eq nil (not t))
> T
> CL-USER 3 : 1 > (eq nil '())
> T
> CL-USER 4 : 1 > (eq nil ())
> T
> CL-USER 5 : 1 > (eq nil 0)
> NIL
>
> I don't care what you say, this is buggered. Not that I
I like it :) This has the potential to turn into another rabid
flame-fest, but the equivalence of nil and the false value is a great
convenience, especially in a language where iterating (or recursing, or
tail-recursing... whatever floats your boat) over lists is fundamental and
the end-of-list is a distinguished condition.
As to whether or not 0 should be allowed to join in on the bottom, I
think Common Lisp has struck the right balance by not making it false (Do
*any* Lisps, and I use "Lisp" in the broadest sense of the word, make 0 be
false?) In languages like Perl where undef and 0 (and most egregiously,
the string "0"!) are all false, you basically have to give up on shorthand
and use explicit tests for undefinedness everywhere, essentially putting
you back in the same situation as if there was only #f and that isn't used
as a marker in data structures.
> have a fix, but one of `values' major pluses was that it
> allowed functions to distinguish between some of the cases.
Doesn't seem to me that using 0 return values as an indicator of falsehood
is ever going to take off in the Common Lisp world.
Tim
"Tim Moore" <·····@herschel.bricoworks.com> wrote in message
·················@216.39.145.192...
>
>
> Doesn't seem to me that using 0 return values as an indicator of falsehood
> is ever going to take off in the Common Lisp world.
>
To be honest, the 0 test was a last minute addition to the message just
before posting. I threw it in for completeness since a lot of languages
don't make the distinction.
From: Boris Smilga
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <kfsnkmkb3e.fsf@rome.bhasha.com>
"Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> writes:
> "Tim Moore" <·····@herschel.bricoworks.com> wrote in message
> ·················@216.39.145.192...
> >
> >
> > Doesn't seem to me that using 0 return values as an indicator of falsehood
> > is ever going to take off in the Common Lisp world.
> >
>
> To be honest, the 0 test was a last minute addition to the message just
> before posting. I threw it in for completeness since a lot of languages
> don't make the distinction.
Note that the default convention in Unix shells is the opposite: 0
means True, anything else means False. Which is very ironic, from some
point of view.
-BSm
From: Tim Moore
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <98bbmf$igu$0@216.39.145.192>
On 9 Mar 2001, Boris Smilga wrote:
> "Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> writes:
>
> > "Tim Moore" <·····@herschel.bricoworks.com> wrote in message
> > ·················@216.39.145.192...
> > >
> > >
> > > Doesn't seem to me that using 0 return values as an indicator of falsehood
> > > is ever going to take off in the Common Lisp world.
> > >
> >
> > To be honest, the 0 test was a last minute addition to the message just
> > before posting. I threw it in for completeness since a lot of languages
> > don't make the distinction.
To be clear, I meant "0 return values" in the sense of "no return values"
i.e., (values).
> Note that the default convention in Unix shells is the opposite: 0
> means True, anything else means False. Which is very ironic, from some
> point of view.
Yup, and within C on Unix a return value of 0 often means success or true
while a return value of the null pointer, which may or may not have the
bit pattern of 0, almost universally means false or failure. Go figure...
Tim
"Tim Moore" <·····@herschel.bricoworks.com> wrote in message
·················@216.39.145.192...
>
> To be clear, I meant "0 return values" in the sense of "no return values"
> i.e., (values).
>
Judging from the reponses, I haven't made myself clear either.
Although, after re-reading your post, I realized I'd misread
the section I'd quoted, my apologies. It's not the use of any of
them (possibly 0) in an if statement, or a cond, or whatever expects
a logical argument, even `not'.
That kind of coercion is convenient, not necessary, but convenient.
It's the fact that I can't distinguish (eq,eql,etc.) between them
without another argument. I know I can work around it. I know it's
unlikely to change, an implementors nightmare, and it would probably
break a lot of programs if it did. But, the OP was looking for design
flaws, IMHO this is one.
Hell, it's worse in other languages, take C/C++, they finally
introduced a bool type, and the informal 'style guide' is now
saying to use if(NULL!=f()), etc. and use if(f()) iff f() returns
type bool. You folks should be proud that's all a rank newbie
has to pick on, at least I didn't mention the fact that loop
syntax reminds me of VB.(Whoops, now I know I'm treading on dangerous
ground. Strictly my thoughts, I am certainly wrong.)
Sorry for the f() stuff, I like alliteration,
Geoff
Oh, for f*ck's sake, I forgot to forgo using f's :-)
From: Kent M Pitman
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <sfwzoeug0sv.fsf@world.std.com>
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
Tim Moore <·····@herschel.bricoworks.com> writes:
> As to whether or not 0 should be allowed to join in on the bottom, I
> think Common Lisp has struck the right balance by not making it false (Do
> *any* Lisps, and I use "Lisp" in the broadest sense of the word, make 0 be
> false?)
The MOO language allows 0, empty strings, and empty lists, and errors to be
false to be false. This works out surprisingly well in code and feels quite
clean once one gets used to it. (MOO screws up and makes the OBJ class,
sort of like our standard-class, also false, and that feels wrong as you
might imagine, but it's hard to retrofit a fix now that there's tons of
shared code deployed.) Anyway, I think what Lisp does is defensible, but
I think there are a variety of other workable choices in the same space.
From: Christopher Stacy
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <ud7bq7lwq.fsf@spacy.Boston.MA.US>
(OR (CDR (ASSOC 'PUN (FIND-SOMETHING)))
"You don't program in Lisp, do you?")
"Christopher Stacy" <······@spacy.Boston.MA.US> wrote in message
··················@spacy.Boston.MA.US...
>
> (OR (CDR (ASSOC 'PUN (FIND-SOMETHING)))
> "You don't program in Lisp, do you?")
<Chuckle/> The 'newbie' part didn't give that away, eh?
Geoff
In article <·························@news20.bellglobal.com>,
Geoffrey Summerhayes <·············@hNoOtSmPAaMil.com> wrote:
>
>"Julian Morrison" <······@extropy.demon.co.uk> wrote in message
>······································@news.demon.co.uk...
>> (warning: this post might spark a language war; if you hate language wars,
>> set the "ignore")
>>
>> Please tell me the parts of (1)Common Lisp (2) Scheme that are "broken as
>> designed".
>>
>> The reason I ask about the faults is: the good stuff is pretty easy to
>> spot by reading the spec, but design faults can be pretty subtle (which is
>> why they got in there in the first place, obviously).
>
>Well after all the bickering that's been going on, plus
>the fact that I'm a newbie, I'm hesitant to point out
>what's been in manuals for years.
>
>CL-USER 2 : 1 > (eq nil (not t))
>T
>CL-USER 3 : 1 > (eq nil '())
>T
>CL-USER 4 : 1 > (eq nil ())
>T
>CL-USER 5 : 1 > (eq nil 0)
>NIL
>
The big problem here, from my point of view, is that there is no obvious
way to distinguish between a function returning an empty list with one
returning nil. Assume you have a function returning a list of common
words in a phrase, and you want some sort of error indicator if there is
no string giving a phrase:
(foo "A coconut")
=> ("A")
(foo "Buffalo buffalo buffalo")
=> empty list
(foo 42)
=> error indication
- and so you can't use nil for the error indication.
Of course, sometimes you want a return of a zero-length list to mean
false, but in that case you could always write some sort of test for
it (consp?). I consider this the biggest broken thing in Common Lisp.
>I don't care what you say, this is buggered. Not that I
>have a fix, but one of `values' major pluses was that it
>allowed functions to distinguish between some of the cases.
>Skipping the fact that (= 3 3 3) works but (eq 3 3 3) and
>the rest of the ilk fail because they don't take multiple
>arguments.
>
I would say that that is also broken (although IIRC the result
of (eq 3 3) is unspecified, and so a better analogy would be
(eq foo bar baz)).
And let us not forget the problem with the keyword arguments in
READ-FROM-STRING.
Not that any of these problems are going to make me go out and
install Scheme, you understand.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
From: Barry Margolin
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <Ukdq6.46$%h5.23767@burlma1-snr2>
In article <··················@ruti.visi.com>,
David Thornley <········@visi.com> wrote:
>The big problem here, from my point of view, is that there is no obvious
>way to distinguish between a function returning an empty list with one
>returning nil. Assume you have a function returning a list of common
>words in a phrase, and you want some sort of error indicator if there is
>no string giving a phrase:
There are two common solutions:
1) Return multiple values. The first value is the result, and the second
is a boolean. An example of this is GETHASH. The second value is a
boolean that allows you to determine whether the first result came from
the hash table or the default.
2) Signal a condition to indicate failure. The READ function works like
this, unless you set the EOF-ERROR-P argument to NIL (in which case
you're on your own to distinguish EOF from reading the EOF-VALUE, which
defaults to NIL).
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> In article <··················@ruti.visi.com>,
> David Thornley <········@visi.com> wrote:
> >The big problem here, from my point of view, is that there is no obvious
> >way to distinguish between a function returning an empty list with one
> >returning nil. Assume you have a function returning a list of common
> >words in a phrase, and you want some sort of error indicator if there is
> >no string giving a phrase:
>
> There are two common solutions:
>
> 1) Return multiple values. The first value is the result, and the second
> is a boolean. An example of this is GETHASH. The second value is a
> boolean that allows you to determine whether the first result came from
> the hash table or the default.
>
> 2) Signal a condition to indicate failure. The READ function works like
> this, unless you set the EOF-ERROR-P argument to NIL (in which case
> you're on your own to distinguish EOF from reading the EOF-VALUE, which
> defaults to NIL).
Note that (2) is the response that you usually get from a ML
programmer.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Kent M Pitman
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <sfwelw5pl8b.fsf@world.std.com>
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Barry Margolin <······@genuity.net> writes:
>
> > In article <··················@ruti.visi.com>,
> > David Thornley <········@visi.com> wrote:
> > >The big problem here, from my point of view, is that there is no obvious
> > >way to distinguish between a function returning an empty list with one
> > >returning nil. Assume you have a function returning a list of common
> > >words in a phrase, and you want some sort of error indicator if there is
> > >no string giving a phrase:
> >
> > There are two common solutions:
> >
> > 1) Return multiple values. The first value is the result, and the second
> > is a boolean. An example of this is GETHASH. The second value is a
> > boolean that allows you to determine whether the first result came from
> > the hash table or the default.
> >
> > 2) Signal a condition to indicate failure. The READ function works like
> > this, unless you set the EOF-ERROR-P argument to NIL (in which case
> > you're on your own to distinguish EOF from reading the EOF-VALUE, which
> > defaults to NIL).
>
> Note that (2) is the response that you usually get from a ML
> programmer.
Btw, maybe this is a good chance to shamelessly re-promote my paper
"Exceptional Situations in Lisp" for peoplpe who haven't read it.
It goes into these and other options in greater detail.
http://world.std.com/~pitman/Papers/Exceptional-Situations-1990.html
From: Neelakantan Krishnaswami
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <slrn9alv6f.7hm.neelk@alum.mit.edu>
On 10 Mar 2001 12:42:48 -0500, Marco Antoniotti <·······@cs.nyu.edu> wrote:
>Barry Margolin <······@genuity.net> writes:
>>
>> There are two common solutions:
>>
>> 1) Return multiple values. The first value is the result, and the second
>> is a boolean. An example of this is GETHASH. The second value is a
>> boolean that allows you to determine whether the first result came from
>> the hash table or the default.
>>
>> 2) Signal a condition to indicate failure. The READ function works like
>> this, unless you set the EOF-ERROR-P argument to NIL (in which case
>> you're on your own to distinguish EOF from reading the EOF-VALUE, which
>> defaults to NIL).
>
> Note that (2) is the response that you usually get from a ML
> programmer.
FWIW, when hacking in ML I find it much easier to use the option type
rather than throwing an exception. The option type is a builtin sum
type that looks like this:
datatype 'a option = NONE | SOME of 'a;
This is partly because ML's pattern matching is more convenient than
its exception-handling forms, and partly because the compiler will
warn me at compile time if I don't handle the possibility of getting
NONE as a value. (It will issue a nonexhaustive match warning, but
still compile -- the perfect balance between static and dynamic
typing, IMO. :)
Neel
In article <··················@burlma1-snr2>,
Barry Margolin <······@genuity.net> wrote:
>In article <··················@ruti.visi.com>,
>David Thornley <········@visi.com> wrote:
>>The big problem here, from my point of view, is that there is no obvious
>>way to distinguish between a function returning an empty list with one
>>returning nil. Assume you have a function returning a list of common
>>words in a phrase, and you want some sort of error indicator if there is
>>no string giving a phrase:
>
>There are two common solutions:
>
>1) Return multiple values. The first value is the result, and the second
>
>2) Signal a condition to indicate failure. The READ function works like
>
Yup, and I find both of them more awkward than having a false value
that isn't equal to the empty string would be. For one thing, neither
of these is going to work well with some of the MAPs. As I said, this
is not the sort of thing that will make me turn to Scheme, but I find
it more annoying than anything else about Common Lisp.
Anybody know if this was a deliberate design decision, or a hangover
from old practices?
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
········@visi.com (David Thornley) writes:
> In article <··················@burlma1-snr2>,
> Barry Margolin <······@genuity.net> wrote:
> >In article <··················@ruti.visi.com>,
> >David Thornley <········@visi.com> wrote:
> >>The big problem here, from my point of view, is that there is no obvious
> >>way to distinguish between a function returning an empty list with one
> >>returning nil. Assume you have a function returning a list of common
> >>words in a phrase, and you want some sort of error indicator if there is
> >>no string giving a phrase:
> >
> >There are two common solutions:
> >
> >1) Return multiple values. The first value is the result, and the second
> >
> >2) Signal a condition to indicate failure. The READ function works like
> >
> Yup, and I find both of them more awkward than having a false value
> that isn't equal to the empty string would be.
There are a myriad of other options:
You could specify a value that is returned should the answer be false,
or conversely a value to return should the answer be empty.
You could return a *list* of the answer. An empty list is easily
distinguished from a list containing a single NIL, yet CAR and CDR on
such are the same.
You could even write the code in `continuation-passing-style', though
if you find multiple-values to be awkward, you won't be too enamoured
of this approach.
I don't understand what you are getting at. If there is a difference
between an erroneous situation and a situation involving an empty
list, then you shouldn't try to use the empty list for both purposes.
But if there is *no* difference between the two, then what does it
matter?
> For one thing, neither of these is going to work well with some of
> the MAPs.
Presumably this is good! You wouldn't want code further down the line
to be unable to distinguish between the empty list an an error.
> As I said, this is not the sort of thing that will make me turn to
> Scheme, but I find it more annoying than anything else about Common
> Lisp.
I don't see how you would do this differently in Scheme. The
difference there is that the empty list and false are supposed to be
distinguishable. While this would allow you to return false to
indicate error, and the empty list for non-erroneous, but null,
responses, it would still cause you problems when you tried to use
MAP.
-----= 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! =-----
········@visi.com (David Thornley) writes:
> The big problem here, from my point of view, is that there is no
> obvious way to distinguish between a function returning an empty
> list with one returning nil.
I'm afraid that *I* find no obvious distinction between the two. The
empty list *is* nil.
> Assume you have a function returning a list of common words in a
> phrase, and you want some sort of error indicator if there is no
> string giving a phrase:
>
> (foo "A coconut")
> => ("A")
>
> (foo "Buffalo buffalo buffalo")
> => empty list
>
> (foo 42)
> => error indication
>
> - and so you can't use nil for the error indication.
Right. The error handler comes in handy for this sort of thing.
-----= 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! =-----