headers
Edi Weitz | 1 Dec 2002 19:18
Picon
Favicon

DEFCONSTANT at compile time/load time

Hi!

I have a file foo.lisp with the following contents:

  (defun foo (n)
    (1+ n))

  (defconstant +bar+ (foo 10))

If I try to compile it, SBCL (0.7.10 on Linux) complains:

  * (compile-file "foo")
  ; compiling file "/tmp/foo.lisp" (written 01 DEC 2002 07:02:20 PM):
  ; recognizing DEFUN FOO
  ; compiling top level form:
  ; compiling DEFUN FOO:
  ; compiling top level form:

  debugger invoked on condition of type UNDEFINED-FUNCTION:
    The function FOO is undefined.

OK, that's what I expected. The CLHS says about DEFCONSTANT that
"users must ensure that the initial-value can be evaluated at compile
time". OK, let's try it again, foo.lisp now is:

  (eval-when (:compile-toplevel :execute :load-toplevel)
    (defun foo (n)
      (1+ n)))

  (defconstant +bar+ (foo 10))
(Continue reading)

Permalink | Reply | 2 comments |
headers
William Harold Newman | 2 Dec 2002 04:20

Re: DEFCONSTANT at compile time/load time

On Sun, Dec 01, 2002 at 07:18:18PM +0100, Edi Weitz wrote:
> ...except for the strange STYLE-WARNING. However, as soon as FOO gets
> a little more complicated, like, say, so...
> 
>   (eval-when (:compile-toplevel :execute :load-toplevel)
>     (defun foo (n c)
>       (make-string n :initial-element c)))
> 
>   (defconstant +bar+ (foo 10 #\a))
> 
> ...it won't work:
> 
>   * (compile-file "foo")
>   ; compiling file "/tmp/foo.lisp" (written 01 DEC 2002 07:04:44 PM):
>   ; recognizing DEFUN FOO
>   ; compiling top level form:
>   ; compiling DEFUN FOO:
>   ; compiling top level form:
>   ; compiling top level form:
> 
>   ; /tmp/foo.fasl written
>   ; compilation finished in 0:00:00
> 
>   #P"/tmp/foo.fasl"
>   NIL
>   NIL
>   * (load "foo")
>   STYLE-WARNING: redefining FOO in DEFUN
> 
>   debugger invoked on condition of type SIMPLE-ERROR:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Edi Weitz | 3 Dec 2002 14:26
Picon
Favicon

Re: Re: DEFCONSTANT at compile time/load time

Thanks for the detailed reply!

William Harold Newman <william.newman <at> airmail.net> writes:

> You're right, it's because the DEFCONSTANTed thing is left around in
> the compilation environment, and the new definition isn't EQL to the
> old definition.

OK, this is more or less what I guessed but it didn't occur to me that
MAKE-STRING always produces a new string which isn't EQL to the old
one. Duh!!

> Actually, at least in 18c+, I see some of this behavior in CMU CL.
> DEFCONSTANT at compile time causes the symbol to be defined
> permanently after compilation. The difference is that CMU CL tries
> to do what you mean when you later redefine the constant to be
> something else which is EQUALP. This behavior shows up in ordinary
> repeated
> DEFCONSTANTs at the REPL, too:
>   * (defconstant +bar+ "BAR")
>   +BAR+
>   * (defconstant +bar+ "bar")
>   +BAR+
> (no error message, just friendly helpfulness...)

I see what you mean. I just noticed that I didn't get an error message
with 18d+ but now I realize that +BAR+ _is_ defined after the
compilation but CMUCL tries to DWIM.

Thanks again,
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Harold Newman | 9 Dec 2002 14:25

Re: Problem printing circular structures?

On Sun, Dec 08, 2002 at 01:15:36PM -0700, Kevin Rosenberg wrote:
> Neil Schemenauer wrote:
> > > (setq *print-level* 3)
> > > 
> > > will give you ACL output.
> > 
> > Is there a good reason this is not used for the read-eval-print loop?
> > As a new Lisp user, having SBCL spit out megabytes of text to my *sbcl*
> > buffer and crash XEmacs was a nasty surprise.

ANSI specifies that the initial values of *PRINT-LEVEL*,
*PRINT-LENGTH*, and *PRINT-CIRCLE* are NIL. (It's in the HyperSpec
pages for *PRINT-LEVEL*, *PRINT-LENGTH*, and *PRINT-CIRCLE*.) So we do
it that way.

Incidentally, I think ANSI probably made the right decision here. As
other people have said, this is easy to customize, so the only
question is what to do for new users who don't know about these
variables. New users could be surprised to get endless output (and
even more surprised when their environment handles endless output by
crashing) but at least they should be able to understand what
happened. The alternative of having the system do
  * '(1 (2 (3 (4 (5)))) 6 7 8 9 10)
  (1 (2 (3 #)) 6 ...)
has the disadvantage that when a user asked the printer to do
something reasonable, it would do something strange that the the user
wouldn't be able to figure it out for himself without hunting through
the entire manual chapter on the printer.

(So then, why do we still use non-NIL default values of *PRINT-LEVEL*
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert E. Brown | 12 Dec 2002 05:42

coerce result type


It looks like the SBCL compiler does not know that the return value of
(coerce foo 'function) is of type function.  Here's a transcript.

I am using an old version of SBCL, so perhaps this is fixed in a more recent
release.

                        bob

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

loki <6>  sbcl
This is SBCL 0.7.9, an implementation of ANSI Common Lisp.

SBCL is derived from the CMU CL system created at Carnegie Mellon University.
Besides software and documentation originally created at Carnegie Mellon
University, SBCL contains some software originally from the Massachusetts
Institute of Technology, Symbolics Incorporated, and Xerox Corporation, and
material contributed by volunteers since the release of CMU CL into the
public domain. See the CREDITS file in the distribution for more information.

SBCL is a free software system, provided as is, with absolutely no warranty.
It is mostly in the public domain, but also includes some software copyrighted
  Massachusetts Institute of Technology, 1986;
  Symbolics, Inc., 1989, 1990, 1991, 1992; and
  Xerox Corporation, 1985, 1986, 1987, 1988, 1989, 1990
used under BSD-style licenses allowing copying only under certain conditions.
See the COPYING file in the distribution for more information.

More information about SBCL is available at <http://sbcl.sourceforge.net/>.
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Harold Newman | 12 Dec 2002 19:39

Re: coerce result type

On Wed, Dec 11, 2002 at 08:42:06PM -0800, Robert E. Brown wrote:
> It looks like the SBCL compiler does not know that the return value of
> (coerce foo 'function) is of type function.  Here's a transcript.
> 
> I am using an old version of SBCL, so perhaps this is fixed in a more recent
> release.

No, it happens in current SBCL too.

The problem isn't that it doesn't understand the return type, it's
that the compiler note isn't all that clear. Try
  (defvar *wow*)
  (declaim (type function *wow*))
before compiling the DEFUN, and (at least in current SBCL, presumably
in yours too) the optimizer should stop complaining.

Part of the problem is that the message is trying to tell you several
different things (like about the context) so there's a lot of stuff to
wade through I've snipped a fair amount of it away and marked what I 
think are the relevant bits.

> * (defun foo ()
>      (let ((fn (coerce *wow* 'function)))
>      (funcall fn 2 3)))
> 
> ; in: LAMBDA NIL
> ;     (FUNCALL FN 2 3)
> ; --> SB-C::%FUNCALL 
> ; ==>
> ;   (SB-KERNEL:%COERCE-CALLABLE-TO-FUN FUNCTION)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christophe Rhodes | 12 Dec 2002 21:37
Picon
Picon
Favicon

Re: Re: coerce result type

On Thu, Dec 12, 2002 at 12:39:39PM -0600, William Harold Newman wrote:
> On Wed, Dec 11, 2002 at 08:42:06PM -0800, Robert E. Brown wrote:
> > It looks like the SBCL compiler does not know that the return value of
> > * (defun foo ()
> >      (let ((fn (coerce *wow* 'function)))
> >      (funcall fn 2 3)))
> > 
> > ; in: LAMBDA NIL
> > ;     (FUNCALL FN 2 3)
> > ; --> SB-C::%FUNCALL 
> > ; ==>
> > ;   (SB-KERNEL:%COERCE-CALLABLE-TO-FUN FUNCTION)
> > ; 
> > ; note: unable to
> > ;         optimize away possible call to FDEFINITION at runtime
> > ;       due to type uncertainty:
> > ;         The first argument is a (OR FUNCTION SYMBOL), not a FUNCTION.
>             ^^^^^^^^^^^^^^^^^^
> > ;     (COERCE *WOW* 'FUNCTION)
>                 ^^^^^
> 
> We could simplify the optimization notes, but the verbosity is there
> for a reason. In particular, when you're trying to understand where
> the code is coming from within macroexpansions and compiler
> transforms, on average more information seems to be better than less.

I'm not sure this is right, you know...

I think there *is* a real problem in the COERCE derive-type optimizer,
that it isn't aware that the return value of this particular invocation
(Continue reading)

Permalink | Reply | 1 comment |
headers
William Harold Newman | 13 Dec 2002 13:53

Re: coerce result type

On Thu, Dec 12, 2002 at 08:37:36PM +0000, Christophe Rhodes wrote:
> On Thu, Dec 12, 2002 at 12:39:39PM -0600, William Harold Newman wrote:
> > On Wed, Dec 11, 2002 at 08:42:06PM -0800, Robert E. Brown wrote:
> > > It looks like the SBCL compiler does not know that the return value of
> > > * (defun foo ()
> > >      (let ((fn (coerce *wow* 'function)))
> > >      (funcall fn 2 3)))
> > > 
> > > ; in: LAMBDA NIL
> > > ;     (FUNCALL FN 2 3)
> > > ; --> SB-C::%FUNCALL 
> > > ; ==>
> > > ;   (SB-KERNEL:%COERCE-CALLABLE-TO-FUN FUNCTION)
> > > ; 
> > > ; note: unable to
> > > ;         optimize away possible call to FDEFINITION at runtime
> > > ;       due to type uncertainty:
> > > ;         The first argument is a (OR FUNCTION SYMBOL), not a FUNCTION.
> >             ^^^^^^^^^^^^^^^^^^
> > > ;     (COERCE *WOW* 'FUNCTION)
> >                 ^^^^^
> > 
> > We could simplify the optimization notes, but the verbosity is there
> > for a reason. In particular, when you're trying to understand where
> > the code is coming from within macroexpansions and compiler
> > transforms, on average more information seems to be better than less.
> 
> I'm not sure this is right, you know...

I'm not *sure*, either. I'm a bit out of practice with with SBCL, so
(Continue reading)

Permalink | Reply | 0 comments |

Gmane