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

[Camm Maguire]

Greetings!  This should work.  Would you be willing to test an
alternate wrap-literals if I get one together in the near-future?

Take care,

Matt Kaufmann <address@hidden> writes:

> Thank you, Camm.  Unfortunately, after (setq compiler::*keep-gaz* t),
> then all the gazonk*.lsp files are left around.  So I'm wondering if
> it would safe to do the following instead:
> 
> #+(and gcl (not ansi-cl)) (defun compiler::wrap-literals (x) x)
> #+(and gcl (not ansi-cl)) (compile 'compiler::wrap-literals)
> 
> A small test suggests that this may work, though I have no idea really
> what I'm doing.  Should I expect the above solution to be OK?
> 
> Thanks --
> -- Matt
>    Sender: address@hidden
>    Cc: address@hidden
>    From: Camm Maguire <address@hidden>
>    Date: 30 Apr 2007 12:16:06 -0400
>    X-SpamAssassin-Status: No, hits=-2.5 required=5.0
>    X-UTCS-Spam-Status: No, hits=-310 required=200
> 
>    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
> 
> 
> 

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