Dumb question about CL packages in SBCL - comp.lang.lisp

Message from discussion Dumb question about CL packages in SBCL

Zach Beane

View profile

More options Jan 24, 4:03 pm

Newsgroups: comp.lang.lisp

From: Zach Beane <x...@xach.com>

Date: Thu, 24 Jan 2008 16:03:45 -0500

Local: Thurs, Jan 24 2008 4:03 pm

Subject: Re: Dumb question about CL packages in SBCL

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

Mark Reed <markjr...@gmail.com> writes:
> OK, I have a CL library that I'm testing in a variety of
> implementations. It works fine in CLISP and GCL, but blows up in
> SBCL. I must be missing something very basic, so if anyone could
> supply guidance, I would appreciate it.

> Apparently, the issue is that after evaluating an (in-package "blah")
> form, the symbols from outside that package are no longer available.
> This simple sequence fails:

> (defpackage "FOO")
> (in-package "FOO")
> (format t "Hello, world!~%")

The problem is that DEFPACKAGE with no specific :USE list will end up
using an implementation-defined list of packages. SBCL's
implementation-defined list is empty; other Lisp implementations use
different defaults. For example, here's the result of evaluating
"(package-use-list (make-package (gensym)))" in several
implementations:

CLISP:
=> (#<PACKAGE COMMON-LISP>)

LispWorks Linux 5.0.1:
=> (#<The COMMON-LISP package, 3/4 internal, 978/1024 external>
#<The HARLEQUIN-COMMON-LISP package, 0/4 internal,
225/256 external>
#<The LISPWORKS package, 56/64 internal, 199/256 external>)

Allegro CL 8.0:
=> (#<The COMMON-LISP package>)

SBCL:
=> NIL

OpenMCL 1.0:
=> (#<Package "CCL"> #<Package "COMMON-LISP">)

As you can see, to get predictable results across implementations with
DEFPACKAGE, you really have to specify *some* :USE list, even if it's
empty.

> ; in: COMMON-LISP:LAMBDA COMMON-LISP:NIL
> ; FOO::FORMAT
> ;
> ; caught COMMON-LISP:STYLE-WARNING:
> ; undefined function: FORMAT

> I could import the common-lisp[-usr] package, but since no such
> package exists in e.g. gcl, I have to protect it somehow, which is
> difficult when the system can't even find IF or COND without package
> qualification.

I don't know much about GCL, but I think there's a way to start it so
it's more conformant with the Common Lisp standard. COMMON-LISP is a
standard package.

Zach

Reply to author Forward