[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Compiling GCL

From: Camm Maguire
Subject: Re: [Gcl-devel] Compiling GCL
Date: Mon, 04 Nov 2013 10:31:49 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Greetings, and thanks so much for pursuing this!

Faré <address@hidden> writes:

> Dear Camm,
>>> (declaim (ftype function ensure-exported))
>> Why do you think this is legal from the following page from the spec?  I
>> think you mean either (declaim (type function ensure-exported)) or
>> (declaim (function ensure-exported)).
> Well, I expect declaim type would associate a type
> to the *variable* named ensure-exported, not to the function of the same name.

That is true, and is what I assumed you intended.  Since that is not the
case, please see below.

>> 3.8.23 ftype                                                         
>> [Declaration]
>> Specifies that the functions named by function-names are of the
>> functional type type.
> I don't see anything in http://clhs.lisp.se/Body/d_ftype.htm
> that suggests function is an invalid type, as opposed to
> (function (&rest t) &rest t)
> It just says type, and as far as I can tell, all the implementations agree 
> that
> function is a valid type for functions (indeed, the most general type
> that covers
> all functions, even including funcallable objects)

It does indeed fail to define 'type' precisely, but all the examples are
of the (function (&rest t) t) variety, and from the context, as we
are describing a function binding of a symbol, it would clearly be
inadmissible to do (declaim (ftype cons foo)), so (declaim (ftype
function foo)) is at best a no-op.  I suppose we could let it pass, but
it has no content AFAICS.

(OK, so I'm reading the spec more closely, and it does say type is a
subtype of function.  So I've committed a patch to let the no-op declaim
pass.  Clisp, perhaps the most compliant free option out there, seems to
allow anything after ftype.  It seems that as of now we are closer to
sbcl here.)

> OK, after compiling an ansi gcl the way you suggested,
> trying to load asdf as a lisp file works — that's good.
> But compiling it fails.
> I invoke GCL with:
> gcl -eval '(compile-file "/home/tunes/cl/asdf/build/asdf.lisp" :print
> t :verbose t)'
> The last things in the output log as I is
> ; (PROGN (DEFPACKAGE :ASDF/FOOTER ...) ...) is being compiled.
> ; (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL ...) ...) is being compiled.
> ; (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL ...)) is being compiled.
> ; (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL ...) ...) is being compiled.
> ;; End of Pass 1.
> ;;; A bug was found in the compiler.  Contact Taiichi.

Thank you for this report!  This should be fixed now.  I've cloned your
source and loaded and compiled successfully.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]