[Gcl-devel] Re: function-lambda-expression

[Camm Maguire]

Greetings!  Am forwarding this to the list for discussion.  The issue
is whether we should keep function definitions around post compile.
There are several advantages, not the least among which is the
possibility of compiler inlining of explicitly provided constant
functional arguments.  Primary disadvatange is memory consumption.

Thoughts most welcome.

Robert Boyer <address@hidden> writes:

> > Might be nice to carry the definition around post compile too for inlining
> > purposes, but this would likely consume a lot of memory.
> 
> This is a very good idea and it is what used to happen in some old Lisps,
> when "core" cost a million dollars a megabyte.  I'm all for it!
> 
> It's not that compilers then were smart enough to do much inlining well.  The
> old 'EXPR lambda property, as it was called in some Lisps, was simply left
> alone by the compiler and on a new property, e.g., 'SUBR, the compiled code,
> was hung.  This was before the much faster symbol-function slot was
> conceived, which made it impossible for both definitions to remain around
> simultaneously.  For many years, in Interlisp, the editor I and many others
> used quite happily was an in-Lisp editor that looked for the definition of a
> function as a Lisp object under its EXPR property even after it had been
> compiled.  In fact, that editor actually saved our Lisp functions to text
> files, pretty printing them out.  This is something that Maclisp-style leaned
> against, and Maclisp-style predominated in the development of Common Lisp.
> 
> Having in-core lambdas still around after compilation would make
> function-lambda-expression infinitely easier to code!  It would permit people
> to see, in core, functions as they were being developed, it would permit
> switching more easily to interpreted code for debugging, e.g., via Schelter's
> Emacs stepper hack.  But it would consume memory.  So it is still a judgement
> call.  And a very controversial one I'd say because of all the history.
> 
> > may have been pre-processed in some ways
> 
> I think a good example of this used to be in-situ macro expansion in some
> versions of Maclisp, something that GCL has long needed to make the execution
> of interpreted code a lot faster.  However, this would really conflict with
> Interlisp's idea of an in core editor.  So it is probably better to use hash
> tables for fast, interpreted macro expansion memoization, if someone gets
> around to it someday.

So here is point one -- if done, would the code post or pre
macroexpansion be saved?  Perhaps post, as some macros might be only
eval-when'ed :compile-toplevel, no?  Does this diminish usefulness? 

> 
> > more capable alternate in gcl_mislib.lsp
> 
> Certainly anything is a lot better than NIL T NIL.  I just suggested NIL T
> NIL to get going.
> 
>   >  produce a genuine lambda list
> 
> this would be most useful.
> 
> > closure-p
> 
> This property scares me to death.  I'm not sure that this sort of thing has
> ever been done well (perfectly) in Lisp.  This reminds me somewhat of the
> strange case we saw on gcl-dev recently of someone who did all of the DEFUNs
> inside a single outer let.  It seems to me to suggest something that GCL does
> not support, as far as I know, namely the retention of the lexical
> environment in place at the time a function was compiled, so that a
> "recompile" sort of command was possible.  Sounds like it might be nice.  But
> then again, it might take up space.
> 

Well, to my very limited understanding, GCL has this in the
lambda-block-closure and lambda-closure forms, at least as correctly
as all the compiler tests and historical usage would indicate, as
these are exactly the forms fed to the compiler.  

Separately, but relatedly you write:

=============================================================================
> auto-proclaim functions on compilation

This is a wonderful, wonderful idea, but I hope that you can see your way to
doing it perfectly honestly.  I don't think Bill Schelter ever did.  Here is
the problem as I dimly see it.  If I define

   (defun foo (x) x) 

and you proclaim it, but later I redefine foo as

   (defun foo (x y) (values x y))

in addition to re-proclaiming foo, you need to think very carefully about all
the functions we have ever compiled since you proclaimed the one arg foo that
called the one arg foo and do something.  Do what?  I don't know.  But
please, please don't just give me a segmentation violation some day.

=============================================================================

Well, the cleanest way I can conceive of handling this is to keep
track of which functions call which in a directed graph, which is at
least implicit if the source is kept post compile.  When one modifies
one function, recompiles are triggered for those higher up the graph.  

Of course, we have this issue already.  One is fully free to do the
following with no protection:

(defun foo nil (values 1 2))
(defun bar nil (cadr (multiple-value-list (foo))))
(compile 'bar)
(defun foo nil 1)

Not sure what should be guaranteed here -- Paul?

=============================================================================
>  keep the lambda functions around post compile.

This is a great idea and I am all for it but I can tell you that you better
make this easily controllable by some (setq si::*save-exprs* nil) switch or
you will encounter unimaginable rage from pristine Maclisp baby-boomers.
What is most tricky here is that you need to think through whether you are
also going to dump the lambda functions to the compiled files so that when I
load merely a compiled file, I magically get back all the lambdas!
Otherwise, you need to keep the source and compiled files together, and no
one has ever been able to do that really right, though I suspect it can be
done.  Maybe MD5 to the rescue, so you can be "sure" you have relocated the
right damn source file?
=============================================================================

Yes, dumping the forms in the .o would be the only way to go, I'd
think.

Take care,


> Bob
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah