Package Query
in [Lisp]
|
Prev: A link to a collection of tutorials on LISP.
Next: A link to a collection of tutorials on LISP.
From: Peter Keller on 28 Jun 2010 00:53 RG <rNOSPAMon(a)flownet.com> wrote: > The reason I'm putting "contents" in scare quotes is because Lispers > don't generally speak of symbols having "contents", they speak of > symbols having various kinds of BINDINGS, which is almost certainly what > you mean when you say "contents", but you'll be less confused if you > stick with established terminology. You are correct. I know what bindings are and what they mean, but haven't yet finished reconciling that knowledge with the concept of lisp packages yet. I soon will and all will be well. Oddly, lisp packaging explanations seem to disassociate symbol importing/exporting and bindings so much, that it can be confusing when you encounter a problem to figure out exactly what is going wrong. Most of my problems are of the form "Why is this (often bare) symbol not in the package I expect it to be in?" and concern themselves with symbols produced from macro expansion. Later, -pete
From: RG on 28 Jun 2010 03:57 In article <i099ru$4i3$1(a)news.eternal-september.org>, Peter Keller <psilord(a)cs.wisc.edu> wrote: > Oddly, lisp packaging explanations seem to > disassociate symbol importing/exporting and bindings so much, If you think this is odd then you have missed something very fundamental. Packages have nothing to do with bindings, so it is not at all odd that explanations of packages should have nothing to do with bindings. Packages are just data structures that map strings onto symbols. Don't make it more complicated than it is. rg
From: Peter Keller on 28 Jun 2010 12:28 RG <rNOSPAMon(a)flownet.com> wrote: > If you think this is odd then you have missed something very > fundamental. Packages have nothing to do with bindings, so it is not at > all odd that explanations of packages should have nothing to do with > bindings. What's the point of exporting a symbol if you don't care about either its binding or the fact it is eq to itself inside of the library the package is for? It is my understanding the keyword package is an specialization of the latter idea. > Packages are just data structures that map strings onto symbols. Don't > make it more complicated than it is. Saying it isn't more complicated than it is is somewhat disingenuous. I say. this because because the string "A::B" turns into the symbol |A::B| with make-symbol and you can't get the binding for it as you'd expect because what you really wanted was |A|::|B|. This notion right here is what I spent a good long time figuring out and understanding. The part that finally made me figure it out was realizing that A::B is often and erronously loosely talked about like the entire thing is a symbol, but it isn't, It is the symbol B with a package prefix A. This is the difference between (intern "A" "B") and (intern "A::B"). Once I really understood that difference, I understood many of the problems I was having. Hence this is why one should be careful talking about strings as being mapped into symbols and should make mention that package prefixes with the colons are not a part of the symbol name. In addition, this is why I was a bit confused by Pascal's PRINT-READABLY solution, I kept grouping the package prefix and symbol name into the whole thing being a symbol, and that was wrong. -pete
From: RG on 28 Jun 2010 12:57 In article <i0aiir$r92$1(a)news.eternal-september.org>, Peter Keller <psilord(a)cs.wisc.edu> wrote: > RG <rNOSPAMon(a)flownet.com> wrote: > > If you think this is odd then you have missed something very > > fundamental. Packages have nothing to do with bindings, so it is not at > > all odd that explanations of packages should have nothing to do with > > bindings. > > What's the point of exporting a symbol if you don't care about either its > binding or the fact it is eq to itself inside of the library the package is > for? Of course you normally care about the bindings. But those have nothing to do with packages. Bindings are associated with symbol, and symbols are normally interned in packages, but these are two completely orthogonal features. You can have symbols in packages without bindings,and you an have symbols with bindings that are not in any package. Different language features that both just happen to involve symbols. > Saying it isn't more complicated than it is is somewhat disingenuous. I say. > this because because the string "A::B" turns into the symbol |A::B| with > make-symbol and you can't get the binding for it as you'd expect because what > you really wanted was |A|::|B|. This notion right here is what I spent a > good > long time figuring out and understanding. The part that finally made me > figure > it out was realizing that A::B is often and erronously loosely talked about > like the entire thing is a symbol, but it isn't, It is the symbol B with a > package prefix A. > > This is the difference between (intern "A" "B") and (intern "A::B"). You are confusing the concept of a package (which is simple) with the syntax used by the reader to produce symbols from strings, which is indeed somewhat complicated. The string "A::B" does indeed produce different results when processed by MAKE-SYMBOL than it does when processed by READ, but that should not be too surprising because, well, they are different functions that do different things. But at root what you get is a symbol that may or may not be interned in one or more packages. The symbol has a name which may or may not include colons. But making symbols whose names include colons is generally frowned upon for reasons that you seem to have discovered the hard way. I think your entire problem is a failure to understand the difference between (make-symbol "A::B") and (read-from-string "A::B"). The former gives you a (uninterned) symbol whose name is "A::B", and the latter gives you a symbol whose name is "B" and is interned in package "A". That's it. rg
From: Alessio Stalla on 28 Jun 2010 14:19
On 28 Giu, 18:28, Peter Keller <psil...(a)cs.wisc.edu> wrote: > The part that finally made me figure > it out was realizing that A::B is often and erronously loosely talked about > like the entire thing is a symbol, but it isn't, It is the symbol B with a > package prefix A. You're making confusion. It makes no sense to talk about "the symbol B with a package prefix A" because there are no such things as symbols with a package prefix and symbols without. A::B is the string representation of a symbol that the reader recognizes. But a symbol itself is neither B nor A::B, it's an object in memory. Since symbols are identifiers that are often read and written by humans it makes sense to give a human-readable representation of them, hence the A::B notation. > This is the difference between (intern "A" "B") and (intern "A::B"). > > Once I really understood that difference, I understood many of the problems I > was having. Hence this is why one should be careful talking about strings as > being mapped into symbols and should make mention that package prefixes with > the colons are not a part of the symbol name. Strings *are* mapped to symbols - by means of packages. A package is precisely a mapping from strings to symbols. For convenience CL has the concept of the "current package", the value of the *package* variable, that instructs the reader on which package to intern unqualified symbols in. But if CL hadn't that feature, you would always write symbols in their fully qualified notation, to indicate which package to use to map the string naming the symbol to the symbol object. Cheers, Alessio |