Path: utzoo!utgpu!attcan!uunet!husc6!purdue!bouma
From: bouma@cs.purdue.EDU (William J. Bouma)
Newsgroups: comp.lang.lisp
Subject: Re: #< syntax
Summary: functions in Common Lisp
Keywords: lambda
Message-ID: <4625@medusa.cs.purdue.edu>
Date: 5 Aug 88 20:39:50 GMT
References: <3387@phoenix.Princeton.EDU> <24911@think.UUCP> <3394@phoenix.Princeton.EDU>
Distribution: na
Organization: Department of Computer Science, Purdue University
Lines: 68

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

     [ junk about being able to read all Lisp objects deleted ]

     I agree with barmar that there is a bunch of Lisp data structures which
  should never need to be  printed/read  by any normal lisp user. Typing in
  hash tables does not sound practical or appealing. But that doesn't seem to
  be the real issue here:

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

     If you want to treat a lambda list as a piece of data, make it one
  explicitely:

  (setq plusl '(lambda (x y) (+ x y)))

  Once you allow whatever interpreter you are using to get hold of it, there
  is no guarentee that the internal representation it uses will make any sense
  to a human:

  (setq plusf #'(lambda (x y) (+ x y)))

  I believe a funcall on either of these will work. But the price you pay is
  slower execution speed for plusl since it first has to be converted into
  the internal rep before it can be run.

  Of course the Lisp you are using could keep around the original lambda list
  that the function came from and just print that out when you asked to print
  the function. Or it could even have a "de-interpreter" that changes the 
  internal format back to one it can print. But there is nothing in lisp that 
  says it HAS to do this.


>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

     Again, what you want is some kind of de-compiling tool. KCL either just
  keeps its functions in this list format or does a de-compiling for you when
  it prints it out. If you want to have functions that modify other functions
  you should keep them as lambda LISTs. Why would you want to modify someone
  elses function at such a low level? Try modifying the source code.

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

     It is no secret, and it is only arbitrary in the sence that any lisp
  implementation is free to this its own way. The compiler can probably read
  the internal representation and make sense out of it. This is something you,
  being a mere mortal, cannot yet do.

-- 
Bill <bouma@medusa.cs.purdue.edu>  ||  ...!purdue!bouma