Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Default package use list

6 views
Skip to first unread message

Marco Antoniotti

unread,
Mar 11, 1998, 3:00:00 AM3/11/98
to

Hello

looks like I have problems with my news reader.

I'd like to know how you can find out what is the default package use
list supplied to DEFPACKAGE and friends. In CMUCL you have
*DEFAULT-PACKAGE-USE-LIST*.

I'd like info about

Lispworks
Allegro
MCL
GCL
CLISP

Please answer in private and tell me also what are the necessary
features to discriminate among the various cases (especially wrt the
underlying OS).

--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 80 79 23, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it

Barry Margolin

unread,
Mar 12, 1998, 3:00:00 AM3/12/98
to

In article <lwogzdq...@galvani.parades.rm.cnr.it>,

Marco Antoniotti <mar...@galvani.parades.rm.cnr.it> wrote:
>looks like I have problems with my news reader.

Your first post showed up fine.

>I'd like to know how you can find out what is the default package use
>list supplied to DEFPACKAGE and friends. In CMUCL you have
>*DEFAULT-PACKAGE-USE-LIST*.

(defun default-package-use-list ()
(let* ((name (loop for name = (gensym)
unless (find-package name) return name))
(package (make-package name))
(use-list (package-use-list package)))
(delete-package package)
use-list))

--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.

Kent M Pitman

unread,
Mar 12, 1998, 3:00:00 AM3/12/98
to

Barry Margolin <bar...@bbnplanet.com> writes:

> >I'd like to know how you can find out what is the default package use
> >list supplied to DEFPACKAGE and friends. In CMUCL you have
> >*DEFAULT-PACKAGE-USE-LIST*.
>

> (defun default-package-use-list () ...)

Barry's code looks good to me, but I have to ask--how is this
question fundamentally different than the question "what value
is given to an uninitialized array element?"

Personally, I voted for defining the package use list to something
portable, but I didn't get my way. But given that the definition
is as it is, isn't the obvious thing simply to always specify a
package use list and then not hae to care?

Obviously code-walking code that wants to understand the effect of
another package cannot do this, but in a certain sense, such code
can't (without quantifying over every possible implementation) know
the the answer and might as well assume it to be "undefined".

Failing to specify a package is conforming, in that it is not
forbidden. However it asks for an effect that is not portably
defined. As a consequence, any code written in the resulting package
is not conforming. And so the degree to which it's menaingful to even
say the DEFPACKAGE itself is conforming is quite minimal.

Erik Naggum

unread,
Mar 12, 1998, 3:00:00 AM3/12/98
to

* Marco Antoniotti

| I'd like to know how you can find out what is the default package use
| list supplied to DEFPACKAGE and friends.

hm. it's harder to discover GETENV implementations on your own, so I can
see why you need that, but can you not call PACKAGE-USE-LIST and know for
certain in a case like this? and if it is controlled by a variable, you
don't know for certain, anyhow, do you?

#:Erik
--
God grant me serenity to accept the code I cannot change,
courage to change the code I can, and wisdom to know the difference.

Marco Antoniotti

unread,
Mar 12, 1998, 3:00:00 AM3/12/98
to

Erik Naggum <cle...@naggum.no> writes:

> * Marco Antoniotti
> | I'd like to know how you can find out what is the default package use
> | list supplied to DEFPACKAGE and friends.
>
> hm. it's harder to discover GETENV implementations on your own, so I can
> see why you need that, but can you not call PACKAGE-USE-LIST and know for
> certain in a case like this? and if it is controlled by a variable, you
> don't know for certain, anyhow, do you?

I cannot test all the CL implementations. Anyway, I was just being
lazy. Barry Margolin's solution is definitively the catch-all that I
should have come up with in the first place :}

Erik Naggum

unread,
Mar 13, 1998, 3:00:00 AM3/13/98
to

* Marco Antoniotti -> Kent Pitman
| If I understood well what you just said, in order to write, if not quite
| "conforming", "maximally portable" code, it becomes imperative to know
| with accuracy the 'default-package-use-list' used in the major CL
| implementations.

hm. I have taken a somewhat differing view. I always specify :USE to
DEFPACKAGE and MAKE-PACKAGE, and so I know exactly what to expect. in
particular, you can get seriously burned if the default package-use-list
happens to make two different packages share a symbol and you try to use
it for something useful in both packages.

e.g., I had been irritated at the rule that I could not define anything
of interest for symbols in the COMMON-LISP package for quite a while, and
made a habit out of turning off the annoying package-lock warnings in
Allegro CL (Unix). so I wrote a lot more code with this habit in place,
and lo and behold, I used a name for a class that just happened to be in
the COMMON-LISP package from two packages. thus came enlightenment.

Kent M Pitman

unread,
Mar 14, 1998, 3:00:00 AM3/14/98
to

Marco Antoniotti <mar...@galvani.parades.rm.cnr.it> writes:

> Kent M Pitman <pit...@world.std.com> writes:
>
> > Barry's code looks good to me, but I have to ask--how is this
> > question fundamentally different than the question "what value
> > is given to an uninitialized array element?"

> ...


> > Failing to specify a package is conforming, in that it is not
> > forbidden. However it asks for an effect that is not portably
> > defined. As a consequence, any code written in the resulting package
> > is not conforming. And so the degree to which it's menaingful to even
> > say the DEFPACKAGE itself is conforming is quite minimal.
>

> If I understood well what you just said, in order to write, if not
> quite "conforming", "maximally portable" code, it becomes imperative to know
> with accuracy the 'default-package-use-list' used in the major CL
> implementations.

No. As Erik noted, what I said was that "maximally portable" code is
correctly achieved by never allowing this to default; simply :use
what you want. Why adopt probabilistic semantics when determinism is
within your grasp?

As a good rule of thumb, behaving as if unspecified things were forbidden
is what leads to maximally portable code.

Marco Antoniotti

unread,
Mar 15, 1998, 3:00:00 AM3/15/98
to

This is indeed what I assume while I program in CL. However, I
believe you should not assume that people using your code adhere to
your self-imposed rules.

0 new messages