I'm what you would probably call a hobbyist programmer, and I've been
recently working on teaching myself Common Lisp. I've generally been
quite pleased with how many good, freely available resources there are
for CL, and one of the things I've been working on is the exercises in
a book by Shapiro, called /Common Lisp: An Interactive Approach/[1].
I'd been working with SLIME for Aquamacs and OpenMCL 1.0.
However, I found some of the exercises pretty hard, and decided to try
to STEP through some of the code I was working on. OpenMCL doesn't do
that, so I downloaded SBCL and tried that out. And it does STEP just
fine, but I can't get any of the packages I set up to work[2].
In OpenMCL, I had this, and it worked fine:
(defpackage match
(:shadow boundp substitute))
(in-package match)
However, when I tried compiling it in SBCL, I get a message about how
match is an undefined variable. I look at the Hyperspec some, and try
this:
defpackage "match"
(:shadow boundp substitute))
(in-package "match")
And then I get all sorts of errors, like:
The variable |match|::*GRAMMAR-RULES* is unbound.
[Condition of type UNBOUND-VARIABLE]
despite the fact that I have
(defparameter *grammar-rules*
'(((john ?v ?n) ((n john) ?v ?n))
((?n1 loves ?n2) (?n1 (v loves) ?n2))
((?n ?v mary) (?n ?v (n mary)))
((?n1 (v ?v) (n ?n2)) (?n1 (vp (v ?v) (n ?n2))))
(((n ?n1) (vp ?v ?n2)) (s (n ?n1) (vp ?v ?n2)))))
right there in the file. In fact, It appears that evaluating that
statement is what's causing the problem (after compiling the file with
C-c C-k didn't work, I tried just evaluating the region with C-c C-r,
and got the same error message).
I really have no idea what's going on. Any explanation would be greatly
appreciated.
Thanks!
[1] http://www.cse.buffalo.edu/~shapiro/Commonlisp/
[2] The author suggests doing each chapter's exercises, and the two
"projects", in their own packages.
Pillsbury,
Shapiro's book is fantastic.
>
> defpackage "match"
> (:shadow boundp substitute))
>
> (in-package "match")
>
That should be (defpackage "MATCH" ...) and (in-package "MATCH"). I
believe that Chapter 6 and Chapter 7 spend some time discussing the
many different printed representations that symbols possess. (Everyone
runs into this problem).
Good Luck,
Rand
(please don't email me because it doesn't work)
==================== aside ============================
If you're using LispWorks with this example, you'll get a package name
clash.
Here is the relevant lisp-hug thread:
http://thread.gmane.org/gmane.lisp.lispworks.general/3543/focus=3546
==================== aside ============================
··········@eudoramail.com wrote:
> That should be (defpackage "MATCH" ...) and (in-package "MATCH"). I
> believe that Chapter 6 and Chapter 7 spend some time discussing the
> many different printed representations that symbols possess. (Everyone
> runs into this problem).
Yes, that did the trick. Thanks!
On 29 Jun 2006 22:08:53 -0700, ··········@eudoramail.com tried to
confuse everyone with this message:
>
>Pillsbury,
>
>Shapiro's book is fantastic.
>
>>
>> defpackage "match"
>> (:shadow boundp substitute))
>>
>> (in-package "match")
>>
>
>That should be (defpackage "MATCH" ...) and (in-package "MATCH"). I
>believe that Chapter 6 and Chapter 7 spend some time discussing the
>many different printed representations that symbols possess. (Everyone
>runs into this problem).
>
Or better yet (defpackage :match) or (defpackage #:match), so Lisp
converts it in uppercase for you.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
·········@gmail.com writes:
> (defpackage match
> (:shadow boundp substitute))
>
> (in-package match)
This is a relic of older code. The argument to IN-PACKAGE gets
evaluated. A simple solution is to use a keyword or a string:
(in-package :match)
(in-package "MATCH")
The string is upper-case because the default reader upcases all symbol
names, so that when the name was read in the DEFPACKAGE form, it became
a symbol with the name "MATCH"n
> However, when I tried compiling it in SBCL, I get a message about how
> match is an undefined variable. I look at the Hyperspec some, and try
> this:
>
> defpackage "match"
> (:shadow boundp substitute))
>
> (in-package "match")
>
> And then I get all sorts of errors, like:
>
> The variable |match|::*GRAMMAR-RULES* is unbound.
> [Condition of type UNBOUND-VARIABLE]
>
> despite the fact that I have
>
> (defparameter *grammar-rules*
> '(((john ?v ?n) ((n john) ?v ?n))
> ((?n1 loves ?n2) (?n1 (v loves) ?n2))
> ((?n ?v mary) (?n ?v (n mary)))
> ((?n1 (v ?v) (n ?n2)) (?n1 (vp (v ?v) (n ?n2))))
> (((n ?n1) (vp ?v ?n2)) (s (n ?n1) (vp ?v ?n2)))))
>
> right there in the file. In fact, It appears that evaluating that
> statement is what's causing the problem (after compiling the file with
> C-c C-k didn't work, I tried just evaluating the region with C-c C-r,
> and got the same error message).
>
> I really have no idea what's going on. Any explanation would be greatly
> appreciated.
It looks like this really should work. Although defining packages with
lower-case names is likely to make things a lot harder on you.
Depending on exactly how you got into this state, it may be the case
that there was some caching of package name information in the code that
links the editor buffer to the underlying lisp system.
Mastering the intricacies of symbol-name casing, the package system and
symbol interning is probably among the hardest things to do when
learning Common Lisp. I'd put it right up there with evaluation rules
for potential newcomer confusion.
I generally like to use strings with my package code, although there are
others who prefer keywords or uninterned symbols.
So I would start the file with:
(in-package "CL-USER")
(defpackage "MATCH"
(:shadow "BOUNDP" "SUBSTITUTE"))
(in-package "MATCH")
...
and start in a fresh lisp. See if that works for you.
--
Thomas A. Russ, USC/Information Sciences Institute