[Gcl-devel] Re: GCL compiler bug: load-time-value and macroexpansion

[Camm Maguire]

Greetings, and thanks so much for this report!

The issue in brief stems from ansification -- compile'ed forms must
refer to the exact object literally referred to in the form, not a
copy, so the traditional GCL print and compile-file won't work.  The
function is compiler::wrap-literals, which you can trace if
interested.  There is obviously a bug here -- most likely
wrap-literals should do some selective macro-expansion, perhaps along
the lines of compiler::portable-source in 2.7.0.  I will see if I can
come up with a solution which also retains our current (2.7.0)
compatibility with the ansi tests for compile.  If you have any
suggestions, they are of course most appreciated.  The tests in
question as run thus:

cd ansi-tests
../unixport/saved_ansi_gcl
>(load "gclload1")
>(load "compile")
>(load "compile-file")
>(rt:do-tests)

There is an immediate work-around.  Set the variable
compiler::*keep-gaz* to t -- this avoids wrap-literals and behaves as
the traditional compile via print/compile-file did.  The idea is that
there are certain packages in the ansi build, notably pcl, which
compile functions which need to be linked later in gazonk files at the
raw build stage.  Even though pcl uses compile here, literal object
reference is impossible as the running image at compile time is gone.
So qualitatively if one needs to keep the gazonk files around, they
better not refer to objects only available in the compiling image.  

This exception in all likelihood should not be there eventually, but I
can't at the moment envision a bridge between ansi compile and
traditional gcl compile without one.

Comments/suggestions as always most welcome.

Take care,

Matt Kaufmann <address@hidden> writes:

> Hello --
> 
> It appears that the GCL compiler (at least: version 2.6.7 CLtL1, and
> also version 2.7.0 ANSI as of about 11/27/06) is laying down calls of
> lisp::load-time-value that are interfering with macro expansion.
> Below is an example exhibiting the problem.
> 
> Is there any simple workaround, such as (setq *some-compiler-switch*
> nil)?  By the way, the actual (much bigger) failure I had, from which
> the example below is extracted, was only an explicit error when
> calling COMPILE as shown below.  When I put the function into a file,
> I didn't see any problem with COMPILE-FILE, but I found bizarre and
> somewhat nondeterministic behavior that went away when I avoided
> compiling that function by loading the .lisp file instead.
> 
> .....
> 
> >(defmacro my-mac (b)
>        (list 'list
>             (if (and (consp b)
>                      (stringp (car b)))
>                 (list 'quote b)
>               b)))
> 
> MY-MAC
> 
> >(defun foo ()
>    (my-mac ("Guards")))
> 
> FOO
> 
> >(foo)
> 
> (("Guards"))
> 
> >(compile 'foo)
> 
> Compiling gazonk4.lsp.
> ; (DEFUN FOO ...) is being compiled.
> ;;; The function (LOAD-TIME-VALUE (SYSTEM:NANI 139732192)) is illegal.
> No FASL generated.
> 
> Error: Cannot open the file NIL..
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by LET.
> Broken at LOAD.  Type :H for Help.
> >>(quit)
> sundance:~> cat gazonk4.lsp
> 
> (lisp::defun user::foo lisp::nil (user::my-mac ((lisp::load-time-value 
> (system::nani 139732192)))))sundance:~> 
> 
> Thanks --
> -- Matt
> 
> 
> 

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