·····@sip.medizin.uni-ulm.de (kp gores) writes:
> hello,
> i have some package problems which may be easy to solve:
>
> CLOS 2nd ed says (p. 273) defpackage canT be used to define mutually
> recursive packages. it recommends to use defpackage for initial setup
> only.
>
> how do i define 2 or more packages using each other, i.e. which order of
> package commands is correct?
> eg:
>
> (defpackage :bla)
> (in-package :bla)
>
> (export '(...))
>
> and then:
> (require 'blabla "<path to blabla>")
> (import '(..) blabla)
>
> and the same in package blabla??
No. This is not how it works. You can't use import. You must use
USE (i.e. USE-PACKAGE or :USE). USE effectively does lazy importation
because you specify a package name, not individual symbols, and
because the package has to maintain the information indirect through
the package or it won't catch updates. That's how you get around the
circularity. It only marks the package as having a search list of the
other package, allowing the package to actually be searched later on
when both packages exist and the symbols in question are actually
demanded. IMPORT will force immediate creation of the symbols and
will make a mess.
Kent M Pitman <······@world.std.com> writes:
> ·····@sip.medizin.uni-ulm.de (kp gores) writes:
>
> > hello,
> > i have some package problems which may be easy to solve:
> >
> > CLOS 2nd ed says (p. 273) defpackage canT be used to define mutually
> > recursive packages. it recommends to use defpackage for initial setup
> > only.
> >
> > how do i define 2 or more packages using each other, i.e. which order of
> > package commands is correct?
> > eg:
> >
> > (defpackage :bla)
> > (in-package :bla)
> >
> > (export '(...))
> >
> > and then:
> > (require 'blabla "<path to blabla>")
> > (import '(..) blabla)
> >
> > and the same in package blabla??
>
> No. This is not how it works. You can't use import. You must use
> USE (i.e. USE-PACKAGE or :USE). USE effectively does lazy importation
> because you specify a package name, not individual symbols, and
> because the package has to maintain the information indirect through
> the package or it won't catch updates. That's how you get around the
> circularity. It only marks the package as having a search list of the
> other package, allowing the package to actually be searched later on
> when both packages exist and the symbols in question are actually
> demanded. IMPORT will force immediate creation of the symbols and
> will make a mess.
I got a hitch to scratch! :)
I believe there is one missing functionality in the package system
which would make life easier in some situations (which I have in mind,
but for which the margin left by my mailer is too small to fit them
:)).
One of the characteristics of IMPORT is that it makes the symbol
"present" in the package.
I would like a (I know very very costly) way to USE-SYMBOL, i.e. to
make a symbol (list of symbols) "accessible" in a package without
making it "present".
What do you think about it?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
* Marco Antoniotti wrote:
> I would like a (I know very very costly) way to USE-SYMBOL, i.e. to
> make a symbol (list of symbols) "accessible" in a package without
> making it "present".
I don't know how you'd fit that into the way the package system works,
but you can achieve sort-of the same effect by defining a third
package, importing the symbols you care about into that, then using
that package from the client package.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> * Marco Antoniotti wrote:
>
>
> > I would like a (I know very very costly) way to USE-SYMBOL, i.e. to
> > make a symbol (list of symbols) "accessible" in a package without
> > making it "present".
>
> I don't know how you'd fit that into the way the package system works,
> but you can achieve sort-of the same effect by defining a third
> package, importing the symbols you care about into that, then using
> that package from the client package.
... and why shouldn't you be able to do that automatically? :)
Anyway, this is not very important. Useful, but not that important.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
* Marco Antoniotti wrote:
> ... and why shouldn't you be able to do that automatically? :)
You can, if you do some macrology (which I have, I will try and clean
it up and put it up for ftp somewhere). I agree though that there are
some things you'd like to do but are a bit clunky with the existing
package system.
Something else that was pointed out to me (by KMP?) was that it would
be really nice to be able to say when exporting a symbol that you want
it to be defaultly shadowing, which would enable you to define simply
packages that clobber bits of CL (you can do this already but you have
to do another version of the third-package trick, and it's also a bit
clunky.
I think a slightly souped up package system might be an interesting
thing for some revision of the current standard to have -- it's
probably not that hard to implement, and it would be quite useful.
--tim