Path: utzoo!utgpu!attcan!uunet!husc6!rutgers!njin!princeton!phoenix!eliot
From: eliot@phoenix.Princeton.EDU (Eliot Handelman)
Newsgroups: comp.lang.lisp
Subject: Re: #< syntax
Message-ID: <3394@phoenix.Princeton.EDU>
Date: 4 Aug 88 19:28:34 GMT
References: <3387@phoenix.Princeton.EDU> <24911@think.UUCP>
Reply-To: eliot@phoenix.Princeton.EDU (Eliot Handelman)
Distribution: na
Organization: Princeton University, NJ
Lines: 96

In article <24911@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes:
>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."

[some discussion concerning print representations of streams, hash-tables
 and compiled functions.]

Barry, I agree that I, personally, can't think of any reason why I would
want to read the print representation of a stream, but maybe somebody else
could. My problem is not having access to certain types of objects, like
lambda-bindings.

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

The problem is reading a lambda expression, or treating it as a piece of
data, not what gets printed out when I type in a definition. In KCl,
for example, I can treat #'foo as a list. I haven't found out how to do
so in Lucid, which uses #< syntax, because lambda-bindings are treated
as objects of type procedure. 

I think you'll agree that occassionaly you might like to look at a definition
from the interpreter, particularly if it had been written by some other
procedure. Or you may even want to print the definition to file. If
the lambda-binding can be treated as a list, even if it's been syntactically
altered (making the car of the list LAMBDA-BLOCK, for example), I can
always hack it so that it becomes readable, and either look at it or whatever.
But #< does not allow me to touch it. Here is a fabricated example that
ought to show just what I mean, in Franz Lisp, KCl, and a #< syntax lisp. The
problem is to replace the global 'DOG with 'CAT in a procedure called DOG.


Franz Lisp, Opus 38.79
-> (defun dog () 'DOG)
dog
-> (putd 'dog (subst 'CAT 'DOG (getd 'dog)))
(lambda nil
        'CAT)
-> (dog)
CAT

----

KCl (Kyoto Common Lisp)  June 3, 1987

> (defun dog () 'dog)
DOG

> #'dog
(LAMBDA-BLOCK DOG () 'DOG)

> (defun getd (f) `(lambda ,@(cddr (symbol-function f))))
GETD

> (getd 'dog)
(LAMBDA () 'DOG)

> (setf (symbol-function 'dog) (subst 'CAT 'DOG (getd 'dog)))
(LAMBDA () 'CAT)

> (dog)
CAT

----

The next example is from a lisp that uses #< syntax.

> (defun dog () 'dog)
DOG

> #'dog
#<Interpreted-Function (NAMED-LAMBDA DOG NIL (BLOCK DOG 'DOG)) 4BF8D7>

> (cdr #'dog)
>>Error: #<Interpreted-Function (NAMED-LAMBDA DOG NIL (BLOCK DOG (QUOTE DOG))) 4BF8D7> should be of type LIST


----

Of course, the compiler, at least, has to be able to treat #'dog as a readable
object (I assume). That means that in some way it is readable, and that I'm
arbitrarily being prevented from having it read by one of my own procedures,
or by knowing what secret the compiler uses to get at this data.


- Eliot