I've seen two patterns for defining packages, systems, etc:
(defpackage #:foo ...)
(in-package #:foo)
(defsystem #:foo ...)
or:
(defpackage "FOO" ...)
(in-package "FOO")
(defsystem "FOO" ...)
What are the benefits/trade-offs/portability issues that would make
one method better than the other?
thx -
--
Michael J. Barillier | ``When you have to shoot,
blackwolf(at)shadizar.dyndns.org | shoot. Don't talk.''
http://shadizar.dyndns.org/~blackwolf/ | -- Tuco Ramirez
Public key 0x35E54973: EDB9 4FBC 4D0B 070C C0E3 2EE4 D822 78CE 35E5 4973
Michael J. Barillier wrote:
> I've seen two patterns for defining packages, systems, etc:
>
> (defpackage #:foo ...)
> (in-package #:foo)
> (defsystem #:foo ...)
>
> or:
>
> (defpackage "FOO" ...)
> (in-package "FOO")
> (defsystem "FOO" ...)
>
> What are the benefits/trade-offs/portability issues that would make
> one method better than the other?
Common Lisp allows you to change the way how a readtable interns
symbols. By default, symbols are converted to upper case internally -
that's why the strings in the second example are all upper case. It
could happen that your source code needs to be loaded with different
readtable settings, and then the #: notation is potentially somewhat
more robust. But I'd guess that in practice this doesn't matter much.
Pascal
Pascal Costanza wrote:
> Michael J. Barillier wrote:
>
>> I've seen two patterns for defining packages, systems, etc:
>>
>> (defpackage #:foo ...)
>> (in-package #:foo)
>> (defsystem #:foo ...)
>>
>> or:
>>
>> (defpackage "FOO" ...)
>> (in-package "FOO")
>> (defsystem "FOO" ...)
>>
>> What are the benefits/trade-offs/portability issues that would make
>> one method better than the other?
>
>
> Common Lisp allows you to change the way how a readtable interns
> symbols. By default, symbols are converted to upper case internally -
> that's why the strings in the second example are all upper case. It
> could happen that your source code needs to be loaded with different
> readtable settings, and then the #: notation is potentially somewhat
> more robust. But I'd guess that in practice this doesn't matter much.
The only thing that matters in this case is whether unreferenced
uninterned symbols get collected or not.
Cheers
--
Marco
Marco Antoniotti wrote:
>
> Pascal Costanza wrote:
>
>> Michael J. Barillier wrote:
>>
>>> I've seen two patterns for defining packages, systems, etc:
>>>
>>> (defpackage #:foo ...)
>>> (in-package #:foo)
>>> (defsystem #:foo ...)
>>>
>>> or:
>>>
>>> (defpackage "FOO" ...)
>>> (in-package "FOO")
>>> (defsystem "FOO" ...)
>>>
>>> What are the benefits/trade-offs/portability issues that would make
>>> one method better than the other?
>>
>> Common Lisp allows you to change the way how a readtable interns
>> symbols. By default, symbols are converted to upper case internally -
>> that's why the strings in the second example are all upper case. It
>> could happen that your source code needs to be loaded with different
>> readtable settings, and then the #: notation is potentially somewhat
>> more robust. But I'd guess that in practice this doesn't matter much.
>
> The only thing that matters in this case is whether unreferenced
> uninterned symbols get collected or not.
Why should they not get collected?
Pascal
Pascal Costanza wrote:
> Marco Antoniotti wrote:
>
>>
>> Pascal Costanza wrote:
>>
>>> Michael J. Barillier wrote:
>>>
>>>> I've seen two patterns for defining packages, systems, etc:
>>>>
>>>> (defpackage #:foo ...)
>>>> (in-package #:foo)
>>>> (defsystem #:foo ...)
>>>>
>>>> or:
>>>>
>>>> (defpackage "FOO" ...)
>>>> (in-package "FOO")
>>>> (defsystem "FOO" ...)
>>>>
>>>> What are the benefits/trade-offs/portability issues that would make
>>>> one method better than the other?
>>>
>>>
>>> Common Lisp allows you to change the way how a readtable interns
>>> symbols. By default, symbols are converted to upper case internally -
>>> that's why the strings in the second example are all upper case. It
>>> could happen that your source code needs to be loaded with different
>>> readtable settings, and then the #: notation is potentially somewhat
>>> more robust. But I'd guess that in practice this doesn't matter much.
>>
>>
>> The only thing that matters in this case is whether unreferenced
>> uninterned symbols get collected or not.
>
>
> Why should they not get collected?
They are in several implementations. But there is no guarantee. I did
make a mistake my statement though. Of course, they'd get collected if
they were completely unreferenced. However, it may happen that the
DEFPACKAGE form keeps them around. I know it's paranoid..... :)
Cheers
--
Marco
From: Kent M Pitman
Subject: Re: Keywords v. strings for identifiers
Date:
Message-ID: <upsx7gffs.fsf@nhplace.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:
>>> The only thing that matters in this case is whether unreferenced
>>> uninterned symbols get collected or not.
>> Why should they not get collected?
> They are in several implementations. But there is no guarantee.
This is intended to be dealt with by the wonders of commercial
pressure...
If you have an application that is not getting small enough, and this
is the reason, report it as a bug notwithstanding the absent
requirement of the language. The reason they should get collected is
not because the spec says so--it's because you can prove there's no
reason not to, and it's good engineering practice to keep things tidy.
Trivia: In PDP10 Maclisp, there was a function GCTWA [for "Garbage
Collect Truly Worthless Atoms"] that told the GC you wanted to do
this.
> I did make a mistake my statement though. Of course, they'd get
> collected if they were completely unreferenced. However, it may
> happen that the DEFPACKAGE form keeps them around. I know it's
> paranoid..... :)
Yes, Maclisp didn't have packages but did have a single thing called
an "obarrays" which was the one and only one place into which things
were interned. (It was possible, with much work, to make multiple
ones, but I think the only real case where this was done was in the
implementation of the compiler, which had a compiler obarray to keep
its symbols separate from the user's obarray.) But the point is that
indeed, the reflective capability to observe the presence in the
obarray or the package structure means the symbol technically can't be
gc'd. However, if no one holds a pointer other than that, the only
downside of uninterning (carrying on with the triviafest: Maclisp
called this remob'ing) was that there could be situations in which you
were needlessly adding and removing these things from the package
(obarray) structure and so doing extra pieces of bookkeeping for
nothing. In applications that you knew would call READ (for example)
a whole lot, you might not want to bother removing symbols that READ
might need to spontaneously (re)create, while in other applications
you know better.
From: Edi Weitz
Subject: Re: Keywords v. strings for identifiers
Date:
Message-ID: <ubr8uuudj.fsf@agharta.de>
On Mon, 04 Apr 2005 14:50:10 -0500, Michael J. Barillier <········@midsouth.rr.com> wrote:
> I've seen two patterns for defining packages, systems, etc:
>
> (defpackage #:foo ...)
> (in-package #:foo)
> (defsystem #:foo ...)
>
> or:
>
> (defpackage "FOO" ...)
> (in-package "FOO")
> (defsystem "FOO" ...)
>
> What are the benefits/trade-offs/portability issues that would make
> one method better than the other?
Both versions should work fine with all ANSI-compliant Lisps. In
practice, though, at least Corman Common Lisp chokes on the first
version while AllegroCL in "modern" mode deliberately deviates from
the standard and won't work as expected with the second version.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")