[Gcl-devel] ANSI function behaviour

[Peter Wood]

On Mon, Oct 28, 2002 at 09:49:02PM +0100, I wrote:
> Hi
> 
> On Mon, Oct 28, 2002 at 10:17:54AM -0500, Camm Maguire wrote:
> 
> > We need to register this as a task on the website, as it doesn't look
> > particularly trivial.  How would you describe its priority?
> > Thankfully, we can see how ecl does it, which should be pretty close.
> > Ideally, someone could find the relevant sections in the ansi-spec,
> > ensure that they describe essentially the same behavior as you have
> > quoted from cltl2, dig into the diffs with ecl to discover its patch,
> > and propose a change.  If no one else volunteers, I'll certainly try
> > to get to it, but I'm not sure whether it should be at the top of the
> > list.  
> >
> 
> The relevant clarification is at:
> 
> http://www.lispworks.com/reference/HyperSpec/Issues/iss175_w.htm
> 
> I think its pretty important if we want to call ourselves ansi.
> However there are surely lots of other things that are more pressing.
> 
> I am currently fiddling with the error system.  Wether or not anything
> comes of that, I will investigate this closure issue afterwards.
> 
> Regards,
> Peter

Hi,


I am about 95% done with an implementation of ANSI function behaviour
for GCL.  That is to say, there is some cleaning up to do, mods to PCL
to make, and adaption of existing GCL code that assumes the cons form
of functions which was allowed by CLTL1, but forbidden by ANSI. 

All the 'big bits' are done: (setf foo) function names, a discrete
type for functions, fdefinition, defmacro, defun, lambda, etc.

ECL's way of doing it was no help, since ECL uses a byte-code compiler
for interpreted code.  So this is original.

I am aware that there are several places in the implementation which
could probably be improved a bit wrt efficiency (speed/size), however
I don't think there is anything glaringly horrible.

It looks like this:

========================================================
Starts dribbling to ansi-fn.txt (2002/12/10, 16:16:19).
NIL

> 
(defun foo (a b) (+ a b))
FOO

> 
(fdefinition 'foo)
#<Interpreted-function :LAMBDA-BLOCK FOO>

> 
(type-of #'foo)
FUNCTION

> 
(functionp #'foo)
T

> 
(let ((x 'foo) (y 'bar)) (defun foobar () (make-symbol (concatenate 'string 
(symbol-name x) (symbol-name y)))))
FOOBAR

> 
(foobar)
#:FOOBAR

> 
#'foobar

#<Interpreted-function :LAMBDA-BLOCK-CLOSURE FOOBAR>

> (compile 'foobar)
Compiling gazonk0.lsp.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling gazonk0.lsp.
Loading gazonk0.o
Finished loading gazonk0.o
#<compiled-closure 0830e40c>

> 
(functionp #'foobar)
T

> 
(function foobar)
#<compiled-closure 0830e40c>

> 
(setf lam1 (lambda (l) (car l)))
#<Interpreted-function :LAMBDA-CLOSURE>

> 
(mapcar lam1 '((g c c) (c p p) (l d d)))
(G C L)

> 
(defun (setf foo) (n) n)
#<Interpreted-function :LAMBDA-BLOCK FOO>

> 
((setf foo) 1)
1

> 
(compile 'lam2 lam1)
Compiling gazonk0.lsp.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling gazonk0.lsp.
Loading gazonk0.o
Finished loading gazonk0.o
#<compiled-function LAM2>

> 
(fdefinition 'lam2)
#<compiled-function LAM2>

> 
#'lam2

#<compiled-function LAM2>

> (mapcar #'lam2 '((e c c) (f l y) (f i g)))
(E F F)

>  
(defmacro foo (x) `(car ',x))
FOO

> 
(macro-function 'foo)
#<Interpreted-function :LAMBDA-BLOCK FOO>


> 
(foo (car '(1 2 3)))
CAR

(dribble)
============================================================

There are a number of extra lisp functions (in "SYSTEM") for accessing
interpreted-functions.  The user need not bother with these, as they
are only necessary internally.

The changes required were not very large, but this _is_ an
incompatible change.  Any code which expects functions to
be lists will break.  As a result, my build is currently breaking in
compilation of PCL with this message:

Compiling GCL-LOW...
Compiling /home/prw/Projects/agcl/pcl/impl/gcl/gcl-low.lisp.

Error: #<Interpreted-function :LAMBDA-BLOCK SLOOP:LOOP-RETURN> is not of type 
LIST.

My next priority will be to modify PCL to build with the new function
behaviour.

Camm, can I expect to get this stuff in eventually?  My version of GCL
is diverging alarmingly from the official one (there are also all the
patches for clcs/error handling, outstanding).

Regards,
Peter