Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!cdr.utah.edu!moore
From: moore%cdr.utah.edu@cs.utah.edu (Tim Moore)
Newsgroups: comp.lang.lisp
Subject: Re: STRUCTUREP
Message-ID: <1990Oct10.165312.29838@hellgate.utah.edu>
Date: 10 Oct 90 22:53:12 GMT
References: <753@forsight.Jpl.Nasa.Gov> <1990Oct10.091722.4495@hellgate.utah.edu> <1990Oct10.130925.18317@hellgate.utah.edu> <756@forsight.Jpl.Nasa.Gov>
Organization: University of Utah CS Dept
Lines: 70

In article <756@forsight.Jpl.Nasa.Gov> gat@robotics.Jpl.Nasa.Gov (Erann Gat) writes:
>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.

OK, I have. It looks like callable objects are an abstraction of the
objects-as-closures style that has appeared in other articles today.
Nice as far as that style of object-oriented programming goes.

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

Lisp Pointers is a periodical that is published irregularly. It is now
a publication of the ACM.

>> 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!)
>

It's true that there aren't any facilities for getting at the slots of
an arbitrary structured type (unless you have the source of the
defstruct). I don't know whether this is good or bad. slots of a
structured type must exist somewhere in the system in order to support
inheritance in a practical manner.

It seems like a bad idea to overide a structure's print function,
unless you are handling *print-circle*, *print-length*, etc. You might
get a nasty surprise. You could print the object to a string and
strip the #S...

>> 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! :->)

I use the index. It's not much different from browsing the Unix
manuals for C libraries. Also, experience helps, as with any large
language or system.
Tim Moore                    moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Ah, youth. Ah, statute of limitations."
		-John Waters