From: <as...@ma...> - 2003-12-03 18:50:44
|
Loading a file containing (defpackage :test (:use "COMMON-LISP") (:export #:exported)) (in-package :test) (with-open-file (f "/tmp/test-result.cl" :direction :output :if-exists :supersede) (format f "~s~%~s~%" 'exported 'not-exported)) produces [simon@hugi src]$ cat /tmp/test-result.cl TEST:EXPORTED TEST::NOT-EXPORTED I'm not sure this is a bug, but ABL certainly behaves differently from both ACL and LW, which put EXPORTED NOT-EXPORTED in test-result.cl Andras |
From: Andras S. <as...@ma...> - 2004-08-04 15:17:56
|
I'm not at all sure this is a bug, but: foo.lisp: (defpackage :foo (:use :common-lisp) (:export :foo)) (in-package :foo) (defun foo () 42) bar.lisp (in-package :cl-user) (use-package :foo) (defun bar () (foo)) Now after (load (compile-file "foo.lisp")) (load (compile-file "bar.lisp")) (bar) while in the CL-USER package, I get The function FOO is undefined. It looks as if FOO got interned in the CL-USER package because USE-PACKAGE is only evaluated at load time. Wrapping the USE-PACKAGE form in an EVAL-WHEN helps, but I think this shouldn't be necessary. Andras |
From: Christophe R. <cs...@ca...> - 2004-08-04 15:50:18
|
Andras Simon <as...@ma...> writes: > It looks as if FOO got interned in the CL-USER package because > USE-PACKAGE is only evaluated at load time. Wrapping the USE-PACKAGE > form in an EVAL-WHEN helps, but I think this shouldn't be necessary. It is necessary. Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Andras S. <as...@ma...> - 2004-08-04 16:24:48
|
On Wed, 4 Aug 2004, Christophe Rhodes wrote: > Andras Simon <as...@ma...> writes: > >> It looks as if FOO got interned in the CL-USER package because >> USE-PACKAGE is only evaluated at load time. Wrapping the USE-PACKAGE >> form in an EVAL-WHEN helps, but I think this shouldn't be necessary. > > It is necessary. OK, I see. Thanks! Andras |
From: Peter G. <pe...@ar...> - 2004-08-04 16:12:23
|
On Wed, 4 Aug 2004 at 17:17:47 +0200, Andras Simon wrote: > I'm not at all sure this is a bug, but: > > foo.lisp: > > (defpackage :foo > (:use :common-lisp) > (:export > :foo)) > > (in-package :foo) > > (defun foo () 42) > > > bar.lisp > > (in-package :cl-user) > (use-package :foo) > > (defun bar () > (foo)) > > Now after > > (load (compile-file "foo.lisp")) > (load (compile-file "bar.lisp")) > (bar) > > while in the CL-USER package, I get > > The function FOO is undefined. > > It looks as if FOO got interned in the CL-USER package because > USE-PACKAGE is only evaluated at load time. Wrapping the USE-PACKAGE > form in an EVAL-WHEN helps, but I think this shouldn't be necessary. When in doubt, consult the oracle (sbcl). Slightly edited for brevity: CL-USER(1): (load (compile-file "foo")) T CL-USER(2): (load (compile-file "bar")) ; compiling file "/home/peter/depot/j/src/org/armedbear/lisp/bar.lisp" (written 04 AUG 2004 08:30:58 AM): ; compiling top level form: ; compiling top level form: ; recognizing DEFUN BAR ; compiling DEFUN BAR: ; compiling top level form: ; file: /home/peter/depot/j/src/org/armedbear/lisp/bar.lisp ; in: DEFUN BAR ; (FOO) ; ; caught STYLE-WARNING: ; undefined function: FOO ; ; caught STYLE-WARNING: ; This function is undefined: ; FOO ; ; compilation unit finished ; caught 2 STYLE-WARNING conditions ; /home/peter/depot/j/src/org/armedbear/lisp/bar.fasl written ; compilation finished in 0:00:00 debugger invoked on a SIMPLE-ERROR in thread 17990: Using package FOO results in name conflicts for these symbols: (FOO) You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE] Unintern the conflicting symbols in the COMMON-LISP-USER package. 1: [ABORT ] Reduce debugger level (leaving debugger, returning to toplevel). 2: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop. ("hairy arg processor for top level local call USE-PACKAGE" :FOO #<PACKAGE "COMMON-LISP-USER">) 0] Which is a bit obscure. I think what's happening is that the compile- time environment is bleeding over into the runtime environment, but I'm not at all sure. Clearly compilation succeeds, however. Let's keep going just a bit: 0] 2 CL-USER(3): (apropos "FOO") FOO:FOO (fbound) FOO :FOO (bound) SB-C::FOO SB-C::%FUNCALL-IN-FOOMACROLET-LEXENV (fbound) SB-C::MAPFOO-TRANSFORM (fbound) SB-KERNEL::FOO CL-USER(4): (symbol-package 'foo) #<PACKAGE "COMMON-LISP-USER"> So somehow or other the symbol FOO has found its way into CL-USER. Now, if at this point you start a fresh copy of sbcl and just load foo.fasl and bar.fasl, (bar) works fine: CL-USER(1): :ld foo.fasl loading "foo.fasl" CL-USER(2): :ld bar.fasl loading "bar.fasl" CL-USER(3): (bar) 42 Same with abcl: CL-USER(1): :ld foo.abcl ; Loading /home/peter/depot/j/src/org/armedbear/lisp/foo.abcl ... ; Loaded /home/peter/depot/j/src/org/armedbear/lisp/foo.abcl (0.065 seconds) CL-USER(2): :ld bar.abcl ; Loading /home/peter/depot/j/src/org/armedbear/lisp/bar.abcl ... ; Loaded /home/peter/depot/j/src/org/armedbear/lisp/bar.abcl (0.104 seconds) CL-USER(3): (bar) 42 So I dunno. Is there a bug? And if so, exactly what is it? -Peter |
From: Andras S. <as...@ma...> - 2004-08-04 16:22:49
|
On Wed, 4 Aug 2004, Peter Graves wrote: > On Wed, 4 Aug 2004 at 17:17:47 +0200, Andras Simon wrote: >> I'm not at all sure this is a bug, but: >> >> foo.lisp: >> >> (defpackage :foo >> (:use :common-lisp) >> (:export >> :foo)) >> >> (in-package :foo) >> >> (defun foo () 42) >> >> >> bar.lisp >> >> (in-package :cl-user) >> (use-package :foo) >> >> (defun bar () >> (foo)) >> >> Now after >> >> (load (compile-file "foo.lisp")) >> (load (compile-file "bar.lisp")) >> (bar) >> >> while in the CL-USER package, I get >> >> The function FOO is undefined. >> >> It looks as if FOO got interned in the CL-USER package because >> USE-PACKAGE is only evaluated at load time. Wrapping the USE-PACKAGE >> form in an EVAL-WHEN helps, but I think this shouldn't be necessary. > > When in doubt, consult the oracle (sbcl). Yes, this is what I did after reading Christophe's message. > > Slightly edited for brevity: > > CL-USER(1): (load (compile-file "foo")) > T > CL-USER(2): (load (compile-file "bar")) > ; compiling file "/home/peter/depot/j/src/org/armedbear/lisp/bar.lisp" (written 04 AUG 2004 08:30:58 AM): > ; compiling top level form: > ; compiling top level form: > ; recognizing DEFUN BAR > ; compiling DEFUN BAR: > ; compiling top level form: > > ; file: /home/peter/depot/j/src/org/armedbear/lisp/bar.lisp > ; in: DEFUN BAR > ; (FOO) > ; > ; caught STYLE-WARNING: > ; undefined function: FOO > > ; > ; caught STYLE-WARNING: > ; This function is undefined: > ; FOO > ; > ; compilation unit finished > ; caught 2 STYLE-WARNING conditions > > ; /home/peter/depot/j/src/org/armedbear/lisp/bar.fasl written > ; compilation finished in 0:00:00 > > debugger invoked on a SIMPLE-ERROR in thread 17990: > Using package FOO results in name conflicts for these symbols: > (FOO) > > You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. > > restarts (invokable by number or by possibly-abbreviated name): > 0: [CONTINUE] Unintern the conflicting symbols in the COMMON-LISP-USER package. > 1: [ABORT ] Reduce debugger level (leaving debugger, returning to toplevel). > 2: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop. > ("hairy arg processor for top level local call USE-PACKAGE" > :FOO > #<PACKAGE "COMMON-LISP-USER">) > 0] > > Which is a bit obscure. I think what's happening is that the compile- > time environment is bleeding over into the runtime environment, but I'm > not at all sure. Clearly compilation succeeds, however. I thought it was clear: FOO got interned in the CL-USER package when COMPILE-FILE READ the form. Isn't this the case? > > Let's keep going just a bit: > > 0] 2 > CL-USER(3): (apropos "FOO") > FOO:FOO (fbound) > FOO > :FOO (bound) > SB-C::FOO > SB-C::%FUNCALL-IN-FOOMACROLET-LEXENV (fbound) > SB-C::MAPFOO-TRANSFORM (fbound) > SB-KERNEL::FOO > CL-USER(4): (symbol-package 'foo) > #<PACKAGE "COMMON-LISP-USER"> > > So somehow or other the symbol FOO has found its way into CL-USER. By COMPILE-FILE READing it? > > So I dunno. Is there a bug? And if so, exactly what is it? > Maybe not signaling a name conflict error is bug? Andras |
From: Peter G. <pe...@ar...> - 2004-08-04 16:36:37
|
On Wed, 4 Aug 2004 at 18:22:45 +0200, Andras Simon wrote: > Yes, this is what I did after reading Christophe's message. Some sort of mailing list time warp seems to be in effect. I haven't received Christophe's message yet, even though it's already up on gmane. Sorry for adding to the confusion. -Peter |
From: Andras S. <as...@ma...> - 2004-08-04 16:54:21
|
On Wed, 4 Aug 2004, Peter Graves wrote: > On Wed, 4 Aug 2004 at 18:22:45 +0200, Andras Simon wrote: >> Yes, this is what I did after reading Christophe's message. > > Some sort of mailing list time warp seems to be in effect. > > I haven't received Christophe's message yet, even though it's already > up on gmane. > > Sorry for adding to the confusion. You can't add much to mine :-) But here's something else: unlike USE-PACKAGE, DEFPACKAGE should have compile-time effects; and it does in abcl. But how it's achieved is a mystery to me, since DEFPACKAGE doesn't expand into an EVAL-WHEN. Andras |
From: Peter G. <pe...@ar...> - 2004-08-04 17:06:47
|
On Wed, 4 Aug 2004 at 18:54:19 +0200, Andras Simon wrote: > But here's something else: unlike USE-PACKAGE, DEFPACKAGE should have > compile-time effects; and it does in abcl. But how it's achieved is a > mystery to me, since DEFPACKAGE doesn't expand into an EVAL-WHEN. It's treated specially by COMPILE-FILE (compile-file.lisp:59). This isn't really the right approach, of course, but I did it that way when I first started working on COMPILE-FILE and haven't revisited it since. -Peter |
From: Andras S. <as...@ma...> - 2004-08-04 17:40:32
|
On Wed, 4 Aug 2004, Peter Graves wrote: > On Wed, 4 Aug 2004 at 18:54:19 +0200, Andras Simon wrote: >> But here's something else: unlike USE-PACKAGE, DEFPACKAGE should have >> compile-time effects; and it does in abcl. But how it's achieved is a >> mystery to me, since DEFPACKAGE doesn't expand into an EVAL-WHEN. > > It's treated specially by COMPILE-FILE (compile-file.lisp:59). Thanks for solving the mystery! Andras |
From: Peter G. <pe...@ar...> - 2003-12-04 03:21:04
|
On Wed, 3 Dec 2003 at 20:49:29 +0100, Andr=E1s_Simon wrote: > Loading a file containing > > (defpackage :test > (:use "COMMON-LISP") > (:export #:exported)) > > (in-package :test) > > (with-open-file (f "/tmp/test-result.cl" :direction :output > :if-exists :supersede) > (format f "~s~%~s~%" 'exported 'not-exported)) > > produces > > [simon@hugi src]$ cat /tmp/test-result.cl > TEST:EXPORTED > TEST::NOT-EXPORTED > > I'm not sure this is a bug, but ABL certainly behaves differently > from both ACL and LW, which put > > EXPORTED > NOT-EXPORTED > > in test-result.cl Indeed a bug, but in Symbol.toString(), not in the package code per se. Now fixed in CVS. Thanks! -Peter |