Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: STRUCTUREP
Message-ID: <3564@skye.ed.ac.uk>
Date: 17 Oct 90 18:32:45 GMT
References: <753@forsight.Jpl.Nasa.Gov> <27133D6E.715C@marob.masa.com> <755@forsight.Jpl.Nasa.Gov> <2714943B.1332@marob.masa.com>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 66

In article <2714943B.1332@marob.masa.com> cowan@marob.masa.com (John Cowan) writes:

>Erann Gat writes:

>>Oh, come on!  Since the implementation gets to define structurep, it
>>can make explicit checks to exclude other types which the implementation
>>implements as structures.  It may not be pretty or efficient, but it's
>>certainly not impossible!
>
>The point is that the non-existence of STRUCTUREP allows freedom to the
>implementor to make certain choices.  Structures are a "raw" construct
>in CL, with very few specific semantics (see below).

Yes, it allows certain choices.  But are they choices worth allowing?

Earlier you write:

   [No; standard types can be implemented as structures]

Why is *that* a problem?  It looks like you're talking about
a different aspect of the structure issue in this message.
Anyway ...

It's a pain that one cannot determine whether an object is a structure
and find out what slots it has.  For example, you may want to write a
print function that works like the normal one in somce cases but not
in others.  You can't, because the information needed for the normal
case isn't available in portable form.  (Yes, this is the same example
given before.)

A number of people have written their own macro, on top of DEFSTRUCT,
just to provide such capabilities.  Note that (1) they can do this,
and (2) the implementation has the same freedom it had before.

(BTW, I'm glad to hear you've implemented a T in CL.  Good idea.)

>My point is that Common Lisp structures >aren't< T structures, and aren't
>meant to be.  CL structures are a layer of syntactic sugar that allow you
>to define handy {access, construct, print} functions, and take care of
>some of the work.  The underlying datatype can be a list, a vector, or
>a MacLisp hunk (i.e. a cons with != 2 components).  The "hunk-level"
>access provided in MacLisp is not standardized by CL, so you can't reliably
>get at it, and implementers who think they can do better than hunks are
>free to do so.  CL is not designed to require retaining any meta-information
>at run time about structures, except for what is needed by debugging
>tools (inspector, etc.) whose interfaces are not standardized.

1. STRUCTUREP should probably be true only of structures defined 
   without using the :TYPE option.  (N.B. that prevents the name
   from being a valid type specifier.)

2. DEFSTRUCT defines the name as a type specifier, defines a
   predicate, and causes a certain syntax to be used when printing.
   This suggests that structures can be recognized with a fair degree
   of reliability.  STRUCTUREP would have the same reliability (or
   lack of it), but it shouldn't be harder to provide STRUCTUREP than
   to provide the predicates.

3. CLtL II says structure types created by DEFSTRUCT must be disjoint
   from (among other types) CONS and ARRAY.  So the freedom to make
   the underlying type be a list or vector has been removed.

-- Jeff