hi
i'm looking at packages and how other lisp code is organized in
packages and it looks so intricate. is it so?
say, i want to begin with simple package in one source file: do i do
defpackage in the beginning of the file?
but may be the package will grow and i'll want to split it in several
source files, should i make a separate "meta" file that does
defpackage and then ... what? loads others?
i guess i'm also confused about compilation / loading and
evaluating... does "defpackage" has to be evaluated before compiling
a package?
thank you.
--
gr{oe|ee}t{en|ings}
artm
Artem Baguinski wrote:
> i guess i'm also confused about compilation / loading and
> evaluating... does "defpackage" has to be evaluated before compiling
> a package?
I usually put the DEFPACKAGE in its own file, and load that file before
compiling any file with (in-package <that-package>).
(You don't compile a package, you compile a file or a function.)
Paul
Artem Baguinski wrote:
> hi
>
> i'm looking at packages and how other lisp code is organized in
> packages and it looks so intricate. is it so?
It certainly feels that way until you get the hang of it, but at bottom
I think it is fairly straightforward.
The big gotcha is that the reader will intern a symbol or try to resolve
a package reference as soon as it reads one, so I ended up scratching my
head quite a bit at times over how some symbol got into some other
package. This is why defpackage forms often use strings ("MY-SYMBOL") or
uninterned symbols (#:my-symbol) where a plain symbol would be legal.
>
> say, i want to begin with simple package in one source file: do i do
> defpackage in the beginning of the file?
Yes. Here is an example:
(defpackage #:opengl-bindings
(:nicknames #:ogb)
(:use #:common-lisp #:uffi #:ffx)
(:export "GLUT-GET-WINDOW" "GLUT-SET-WINDOW" "GLUT-POST-REDISPLAY"
"WITH-MATRIX" "WITHIN-GL-BEGIN-END" "GL-PUSHM" "GL-POPM"
"GLUT-CALLBACK-SET" "OGB-GLUT-INIT" "CLOSED-STREAM-P" "*SELECTING*"
))
(in-package #:ogb)
...etc..
>
> but may be the package will grow and i'll want to split it in several
> source files, should i make a separate "meta" file that does
> defpackage ...
That seems to be the conventional wisdom, tho I like incremental use of
defpackage:
(defpackage :Cello
(:export IXCanvas targetRes))
Note that with lispworks that does not work unless:
(setq (hcl::*handle-existing-defpackage* (list :add))
Not sure about other Lisp implementations.
and then ... what? loads others?
Load another package before getting into stuff that uses it, so the
loaded package form to export its symbols is visible by the time the
reader gets to your source where you use symbols you hope to get from
the loaded package.
>
> i guess i'm also confused about compilation / loading and
> evaluating... does "defpackage" has to be evaluated before compiling
> a package?
Something like:
(in-package :cello)
(defpackage "CELLO"....)
..has the obvious problem. I guess the moral is that defpackage sets
things up for the reader, so think a little about not just Lisp but also
when the reader is encountering symbols and when it is learning your
package intentions.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> That seems to be the conventional wisdom, tho I like incremental use of
> defpackage:
>
> (defpackage :Cello
> (:export IXCanvas targetRes))
>
> Note that with lispworks that does not work unless:
>
> (setq (hcl::*handle-existing-defpackage* (list :add))
Conforming lisp programs may not do this:
CLtS, 'DEFPACKAGE':
"If the new definition is at variance with the current state
of that package, the consequences are undefined; an implementation
might choose to modify the existing package to reflect the new definition."
Paul
Kenny Tilton wrote:
> The big gotcha is that the reader will intern a symbol or try to resolve
> a package reference as soon as it reads one, so I ended up scratching my
> head quite a bit at times over how some symbol got into some other
> package. This is why defpackage forms often use strings ("MY-SYMBOL") or
> uninterned symbols (#:my-symbol) where a plain symbol would be legal.
So this is timely. I was just struggling with this issue the other day. I
think I understand, but the big question I have is what sorts of types can
be used as names in defpackage, in-package, require, etc., and why one
would want to use each of them. In particular, I see strings, symbols, and
keyword symbols all being used to name packages. I assume they are all
legal and that there are rules that basically use the character content,
which is converted to something canonical. Is the canonical form a string
or a symbol? That is, does the defpackage form convert the string usage to
a symbol and do something with that, or convert the symbols to strings and
then use that?
Kenny, sounds like you answered some of that with your comments above. If I
understand you right, I don't want to use standard symbols in a defpackage
because when the reader reads that form, it's by definition going to be
doing so in another package (like cl-user or something) because the package
I'm defining hasn't been created yet. Because of that, any symbol that
appears in the defpackage form will therefore get interned in the package
that is current when the defpackage is executed, right? So, to avoid
polluting the current package with symbols, it seems like I either want to
use strings, uninterned symbols, or perhaps keyword symbols (which are
always interned in the keyword package, right?). Do I have that right?
-- Dave
Dave Roberts wrote:
> Kenny Tilton wrote:
>
>
>>The big gotcha is that the reader will intern a symbol or try to resolve
>>a package reference as soon as it reads one, so I ended up scratching my
>>head quite a bit at times over how some symbol got into some other
>>package. This is why defpackage forms often use strings ("MY-SYMBOL") or
>>uninterned symbols (#:my-symbol) where a plain symbol would be legal.
>
>
> So this is timely. I was just struggling with this issue the other day. I
> think I understand, but the big question I have is what sorts of types can
> be used as names in defpackage, in-package, require, etc., and why one
> would want to use each of them. In particular, I see strings, symbols, and
> keyword symbols all being used to name packages. I assume they are all
> legal and that there are rules that basically use the character content,
> which is converted to something canonical. Is the canonical form a string
> or a symbol? That is, does the defpackage form convert the string usage to
> a symbol and do something with that, or convert the symbols to strings and
> then use that?
>
> Kenny, sounds like you answered some of that with your comments above. If I
> understand you right, I don't want to use standard symbols in a defpackage
> because when the reader reads that form, it's by definition going to be
> doing so in another package (like cl-user or something) because the package
> I'm defining hasn't been created yet. Because of that, any symbol that
> appears in the defpackage form will therefore get interned in the package
> that is current when the defpackage is executed, right?
Not to be picky, but simply because the timing is so subtle that we
really need to get this right or it will be impossible to
anticipate/debug (rewriting yours): any symbol that appears in the
defpackage form will therefore get interned in the package that is
current when the defpackage /form/ is /read by the reader/.
On a compile-and-load: first the reader reads cello.lisp, then it
compiles it, then it loads the fasl, executing the (defpackage :cello
...) form.
So, to avoid
> polluting the current package with symbols, it seems like I either want to
> use strings, uninterned symbols, or perhaps keyword symbols (which are
> always interned in the keyword package, right?). Do I have that right?
Yes, but two things:
1. keyword symbols are not much help, since they would be weird as
function names or constant names. but yes, i often use keyword symbols
as values as a lazy way of ducking the package system. bad habit
probably born of early painful encounters with packages
2. i am just a humble application programmer, and obviously no expert on
the package system, so some of the above might be bogus.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: james anderson
Subject: Re: trying to understand packages
Date:
Message-ID: <403CC372.DF4B1D0C@setf.de>
Dave Roberts wrote:
>
> Kenny Tilton wrote:
>
> > The big gotcha is that the reader will intern a symbol or try to resolve
> > a package reference as soon as it reads one, so I ended up scratching my
> > head quite a bit at times over how some symbol got into some other
> > package. This is why defpackage forms often use strings ("MY-SYMBOL") or
> > uninterned symbols (#:my-symbol) where a plain symbol would be legal.
>
> So this is timely. I was just struggling with this issue the other day. I
> think I understand, but the big question I have is what sorts of types can
> be used as names in defpackage, in-package, require, etc., and why one
> would want to use each of them. In particular, I see strings, symbols, and
> keyword symbols all being used to name packages. I assume they are all
> legal and that there are rules that basically use the character content,
> which is converted to something canonical. Is the canonical form a string
> or a symbol? That is, does the defpackage form convert the string usage to
> a symbol and do something with that, or convert the symbols to strings and
> then use that?
>
there is no need for uncertainty and/or conjecture. just go look at the
definition for defpackage. it will answer all of your questions. notice the
term "string designator".
> Kenny, sounds like you answered some of that with your comments above. If I
> understand you right, I don't want to use [] symbols in a defpackage
> because when the reader reads that form, it's by definition going to be
> doing so in another package (like cl-user or something) because the package
> I'm defining hasn't been created yet. Because of that, any symbol that
> appears in the defpackage form will therefore get interned in the package
> that is current when the defpackage is [read], right? So, to avoid
> polluting the current package with symbols, it seems like I either want to
> use strings, uninterned symbols, or perhaps keyword symbols (which are
> always interned in the keyword package, right?). Do I have that right?
whereby the issue is not so much pollution from an conservationist standpoint,
since the interned symbols often do not survive the developement image. it is
that the artifactual intered symbol may intefere with a package operation
which is implicit in the containing definition.
...
james anderson wrote:
> there is no need for uncertainty and/or conjecture. just go look at the
> definition for defpackage. it will answer all of your questions. notice
> the term "string designator".
Excellent, thanks. I had missed looking up the definition of "string
designator" in CLHS when I read it the first time and had been looking at
all the various books I could find, which were confusing me more than
helping as they all seemed to use different styles.
>
>> Kenny, sounds like you answered some of that with your comments above. If
>> I understand you right, I don't want to use [] symbols in a defpackage
>> because when the reader reads that form, it's by definition going to be
>> doing so in another package (like cl-user or something) because the
>> package I'm defining hasn't been created yet. Because of that, any symbol
>> that appears in the defpackage form will therefore get interned in the
>> package that is current when the defpackage is [read], right? So, to
>> avoid polluting the current package with symbols, it seems like I either
>> want to use strings, uninterned symbols, or perhaps keyword symbols
>> (which are always interned in the keyword package, right?). Do I have
>> that right?
>
> whereby the issue is not so much pollution from an conservationist
> standpoint, since the interned symbols often do not survive the
> developement image. it is that the artifactual intered symbol may intefere
> with a package operation which is implicit in the containing definition.
Right. Got it.
So the question is here, what is "good package programming style?" I see
many people doing many things here (again, strings, symbols, keyword
symbols, and, now with Kenny, uninterned symbols). Is there any particular
style guide that says one particular way is preferred (akin to putting "*"
on either end of a defvar special variable)? My guess is "No," since there
are so many examples of different style out there. If that's the case, can
a few people chime in here to "argue" for your preferred style.
-- Dave
From: james anderson
Subject: Re: trying to understand packages
Date:
Message-ID: <403CCE4B.7097C1C0@setf.de>
Dave Roberts wrote:
>
> ...
>
> So the question is here, what is "good package programming style?" I see
> many people doing many things here (again, strings, symbols, keyword
> symbols, and, now with Kenny, uninterned symbols). Is there any particular
> style guide that says one particular way is preferred (akin to putting "*"
> on either end of a defvar special variable)? My guess is "No," since there
> are so many examples of different style out there. If that's the case, can
> a few people chime in here to "argue" for your preferred style.
without regard to the possible existence of a "style guide for symbols", i
observe the following:
- :string-designator and #:string-designator are more tolerant of
non-conformant run-time environments than is "STRING-DESIGNATOR"
- :string-designator is one key stroke fewer than #:string-designator
- squandered resources do not concern me in the development image. thus the
interned keywords do not concern me.
- many defpackage implementation macros resolve all designators to strings, so
the symbols do not survive to the fasl form.
- defpackage has insufficiently specified semantics for certain applications
anyway. which led me to implement a variant, modpackage, which i know does not
retain the symbols.
...
From: Joe Marshall
Subject: Re: trying to understand packages
Date:
Message-ID: <vflt9au4.fsf@comcast.net>
james anderson <··············@setf.de> writes:
> without regard to the possible existence of a "style guide for symbols", i
> observe the following:
>
> - :string-designator and #:string-designator are more tolerant of
> non-conformant run-time environments than is "STRING-DESIGNATOR"
But less predictable as well. When I use "STRING-DESGINATOR" I know
the symbol's name, but when I use :string-designator, I don't know if
the symbol will have the name "STRING-DESIGNATOR" or "string-designator".
If you don't care, then that's fine. If you do care, it's a problem.
I sometimes care.
--
~jrm
Joe Marshall wrote:
> If you don't care, then that's fine. If you do care, it's a problem.
> I sometimes care.
Hmmmm... under what circumstances do you care? I had sort of decided that
:symbol seemed like the way to go. Now I'm thinking maybe not...
-- Dave
From: Joe Marshall
Subject: Re: trying to understand packages
Date:
Message-ID: <n07594qk.fsf@comcast.net>
Dave Roberts <·············@re-move.droberts.com> writes:
> Joe Marshall wrote:
>
>> If you don't care, then that's fine. If you do care, it's a problem.
>> I sometimes care.
>
> Hmmmm... under what circumstances do you care? I had sort of decided that
> :symbol seemed like the way to go. Now I'm thinking maybe not...
Since symbols are symbols, it is a good idea to use them when you need
interned names to compare quickly, for instance, query-keys in URIs.
When parsing the URI, you'd use find-symbol on the query keys to
intern the ones of interest (presumably, the query keys that did not
map to symbols would be unrecognized). You really want to know
exactly what is being interned.
--
~jrm
From: james anderson
Subject: Re: trying to understand packages
Date:
Message-ID: <403E2507.88E49E40@setf.de>
Dave Roberts wrote:
>
> Joe Marshall wrote:
>
> > If you don't care, then that's fine. If you do care, it's a problem.
> > I sometimes care.
>
> Hmmmm... under what circumstances do you care?
when the case of the symbol's print name matters. if you need to match the
case of an external representation it sometimes will. for program code it
usually does not. one additional wrinkle is that, in the case where i would
have cared with respect to program code there was a secondary concern, that, perhaps,
- symbols were not the correct representation for the external data in the
first place, and
- it was not clear that one wanted to couple the case treatment of those data
objects with the reader's case treatment for symbols.
i ended up introducing a reader macro which uncoupled both the representation
and the case management. my case was names, xml documents, and namespaces. for
which i ended up using a form other than defpackage to define collections of
names.
> I had sort of decided that
> :symbol seemed like the way to go. Now I'm thinking maybe not...
it depends on whether one uses defpackage to generate symbols for which the
print names need to match a particular external representation.
...
In article <·················@setf.de>,
james anderson <··············@setf.de> wrote:
> Dave Roberts wrote:
> >
> > Joe Marshall wrote:
> >
> > > If you don't care, then that's fine. If you do care, it's a problem.
> > > I sometimes care.
> >
> > Hmmmm... under what circumstances do you care?
>
> when the case of the symbol's print name matters. if you need to match the
> case of an external representation it sometimes will. for program code it
> usually does not. one additional wrinkle is that, in the case where i would
> have cared with respect to program code there was a secondary concern, that,
> perhaps,
> - symbols were not the correct representation for the external data in the
> first place, and
> - it was not clear that one wanted to couple the case treatment of those data
> objects with the reader's case treatment for symbols.
I think that's the point: if you care, it's a strong indication that
you're using the wrong data structure. Sometimes this is due to
historical considerations -- the code may be derived from ancient code
that predated strings as Lisp data structures.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
From: Tim Bradshaw
Subject: Re: trying to understand packages
Date:
Message-ID: <ey37jy9hi0j.fsf@cley.com>
* Dave Roberts wrote:
> So the question is here, what is "good package programming style?" I see
> many people doing many things here (again, strings, symbols, keyword
> symbols, and, now with Kenny, uninterned symbols). Is there any particular
> style guide that says one particular way is preferred (akin to putting "*"
> on either end of a defvar special variable)? My guess is "No," since there
> are so many examples of different style out there. If that's the case, can
> a few people chime in here to "argue" for your preferred style.
I use keywords for package names and uninterned symbols as designators
for (the names of) symbols concerned with the package. Thus:
(defpackage :org.tfeb.utils.foo
(:use :cl)
(:export #:grunge #:bash))
Using symbols (either keywords, or other interned or uninterned
symbols) avoids many issues with the case of things. One well-known
implementation (ACL) has a mode where things are defaultly lower-case,
and in this mode
(defpackage "ORG.TFEB.UTILS.FOO"
(:use "CL")
(:export "GRUNGE" ...))
won't do what you probably expect.
The interned/uninterned symbol difference is really because I don't
care about cluttering the keyword package with a few symbols, but I
don't want to put potentially significant numbers there. I don't want
to clutter the dynamically current package at read-time at all, hence
no unqualified symbols. I suspect a decent DEFPACKAGE would to
macroexpand to something that didn't intern symbols anyway, so this
may be moot at load-time (but probably isn't at compile-time)
--tim