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

In article <25254@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes:

[I bring up the problem of getting at a lambda-binding in #< lisps.]

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

That's absolutely true. The difference between hash tables and procedures
is that Steels tells me how to access hash tables and doesn't indicate
how I can access lambdas. I don't care how an object prints. But I have to
know how to read it.

All that I'm saying is that I think it's contrary to the nature of lisp
to decide who's going to use it, and why, and what they're going to do with
it. My code may be very idiosyncratic, but so what? So what if I do things
in a way that earlier lisps with greater flexibilty allowed, but all of
a sudden not CL? I happen to like walking code -- what's wrong with that?


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

Steele says of DISASSEMBLE: "This ... is often of use to the novice 
who wishes to understand the workings of compiled code." It's interesting
that CL forsaw having a function whose use was purely pedadogical. (He
also says that this is useful for debugging the compiler, but that alone
wouldn't justify putting the function in USER.) If I may answer your question
quite modestly -- if DISSASSEBLE exists then GRINDEF (or whatever) ought to
be made public too, if only for purely pedagogical reasons. 

I think this point is too important to overlook. Winston and Horn have their
M-LISP interpreter at the end of their book. Can you write decent lisp code
without *really* understanding how (say) the read-eval-print loop works?
Isn't there a near isomorphy between lisp implementors and lisp programmers?

To answer your question directly, I don't try to walk compiled code,
but I see that as my problem. Why is a system that can analyze what another
lisp system would do IF it were run inconceivable? I think you SHOULD be able
to analyze compiled code, too.

>One of Common Lisp's goals was to define a language that produces
>equivalent programs whether they are compiled or interpreted. 

Why, was it ever the case that compiled programs behaved differently from
interpreted? What lisp in particular?

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

Ok, but I don't see what this has to do with #< notation.

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

That's true. Point is, what difference should it make what you call
the first element, LAMBDA-BLOCK, NAMED-LAMBDA, DIGESTED-LAMBDA or
whatever? Why not push for standardization? I mean, everybody has
already agreed on the lambda part, which is of no more than historical
significance, anyway.

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

Of course I could do that, but it's ugly. I think what that leads to is writing
my own interpreter, with my own version of anything that does surgery,
so that I can keep an accessible copy around. Then if I want to make changes,
I have to make twice as many as before. It's a trivial problem, but it's an
improvised solution to somthing that ought to handled more generally.

>The function cell is not a general-purpose storage location.

A procedure is a piece of data, whether or not it has its own special
set of accessors. Besides which, I would imagine that this view
is anathema to your company's ideology, that of the identity of the processor
and memory.

>Barry Margolin
>Thinking Machines Corp.

Eliot Handelman
Dep't of Music
Princeton University