Re: packages: how would I do this
From: Kent M Pitman (pitman_at_nhplace.com)
Date: 11/16/03
- Next message: Pascal Costanza: "Re: More static type fun."
- Previous message: Damien Kick: "Re: Question about design, defmacro, macrolet, and &environment"
- In reply to: Henrik Motakef: "Re: packages: how would I do this"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 15 Nov 2003 20:34:34 -0500
Henrik Motakef <usenet-reply@henrik-motakef.de> writes:
> Lowell <lkirsh@cs.ubc.ca> writes:
>
> > ... &optional (pprint (if (find-package 'pp) #'pp:pp #'pprint)))
> >
> > But if I don't have package pp loaded already, then this causes a read
> > error. How can I get around this?
>
> (if (find-package 'pp)
> (symbol-function (intern "PP" "PP"))
> #'pprint)
This is true, but the question is why you wouldn't have the PP
package loaded. In general, I think provisionally loadable stuff
like this is awful. We used to do lots more of this back when address
spaces are small, but increasingly I just don't see the point.
Note that another way to do it is to require not PP but MY-PP where
MY-PP has (a) a variable *MY-PPRINT-DISPATCH* that is initially #'pprint
and (b) a LOAD-PP function that both loads the PP package and also
sets *MY-PPRINT-DISPATCH* to PP:PP. In this way, the other package
can just (funcall my-pp:*my-pprint-dispatch* ...) and optionally use
(my-pp:load-pp) if needed.
If the reason you're worried about PP is that it's not available on
all systems (one of the few cases where conditional loading seems to be
something that's needed), making a stub version that just defines
PP:PP as a synonym for PPRINT is yet a third way.
- Next message: Pascal Costanza: "Re: More static type fun."
- Previous message: Damien Kick: "Re: Question about design, defmacro, macrolet, and &environment"
- In reply to: Henrik Motakef: "Re: packages: how would I do this"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]