Christophe Rhodes <csr21@...> wrote:
> Clemens Fruhwirth <clemens@...> writes:
> > it works. It seems that import is not considered to modify the reader
> > behaviour while compilation. Imho this is wrong.
> In the opinion of those who wrote the Common Lisp standard, this is
> correct. IMPORT is a function, and so has no read-time or
> :compile-toplevel-time effect, but as you've noticed, the programmer
> is provided with EVAL-WHEN to control when it is evaluated.
I'm wondering what could be broken by a different import semantic, but -
sigh - a standard is a standard, and at least you're not tempted to
write code in sbcl that does not work on other implementation (as I was,
as I was switching over from cmucl).
However, import is nothing obscure, neither is compilation. The
name-conflict error already states a reference to CLHS. What do you
think of adding a hint to the error message, so folks switching
from other CL implementations like cmucl don't fall into this trap?
This would make sbcl a bit more developer friendly. No, I don't want to
add presumptuous hints to every error message as other compiler products
do. But again, import is likely to be used, same is true for
Probably something like this:
IMPORT UFFI:DEF-CONSTANT causes name-conflicts in #<PACKAGE "COMMON-LISP-USER">
between the following symbols:
[Condition of type SB-INT:NAME-CONFLICT]
Common Lisp Hyperspec, 126.96.36.199.5 [section]
IMPORT is commonly wrapped in (eval-when (:compile-toplevel) ... ) for code compilation.
Fruhwirth Clemens - http://clemens.endorphin.org
for robots: sp4mtrap@...