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 15:44 RG <rNOSPAMon(a)flownet.com> wrote: > 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". I would say that's a fair assesment of what I had misunderstood. Thanks to all for helping me out. -pete
From: Scott L. Burson on 28 Jun 2010 16:09 On Jun 28, 12:44 pm, Peter Keller <psil...(a)cs.wisc.edu> wrote: > RG <rNOSPA...(a)flownet.com> wrote: > > 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". > > I would say that's a fair assesment of what I had misunderstood. Please don't take Ron's grumpy impatience with you ("your entire problem is a failure to understand...") personally. Packages are indeed a little confusing at first (I certainly recall finding them so). People who are familiar with a concept sometimes forget that the concept was once not so obvious to them. -- Scott
From: RG on 28 Jun 2010 16:36 In article <61c35d14-07ab-41e1-8c40-37623ab2569e(a)b33g2000prd.googlegroups.com>, "Scott L. Burson" <gyro(a)zeta-soft.com> wrote: > On Jun 28, 12:44 pm, Peter Keller <psil...(a)cs.wisc.edu> wrote: > > RG <rNOSPA...(a)flownet.com> wrote: > > > 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". > > > > I would say that's a fair assesment of what I had misunderstood. > > Please don't take Ron's grumpy impatience with you ("your entire > problem is a failure to understand...") personally. Packages are > indeed a little confusing at first (I certainly recall finding them > so). People who are familiar with a concept sometimes forget that the > concept was once not so obvious to them. > > -- Scott Sorry, I didn't mean for that to come out like grumpy impatience. I rather meant it as "you're not really as confused as you think you are." :-) rg
From: Peter Keller on 28 Jun 2010 17:23 RG <rNOSPAMon(a)flownet.com> wrote: > In article > <61c35d14-07ab-41e1-8c40-37623ab2569e(a)b33g2000prd.googlegroups.com>, > "Scott L. Burson" <gyro(a)zeta-soft.com> wrote: > >> On Jun 28, 12:44?pm, Peter Keller <psil...(a)cs.wisc.edu> wrote: >> > RG <rNOSPA...(a)flownet.com> wrote: >> > > 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". ? >> > >> > I would say that's a fair assesment of what I had misunderstood. >> >> Please don't take Ron's grumpy impatience with you ("your entire >> problem is a failure to understand...") personally. Packages are >> indeed a little confusing at first (I certainly recall finding them >> so). People who are familiar with a concept sometimes forget that the >> concept was once not so obvious to them. >> >> -- Scott > > Sorry, I didn't mean for that to come out like grumpy impatience. I > rather meant it as "you're not really as confused as you think you are." > :-) No worries! I figure it'll be a couple of years of writing lisp before I really start to understand certain concepts intuitively, and maybe a decade before I understand how to recognize and natively perform The Lisp Way. I know and wrote in Scheme for a long time, so I'm not that far off from the lisp way as it stands. I know that the lisp code I'll be releasing might not be as lispy as it could be, but I know that it'll be tested, robust, reliable, and it'll solve my, and hopefully other people's, problems. And in my grizzled age, that's good enough for me. I have good understanding that as my experience in writing actual lisp grows, so will my craft of it. I very much appreciate the time you folks spend, uh, figuring out what I'm trying to ask, :) and then answering my questions. Thank you. Later, -pete
From: Thomas A. Russ on 28 Jun 2010 18:06
Peter Keller <psilord(a)cs.wisc.edu> writes: > > 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? Symbols are always EQ to themselves regardless of packages. All packages do is to determine how a string name is mapped to a symbol. Bindings and function values and class definitions, etc. are all properties of the symbol and have nothing to do with packages. Once you have the symbol, you get all of its bindings, propeties, defintions, and anything else associated with it. But that has nothing to do with packages. As to export, there are really only two effects of exporting a symbol from a package: (1) You only need a single colon to refer to it in fully qualified form. This is perhaps a bit trivial, but it serves as a reminder about which symbols are part of an external interface. (2) If you USE the package, you get (only) the exported symbols of the package you are using. >It is my understanding the keyword package is an specialization of the > latter idea. No. The keyword package just has the special property that all of the symbols are constants that evaluate to themselves. > > 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|. Well, that is because you used the wrong name. To an experienced lisper, this complaint is the same as saying that the strings "FOO" and "BAR" turn into different symbols and you can't get the binding you want. It is important to realize that to unambiguously designate a symbol you need its full name, which is the combination of package name and symbol name. It's also similar to why (with the standard reader settings) 'foo and '|foo| give you different symbols. Packages affect the READing of symbols. They don't affect other operations like MAKE-SYMBOL or intern where you are giving the name of a symbol. What is confusing you is that there are multiple means of getting to a symbol and you do not have a full grasp of where the mapping is taking place in the process. If you want the symbol A::B, then there are several ways to get it: 'A::B (read-from-string "A::B") (intern "B" "A") If you want the symbol |A::B| in the current package you would use slightly different ways to get it: '|A::B| (read-from-string "|A::B|") (intern "A::B") ; Note no package argument! Conceptually you can think of the creation of (interned) symbols as always grounding out in a call to the function INTERN, which takes a symbol-name and a package as its arguments. The colon syntax is used by the reader to transform a string representation of a symbol into an appropriate call to the INTERN function. > 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. No. This is incorrect. The entire thing is a representation of a symbol. There is no symbol B with a package prefix. There is only the symbol which has the symbol name B and package A It is (usually)* different from the symbol which has the symbol name B and package C. > This is the difference between (intern "A" "B") and (intern "A::B"). No. The difference is that you have two different symbols. One in the package "B" with the name "A" and the other in the current package with name "A::B". Perhaps what confuses you is the fact that lisp is sufficiently flexible in what are allowed as symbol names that you can include all sorts of white space, punctuation, etc. that in most other languages would not be syntactically allowed as identifier names. That is why you can have the symbol |(+ 2 2)| and even be somewhat perverse as say (setq |(+ 2 2)| 5) (+ 2 2) ==> 4 |(+ 2 2)| ==> 5 > 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. That is correct when you use the narrow technical meaning of "symbol name". Unfortunately, and perhaps confusinginly, there is a broader meaning of symbol name in the sense of how you refer to a symbol, which in precise terms is perhaps better called the fully qualified 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. Well, that is because the package name plus the symbol name IS what you need to unambiguously refer to a symbol regardless of which package it is in. It is just a convenience that there is a current package in which all new symbols will be interned and which is used to lookup symbols without package qualifiers. (It is a very useful convenience for readability). But you really need both the symbol package and symbol name to identify the symbol. * There was a rather esoteric discussion of this issue a while back in the newsgroup. -- Thomas A. Russ, USC/Information Sciences Institute |