questions about packages
in [Lisp]
|
Prev: ☆☉☉☆ Barely Legal Babes - Free downloads! Videos Images, Barely Legal young teens
Next: does sort always sort vectors in place?
From: Tamas K Papp on 25 Apr 2010 12:14 On Sun, 25 Apr 2010 08:54:52 -0700, jimka wrote: >> 4. All keywords go into the same package. "KEYWORD". What causes the >> evaluator to evaluate keywords to themselves? Is it that they exist in >> this package? The CL syntax for keywords is that the a : preceed the >> name. Other than this extremly handy syntax, is there any other reason >> one might want all keywords in the same package? Is there an >> reasonable argument to allow keywords in other packages? Restated, >> suppose a lisp did not support the : synax for keywords but insisted >> that keywords by identifyable by their inital character being "?". >> Would their be an advantage for that lisp to force all such keywords >> into the same package? >> >> -jim > > It's obvious from the responses to this question that the question is > not stated very well. :-( Let me retry. > > Common lisp, keywords happen to have three very useful properties. 1. > they always evaluate to themselves 2. they always parse to the same > symbol, regardless of the value of *current-package* > 3. key all have (are in) the same package: "KEYWORD" > > These three properties are really orthogonal, but is it nice the CL > makes > sure they are all true simultaneously Does it make sense to separate 2 and 3? If they parse to they same thing anyway, what's the point in having them reside in a separate package? > If the only lisp you have ever used is common lisp or something very > common lisp-like, you might understandably have trouble seperating > the two concepts as you have not so many example of symbols which > exhibit one behavior without exhibiting the other. (T is an example > of a symbol which exhibits #1 and #2, but not #3) It beats be why you are assuming that people "have trouble separating the two concepts". My impression is just that it is unclear _what_ you are trying to achieve. Or, to put it differently, if you have a different behavior (which you would have to specify), what would be the advantage? Speculating about "why X" is useless, unless there is an (implicit) comparison to some viable alternative. > #1 means you cannot do the following > (setq :key 42) > will fail, but (eq :key ':key) returns t. > > #2 means that even if the following functions are defined in different > packages, ... > > ;; in package A > (defun fun1 (x) > (eq x ':key)) > > ;; in package B > (defun fun2 (x) > (eq x ':key)) > > ...the the two functions behave the exact behavior, as opposed to the > following two functions which exhibit different behavior. > > ;; in package A > (defun fun3 (x) > (eq x 'key)) > > ;; in package B > (defun fun4 (x) > (eq x 'key)) > > Now because CL combines #1 and #2, you can write fun1 and fun2 without > quoting the keyword. > > Now, what was my question? > > It was basically this: if a lisp allows users to create symbols which > have attribute #1 > or #2 independently, does this eliminate the need for a single package > which contains them all? What would be the point? If they always parse to the same symbol, that symbol will be in some package. It makes sense for these things to be in a single package. > So I don't understand whether CL conflates the 3 attributes into one > because it only makes sense to do so, or whether the choice is an > arbitrary one. It is a good design choice. The keywords package is special in many respects: eg its symbols don't have to be exported, so they can be used anywhere without further ado. But if you really, really want to separate some behavior, you can easily define symbols which evaluate to themselves, make ? a reader macro, etc. So instead of asking the big "Why?" question, why don't you show us what you would gain by those solutions? Tamas
From: Pascal J. Bourguignon on 25 Apr 2010 12:43 jimka <jimka(a)rdrop.com> writes: >> 4. All keywords go into the same package. "KEYWORD". What causes the >> evaluator to evaluate keywords to themselves? Is it that they exist >> in this package? The CL syntax for keywords is that the a : preceed >> the name. Other than this extremly handy syntax, is there any other >> reason one might want all keywords in the same package? Is there an >> reasonable argument to allow keywords in other packages? Restated, >> suppose a lisp did not support the : synax for keywords but insisted >> that keywords by identifyable by their inital character being "?". >> Would their be an advantage for that lisp to force all such keywords >> into the same package? >> >> -jim > > It's obvious from the responses to this question that the question is > not stated very well. :-( Let me retry. > > Common lisp, keywords happen to have three very useful properties. > 1. they always evaluate to themselves > 2. they always parse to the same symbol, regardless of the value of > *current-package* C/USER[33]> *current-package* *** - SYSTEM::READ-EVAL-PRINT: variable *CURRENT-PACKAGE* has no value What are you talking about??? > 3. key all have (are in) the same package: "KEYWORD" CLHS keyword says: Interning a symbol in the KEYWORD package has three automatic effects: 1. It causes the symbol to become bound to itself. 2. It causes the symbol to become an external symbol of the KEYWORD package. 3. It causes the symbol to become a constant variable. ^^^^^^^^ Your expression "always evaluate to themselves" is not precise enough. > These three properties are really orthogonal, but is it nice the CL > makes > sure they are all true simultaneously > > If the only lisp you have ever used is common lisp or something very > common > lisp-like, you might understandably have trouble seperating the two > concepts > as you have not so many example of symbols which exhibit one behavior > without > exhibiting the other. (T is an example of a symbol which exhibits #1 > and #2, > but not #3) > > #1 means you cannot do the following > (setq :key 42) > will fail, but (eq :key ':key) returns t. It fails not because of your #1, but because of CLHS 3. Not because they "'always' evaluate to themselves", but because they're constant variables. > #2 means that even if the following functions are defined in different > packages, ... "functions are defined in different packages" is meaningless. In Common Lisp, you can only INTERN a string, giving you an interned symbol. Packages only contain symbols. Sometimes, it may happen, but not always, some functions may be fbound to symbols, who are not necessarily interned in a package. On the other hand, as I explained in my other answer, when reading a symbol (included the keywords), they are interned, at read time. If you don't change cl:*package* between reading the following forms, then indeed all the symbols naming the defined functions will be interned in the same package, the one bound to cl:*package* (and all the keywords read are always interned in the package named "KEYWORD"). > ;; in package A > (defun fun1 (x) > (eq x ':key)) > > ;; in package B > (defun fun2 (x) > (eq x ':key)) > > ...the the two functions behave the exact behavior, as opposed to the > following two functions which exhibit different behavior. > > ;; in package A > (defun fun3 (x) > (eq x 'key)) > > ;; in package B > (defun fun4 (x) > (eq x 'key)) No, for this, you would have to use (in-package "A") in (in-package "B") instead of comments. Comments don't have any semantic effect. > Now because CL combines #1 and #2, you can write fun1 and fun2 without > quoting the keyword. > > Now, what was my question? > > It was basically this: if a lisp allows users to create symbols which > have attribute #1 > or #2 independently, does this eliminate the need for a single package > which contains them all? Because of your point #2, two keywords that are written the same must be interned in the same package. (imply (equal (symbol-name k1) (symbol-name k2)) (eql (symbol-package k1) (symbol-package k2))) So you're asking why not putting different keyords in different package? But I ask what would be the point? > So I don't understand whether CL conflates the 3 attributes into one > because it only makes > sense to do so, or whether the choice is an arbitrary one. It does not. Taking the three properties of a real CL keyword: 1. It causes the symbol to become bound to itself. 2. It causes the symbol to become an external symbol of the KEYWORD package. 3. It causes the symbol to become a constant variable. as you mentionned, they're orthogonal, and you can have symbols in all sets, replacing 2. by "It causes the symbol to become an external symbol of some package P." {} (defvar x 42) {1} (defvar x 'x) {2} (intern "X" "P") (export 'p::x) {1,2} (defvar p::x 'p::x) (export 'p::x) {3} (defconstant x 42) {1,3} (defconstant x 'x) {2,3} (defconstant p::x 42) (export 'p::x) {1,2,3} (defconstant p::x 'p::x) (export 'p::x) the whole without using the package named "KEYWORD". Or said otherwise, if you want to have symbols that are constants evaluating to themselves that are exported different packages, nothing prevents you to have them, and if you want to do so from a reader macro, there's no difficulty either. So to answer your question, the KEYWORD package is an arbitrary choice. (But so is 90% of the rest of the language, and 99.9999999999% of the world). -- __Pascal Bourguignon__
From: Pascal Costanza on 25 Apr 2010 12:44 On 25/04/2010 17:54, jimka wrote: > >> 4. All keywords go into the same package. "KEYWORD". What causes the >> evaluator to evaluate keywords to themselves? Is it that they exist >> in this package? The CL syntax for keywords is that the a : preceed >> the name. Other than this extremly handy syntax, is there any other >> reason one might want all keywords in the same package? Is there an >> reasonable argument to allow keywords in other packages? Restated, >> suppose a lisp did not support the : synax for keywords but insisted >> that keywords by identifyable by their inital character being "?". >> Would their be an advantage for that lisp to force all such keywords >> into the same package? >> >> -jim > > It's obvious from the responses to this question that the question is > not stated very well. :-( Let me retry. > > Common lisp, keywords happen to have three very useful properties. > 1. they always evaluate to themselves > 2. they always parse to the same symbol, regardless of the value of > *current-package* > 3. key all have (are in) the same package: "KEYWORD" Most of the time, you want to use symbols because of their identity. Packages help to deal with potential name clashes, in that they divide the available namespace into separate units that can be viewed in isolation, but can also communicate with each via exports and imports. There are, however, cases where the symbol identity doesn't matter, and this is primarily when you want to use symbols as keys referring only indirectly to other values, such as in alists, plists, keyword paramater lists, etc. They _can_ be put all in the same package _because_ their identities don't matter, and this makes it easier to test for their equivalence, i.e., by using the efficient identity test 'eq. That they evaluate to themselves is an added convenience: It doesn't make sense that they evaluate to something else (i.e., to an 'actual' value), otherwise it would be better to keep them in separate packages in the first place to avoid potential nameclashes. Instead of keeping their symbol value undefined, they can just evaluate to themselves, which adds the convenience that you don't have to remember when and when not to quote them. This is quite nice, especially when writing macros, but not essential. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: jimka on 25 Apr 2010 12:45 > Does it make sense to separate 2 and 3? If they parse to they same > thing anyway, what's the point in having them reside in a separate > package? > It is a little bit hard to think about this abstractly I suppose. A real example would certainly help; I agree. There is no reason that I know of why a symbol cannot exist in multiple packages without loosing identity. If package A "uses" package B, I would expect the common symbols to be identical. At least A::foo and B::foo would refer to the same object. right? > My impression is just that it is unclear _what_ > you are trying to achieve. Sorry, but i'm not really at liberty to explain what I'm trying to achieve, but that should not be necessary in order to understand why certain choices were made in the CL specification. > Or, to put it differently, if you have a > different behavior (which you would have to specify), what would be > the advantage? Speculating about "why X" is useless, unless there is > an (implicit) comparison to some viable alternative. It is not that I necessarily want a differnt behavior. If someone is specifying a feature for lisp-foo, it is not really a sufficient argument to say, "You should do it like Common Lisp". But rather, "Common Lisp does it this way, and here is why...". Often the design choices in the CL spec are very well conceived, sometimes they are arbitrary, sometimes they are the lesser of two evils, and sometimes they are mistakes. -jim
From: jimka on 25 Apr 2010 12:58
On Apr 25, 6:01 pm, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > jimka <ji...(a)rdrop.com> writes: > > 4. All keywords go into the same package. "KEYWORD". What causes the > > evaluator to evaluate keywords to themselves? Is it that they exist > > in this package? The CL syntax for keywords is that the a : preceed > > the name. Other than this extremly handy syntax, is there any other > > reason one might want all keywords in the same package? > > (eq ':x ':x) --> true is a good reason. > Maybe there is somthing fundamental that I misunderstand about CL packages. Isn't it possible for symbols in two pacakges to be eq? Isn't this what the :use keyword does on defpackage? It assures you that the symbols with the same name are eq. -jim |