Path: utzoo!utgpu!water!watmath!clyde!ima!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: #< syntax
Message-ID: <24911@think.UUCP>
Date: 4 Aug 88 04:35:16 GMT
References: <3387@phoenix.Princeton.EDU>
Sender: usenet@think.UUCP
Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin)
Distribution: na
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 42

In article <3387@phoenix.Princeton.EDU> eliot@phoenix.Princeton.EDU (Eliot Handelman) writes:
>"It is specifically and purposely NOT required that a CL implementation
>be able to print an object of type hash-table, readtable, package, stream or
>function in a way that can be successfully read back in by read; the
>use of #< syntax is especially recommended for the printing of such objects."
>
>What's the motive behind this, or is there one?

Mostly it is because the Lisp implementations that Common Lisp was
derived from didn't print these things readably, and there was no
strong reason to make them readable.  There has been some recent
discussion about defining a readable printed representation for hash
tables, though.  In general, though, printed representations are
defined for objects that a user might be likely to type in manually,
or which might be written to a text file and read back in in another
session.  Neither is likely for a stream object, and users are not
likely to want to type in the others.  They are frequently quite large
and/or complex; for example, the printed representation of a package
would have to include all the symbols in the package, and the printed
representation of a stream would have to include all its state (some
of which would be obsolete if you read it in after doing some I/O to
the stream).  A compiled function's printed representation would have
to be designed so that it could be linked in properly when read back
in.  If you were to type in the printed representation of a stream
connected to a file that is not currently open, would it open the
file?

>Isn't one of the main things 
>about lisp the uniformity of data and procedures?

What does the uniformity of data and procedures have to do with
printed representations?  The point of the uniformity feature is that
a program can construct other programs and then execute them, i.e.
procedures (usually lambda expressions) are made out of the same stuff
that data is.  Why do you think that this implies that you should be
able to type in objects of all data types?

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar