[comp.lang.lisp] hard to write

jeff@aiai.ed.ac.uk (Jeff Dalton) (10/12/90)

In article <756@forsight.Jpl.Nasa.Gov> gat@robotics.Jpl.Nasa.Gov (Erann Gat) writes:
>> The "hard-to-write" argument is the one I hear most frequently,

>I think that the people who buy Common Lisp implementations and have to pay
>for thousands of obscure features that they never use might care about it as
>well.

Hundreds would be more accurate.  And I suppose these same people
would also complain about having to buy the whole C library.  (Vendors
may like this attitude, because it lets them justify unbundling,
something that is usually not, I suspect, revenue-neutral.)

>> I don't think Common Lisp function names are cryptic. There are a few
>> macros whose syntax is unfortunate, mostly for hysterical raisons. 
>> 
>> I keep a copy of CLTL around when I write code, mostly to check that
>> what I'm about to write isn't already part of the language. It's easy
>> to write obscure code in any Lisp.
>
>How can you be sure that what you are writing isn't already part of the
>language, but that it has an obscure name and is tucked away in a remote
>corner of Steele's tome? 

 (1) It often, perhaps even usually, doesn't hurt to implement
     something yourself.  Indeed, it may be more efficient than
     the built-in version, it you leave out some of the features.

 (2) It's a good idea to look through the book in order to get a feel
     for what it contains and where things are, rather than just look
     things up when you suspect there might be something you want.

>                          (and pity the poor programmer who spends hours
>searching through the book saying to himself, "There's just got to be a
>way to test for structures, there's just got to be! :->)

And the people who assume EQUAL must descend structures, notice
that it works in one CL, and then discover that it's not portable.
There are a number of little traps in CL, I agree.

gat@robotics.Jpl.Nasa.Gov (Erann Gat) (10/14/90)

In article <3534@skye.ed.ac.uk>, jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
> >                          (and pity the poor programmer who spends hours
> >searching through the book saying to himself, "There's just got to be a
> >way to test for structures, there's just got to be! :->)
> 
> And the people who assume EQUAL must descend structures, notice
> that it works in one CL, and then discover that it's not portable.
> There are a number of little traps in CL, I agree.

EQUAL doesn't descend structures!  That was news that sent me scurrying to
CLTL2, and indeed it is so.  But then I found the following puzzling
"Clarification":  The predicate EQUALP, it says, never descends structures
either.  (Actually what it says is that it never recursively descends
any structure or data type other than conses, arrays and pathnames.)  It
then goes on (on p. 109) to describe how EQUALP compares structures!  So
can you compare structures or not?

E.

moore%cdr.utah.edu@cs.utah.edu (Tim Moore) (10/15/90)

-1~
In article <761@forsight.Jpl.Nasa.Gov> gat@robotics.Jpl.Nasa.Gov (Erann Gat) writes: 
>
>EQUAL doesn't descend structures!  That was news that sent me scurrying to
>CLTL2, and indeed it is so.  But then I found the following puzzling
>"Clarification": The predicate EQUALP, it says, never descends structures
>either.  (Actually what it says is that it never recursively descends
>any structure or data type other than conses, arrays and pathnames.)  It
>then goes on (on p. 109) to describe how EQUALP compares structures!  So
>can you compare structures or not?
>
>E.
Organization: University of Utah CS Dept
References: <1990Oct10.130925.18317@hellgate.utah.edu> <756@forsight.Jpl.Nasa.Gov> <3534@skye.ed.ac.uk> <761@forsight.Jpl.Nasa.Gov>

EQUALP should compare DEFSTRUCT structures as described on p. 109. The
translation from X3J13 cleanup issue to CLtL2 was somewhat garbled,
possibly because the cleanup issue was revised several times. Also,
there is some overloading of the term "structure"; in the early parts
of equalp's description it means "any structured datatype with
components", whereas on p.109 it means "DEFSTRUCT object". The cleanup
issue uses more consistent terminology.

Tim Moore                    moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Ah, youth. Ah, statute of limitations."
		-John Waters