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: RG on 27 Apr 2010 12:36 In article <hr6veq$a2l$1(a)news.eternal-september.org>, Tim Bradshaw <tfb(a)tfeb.org> wrote: > On 2010-04-27 15:32:08 +0100, RG said: > > > In article <hr678c$m2$1(a)news.eternal-september.org>, > > Tim Bradshaw <tfb(a)tfeb.org> wrote: > >> > >> This is a terribly important distinction. > > > > It can be, for example if you unexport a symbol: > > Yes, I was agreeing with you! Sorry, my sarcasto-meter was set to hair-trigger mode. rg
From: Thomas A. Russ on 27 Apr 2010 12:46 "Captain Obvious" <udodenko(a)users.sourceforge.net> writes: > TAR> In the second case, the default behavior and common practice is to use > TAR> symbols in the keyword package to denote the keyword arguments to > TAR> functions and init arguments. But this is just the default behavior > TAR> and it isn't required by the standard. For example, nothing stops a > TAR> programmer from using symbols in their own package, thusly: > > This is was an example why "keywords in other packages" could be useful. > Did you read the whole message or just code part? Sure I read the whole message, and pointed out that keywords, in the sense of &key parameters can already live in other packages. > TAR> (make-instance 'baz 'foo:frob 1 'bar:frob "Mary") > > If you did not export frob, it would be: > > (make-instance 'baz 'foo::frob 1 'bar::frob "Mary") > > Quite clumsy, if you ask me. It is clear, however, that if you have keywords in other packages, you won't have the same convenience because you would have to specify that other package unless you happened to be operating inside the other package. The syntactic beauty of keywords relies on its unique ability to use the empty string as a synonym for the KEYWORD package. > If you define frob like that: > > (defconstant %frob '%frob) > (export %frob) Well, this is easy enough to do with macro, if that is what you want. The other question is whether you would want to make sure you shadow the symbol, just in case it already exists and is imported? Anyway, if you want to do that, a quick macro might help: (defmacro defkeyword (symbol) `(progn (defconstant ,name ',name) (export ',name))) Then you could use (defkeyword frozz) to create a new keyword with the effects you want. > > Then you can write > > (make-instance 'baz foo:%frob 1 bar:%frob "Mary") > > Arguably, it is better because you don't need to quote "keywords" and > you can instantly tell aparet parameter names from parameter values. Hmmm. I don't buy that. Except perhaps for a special naming convention of using %, I don't see how you can tell the difference. And % is often used to indicate internal functions or variables, so that isn't a great choice to indicate pseudo-keywords. > Maybe it is still quite clumsy, but we're speaking about language > design, and I'm sure that there is some syntax sugar to make these > keyword-like symbols better than ordinary quoted symbols. Well, you still need to have some way to indicate the package that these other keyword symbols are in, so there is an information theoretic argument that says you can't do very much with syntactic sugar. At best you can save the quote character by making them self evaluating constants. -- Thomas A. Russ, USC/Information Sciences Institute
From: Zach Beane on 27 Apr 2010 14:18 tar(a)sevak.isi.edu (Thomas A. Russ) writes: > The syntactic beauty of keywords relies on its unique ability > to use the empty string as a synonym for the KEYWORD package. Your wording makes me wonder what the reader should do when it encounters ||:FOO. Implementations differ, and I wonder which approach is best justified by the standard. Zach
From: RG on 27 Apr 2010 15:59 In article <4bd4b295$0$281$14726298(a)news.sunsite.dk>, "Captain Obvious" <udodenko(a)users.sourceforge.net> wrote: > j> There is no reason that I know of why a symbol cannot exist in > j> multiple > j> packages without loosing identity. If package A "uses" package B, I > j> would expect the common symbols to be identical. At least A::foo and > j> B::foo would refer to the same object. right? > > But symbol has only one home package. > > ??>> My impression is just that it is unclear _what_ > ??>> you are trying to achieve. > > j> Sorry, but i'm not really at liberty to explain what I'm trying to > j> achieve, but that should not be necessary in order to understand why > certain > j> choices were made in the CL specification. > > You're pretty much answering your own question. > > Good language should have mostly practically useful stuff. > > I guess you have at least some CL programming experience and yet you can't > say why "keywords in other packages" might be useful. This probably means > that those uses are rare. > > And it answers why "keywords in other packages" are not in CL spec -- they > are not important enough. > And as CL is flexible enough to allow users to implement similar things > themselves, it is not a big deal even if there is some use. > > Well, with an inspiration from Pascal Costanza I've found one such case -- > when symbols from different, unrelated pieces of code (and thus from > different packages) are used in one list. For example, in initarg list in > make-instance call. > For example, two classes might be defined in different packages and they > have slot with same name: > > (in-package :foo) > > (defclass foo () > ((frob :initarg :frob))) > > (in-package :bar) > > (defclass bar () > ((frob :initarg :frob))) > > And you want to use both these classes as ancestors: > > (in-package :baz) > > (defclass baz (foo bar) > ()) > > (make-instance 'baz :frob 1) > > Now, even if slot names look same, they are different: foo::frob in first > case and bar::frob in second. > But initargs are keywords and they are same, so you cannot initialize both > foo::frob and bar::frob via initarg :frob. Actually you can. You just can't initialize them to different values: ? (in-package :p1) #<Package "P1"> ? (defclass c1 () ((x :initarg :x))) #<STANDARD-CLASS C1> ? (in-package :p2) #<Package "P2"> ? (defclass c1 () ((x :initarg :x))) #<STANDARD-CLASS C1> ? (in-package :p3) #<Package "P3"> ? (defclass c1 (p1::c1 p2::c1) ()) #<STANDARD-CLASS C1> ? (make-instance 'c1 :x 1) #<C1 #x302000F9EC8D> ? (describe *) #<C1 #x302000E2CE6D> Class: #<STANDARD-CLASS C1> Wrapper: #<CCL::CLASS-WRAPPER C1 #x302000E2BB7D> Instance slots P2::X: 1 P1::X: 1 ? > But cases like this are very rare, I think. Indeed. rg
From: Thomas A. Russ on 27 Apr 2010 16:29
Zach Beane <xach(a)xach.com> writes: > tar(a)sevak.isi.edu (Thomas A. Russ) writes: > > > The syntactic beauty of keywords relies on its unique ability > > to use the empty string as a synonym for the KEYWORD package. > > Your wording makes me wonder what the reader should do when it > encounters ||:FOO. Implementations differ, and I wonder which approach > is best justified by the standard. Ah, I didn't think about that, but now I recall encountering something like that once while playing around with package nicknames. I think I was probably a bit too loose with the terminology and had forgotten that the empty string and not having any package identifier are actually different. That also explains why "" is not a package-nickname of the KEYWORD package. -- Thomas A. Russ, USC/Information Sciences Institute |