Path: utzoo!attcan!uunet!husc6!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: #< syntax
Message-ID: <25254@think.UUCP>
Date: 6 Aug 88 18:57:58 GMT
References: <3387@phoenix.Princeton.EDU> <24911@think.UUCP> <3394@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: 52

In article <3394@phoenix.Princeton.EDU> eliot@phoenix.Princeton.EDU (Eliot Handelman) writes:
>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. 

First of all, you are confusing two completely unrelated concepts.
The fact that some types are printed with #< syntax has absolutely
nothing to do with whether there are mechanisms for accessing the
components of the object.  Hash tables print with #< syntax, but you
can still access the contents.  And there are types with readable
printed representations that DON'T allow you to access the contents
(RANDOM-STATE is the one I can think of).

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

And what do you expect this to do if DOG is compiled before the PUTD?
One of Common Lisp's goals was to define a language that produces
equivalent programs whether they are compiled or interpreted.  The
implementations that use an special type for interpreted functions are
actually helping you out, since the interpreter will catch an error
that might have remained unnoticed until you tried the program
compiled.  In fact, it might not even be caught in compiled code,
because the compiled code for SUBST might not do any type checking;
you might just dump core or something.

Even among implementations that store interpreted definitions as lists
in the function cell there can be much variety.  On a Symbolics
machine, DEFUN will store a list beginning with SI:DIGESTED-LAMBDA,
and the actual lambda expression will be just one element.  There is
currently no portable way to access the interpreted definition of a
function.

If you have programs that construct interpreted definitions and then
want to be able to access these definitions, you should have them
store them somewhere else in addition to (or instead of) the function
cells of symbols.  The function cell is not a general-purpose storage
location.

Barry Margolin
Thinking Machines Corp.

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