Path: utzoo!attcan!uunet!jarthur!elroy.jpl.nasa.gov!forsight!gat
From: gat@robotics.Jpl.Nasa.Gov (Erann Gat)
Newsgroups: comp.lang.lisp
Subject: Re: STRUCTUREP
Message-ID: <756@forsight.Jpl.Nasa.Gov>
Date: 10 Oct 90 20:43:15 GMT
References: <753@forsight.Jpl.Nasa.Gov> <1990Oct10.091722.4495@hellgate.utah.edu> <1990Oct10.130925.18317@hellgate.utah.edu>
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 68

In article <1990Oct10.130925.18317@hellgate.utah.edu>, moore%cdr.utah.edu@cs.utah.edu (Tim Moore) writes:
> In article <754@forsight.Jpl.Nasa.Gov> gat@robotics.Jpl.Nasa.Gov (Erann Gat) writes:
> >You are right, of course.  However, there are a number of things that you
> >can do in T which you can't do in Common Lisp.  Among these are:
> >
> >1.  Create callable objects (which allow you to do things like SETF a locative
> >passed to a function as an argument)
> 
> I'm not sure what you mean by this.

See chapter 7 of the T manual.

> If you mean that T has locatives,

No, I mean callable objects.  (See note above.)

> it's not hard to simulate locatives in Common Lisp (see Lisp Pointers,
> vol. 2 no. 2); they're just closures that encapsulate the information

This sounds like a handy book.  Where do I find it?

> It's unclear why you want to do this. Only system code should really
> need a structurep.

There are dozens of applications I can think of for structurep.  My particular
reason is that I have a stream to which I wish to print arbitrary objects
but on which it is important that no #S read macros appear.  (The reason
for that is too lengthy to go into here, and entirely beside the point in
any case.)  Therefore, I need to be able to tell if the object I am about
to print out is a structure so that I can intercept the print function.
(And yes, I know about the :print-function option to defstruct.  I want
to be able to print out structures created by other people as well!)

> >Personally, I think that it's the "and much more" part that is Common
> >Lisp's biggest problem.  It's getting to the point where it is very difficult
> >to get a grip on the entire language.  Not only does this make CL hard to
> >write, it encourages writing code that is nearly impossible to read without
> >a copy of CLTL in hand (and sometimes even then).  (It also makes it harder
> >to tell when some crtitical feature has been omitted from the language :->)
> 
> The "hard-to-write" argument is the one I hear most frequently,
> especially around here (where we are close to finishing a CL
> implementation). I think only a handful of people (Lisp implementors)
> really care about this.

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.

> 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?  I tend to discover surprizing new features of
CL on a fairly regular basis (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! :->)

> >Just my opinion.
> That's what the net is for!
Thanks.

E.