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: Thomas A. Russ on 26 Apr 2010 12:59 jimka <jimka(a)rdrop.com> writes: > Can someone explain the motiviation for the behavior of READ in the > following situations. > > 1. If the package "P" does not exist then P::name triggers an error. > It seems another quite reasonable behavior might be that READ should > simply create the package. No 1. Because it would cover up typing errors or failure to load files or systems. 2. Because the system wouldn't know which options to give to DEFPACKAGE and it would surely get it wrong. > 2. If the package "P" exists but does not contain "NAME", then P::name > interns "NAME" into P. It seems another resonable behavior might be to > allow the caller to determine whether or not to automatically intern > new symbols. No. 1. You would go crazy trying to read anything into lisp, since the reader will encounter all sorts of new names. 2. It's not clear what behavior you want from this. a. Is it then an error to encounter a new symbol? b. Do you prompt the user? 3. Who is the caller? This is done at READ time and not at evaluation time. So by the time there is a caller of any function other than things like LOAD, COMPILE-FILE, READ, etc. any symbol manipulation has already been done. > 3. If the packagte "P" exists and contains "NAME", but "NAME" is not > interned or not exported, the reader signals an error when > cncountering P:NAME. Another reasonable behavior might be to allow > the caller to opt for automatically interning and exporting the > symbol. Maybe. But there are issues: 1. This would have to be a package level option. 2. It creates issues for automatic name conflicts if any other package were to :USE an automatically exporting package because new symbols could be exported at any time. > 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? Answered in other posts. -- Thomas A. Russ, USC/Information Sciences Institute
From: Pascal J. Bourguignon on 26 Apr 2010 14:07 Stelian Ionescu <sionescu(a)cddr.org> writes: > On Mon, 26 Apr 2010 01:14:23 +0200, Pascal J. Bourguignon wrote: >> (make-instance 'baz foo:frob 1 bar:frob 2) >> >> There! >> You have different keywords named the same in two different packages! > > Lol, we posted nearly identical examples. Btw, you forgot to QUOTE > foo:frob and bar:frob I declared them as self evaluating constants. -- __Pascal Bourguignon__
From: RG on 26 Apr 2010 18:20 In article <ymioch6xilo.fsf(a)blackcat.isi.edu>, tar(a)sevak.isi.edu (Thomas A. Russ) wrote: > jimka <jimka(a)rdrop.com> writes: > > > 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? > > No. Symbols in two packages are definitely not EQ. They cannot be the > same object. Of course they can. You yourself point this out: > Now, if you IMPORT a symbol from package A into package B, then you just > have one symbol that is ACCESSIBLE (via the reader) from either > package. But it is just one symbol, namely the one in package A. > > For example, if you did > > (defpackage a) > (in-package :a) > 'a > > (defpackage b (:import a::a)) > > (eq 'a 'a::a) => T > > (symbol-package 'a) => <Package A> > (symbol-package 'b::a) => <Package A> Here's an even starker example: ? (make-package :p1) #<Package "P1"> ? (make-package :p2) #<Package "P2"> ? (import 'p1::x :p2) T ? (eq 'p1::x 'p2::x) T ? (eq (intern "X" :p1) (intern "X" :p2)) T You are confusing the concept of being interned in a package with the concept of a symbol's home package. A single symbol can be interned in multiple packages, but it can have at most one home package. A symbol need not have a home package to be interned in one or more packages: ? (symbol-package 'p1::x) #<Package "P1"> ? (unintern 'p1::x :p1) T ? (symbol-package 'p2::x) NIL ? 'p2::x #:X > > Isn't this what the :use keyword does on defpackage? It assures you > > that the symbols with the same name are eq. > > No, what :USE does is import all of the exported symbols of the named > packages. No, what :use does is make those symbols accessible by inheritance. This has much the same effect as importing all the external symbols of the used package, but it specifically does NOT cause those symbols to be present (which is a precisely defined term in CLHS) in the using package. rg
From: Tim Bradshaw on 27 Apr 2010 04:29 On 2010-04-26 23:20:17 +0100, RG said: > No, what :use does is make those symbols accessible by inheritance. > This has much the same effect as importing all the external symbols of > the used package, but it specifically does NOT cause those symbols to be > present (which is a precisely defined term in CLHS) in the using package. This is a terribly important distinction.
From: Captain Obvious on 27 Apr 2010 05:19
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? 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. If you define frob like that: (defconstant %frob '%frob) (export %frob) 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. 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. |