"Vladimir V. Zolotych" <······@eurocom.od.ua> writes:
> (defpackage my-package
> (:nicknames myp :myp)
> (:use common-lisp)
> (:export foo))
>
> ....
>
> What happens ? Please explain me what I've done wrong.
When the reader reads the defpackage form, a symbol "FOO" is interned
in the current package. This causes the later clash.
To avoid this kind of behaviour, write your defpackage as
(defpackage my-package
(:nicknames :myp)
(:use :common-lisp)
(:export "FOO"))
so that a "FOO" symbol isn't created by the process of
reading the form.
In article <·················@eurocom.od.ua>, "Vladimir V. Zolotych"
<······@eurocom.od.ua> wrote:
> Using CMUCL 18c
>
> The following (simple-package.lisp):
>
> (eval-when (:compile-toplevel :load-toplevel :execute)
> (unless (find-package :myp)
> (make-package "MY-PACKAGE"
> :nicknames '(myp :myp)
> :use '("COMMON-LISP"))))
Package names are looked up as strings, so a package
nickname "MYP", myp or :myp has the same effect.
> (in-package :myp)
> (export 'foo)
So here you are inside package MYP. The symbol
is MYP::FOO when reading the form
and after exporting it is MYP:FOO.
> I've tried to use DEFPACKAGE (file simple-package2.lisp)
>
> (defpackage my-package
> (:nicknames myp :myp)
> (:use common-lisp)
> (:export foo))
You are creating or accessing a symbol FOO in some package.
It is in the package where the DEFPACKAGE form is read - so
maybe CL-USER. Which may create CL-USER::FOO .
Additionally you are exporting a symbol MYP:FOO.
So it is better to write:
(defpackage "MY-PACKAGE"
(:nicknames "MYP")
(:use "COMMON-LISP")
(:export "FOO"))
Above form contains not any "unwanted" symbols.
> (in-package :myp) ; is it necessary ?
Yes. DEFPACKAGE does only declare a package.
It does not change the default package.
> (defun foo () "foo")
> (defun bar () "bar")
>
> * (load "/home/vlz/cmucl/simple-package2.x86f")
> T
> * (myp:foo)
> "foo"
> * (use-package :myp)
>
>
> Error in function USE-PACKAGE:
> Use'ing package MY-PACKAGE results in name conflicts for these
> symbols:
> (FOO)
Your DEFPACKAGE form introduced (and/or referenced) CL-USER::FOO and
MYP:FOO . Which are different symbols.
Now you are trying to "use" the package MYP in CL-USER.
Thus you get the conflict, because the Lisp wants
to make MYP:FOO accessible as FOO inside package CL-USER
and there is already another FOO inside CL-USER.
> Restarts:
> 0: [CONTINUE] Unintern the conflicting symbols in the COMMON-LISP-USER
> package.
> 1: [ABORT ] Return to Top-Level.
>
> Debug (type H for help)
>
> (USE-PACKAGE :MYP #<The COMMON-LISP-USER package, 4/9 internal, 0/9
> external>)
> 0]
So, you have choices:
a) choose the CONTINUE restart. Which will unintern CL-USER::FOO.
Maybe you want to keep your CL-USER::FOO, though.
b) prevent the creation of CL-USER::FOO. See above my DEFPACKAGE.
c) don't export MYP::FOO .
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig <······@corporate-world.lisp.de> writes:
> > I've tried to use DEFPACKAGE (file simple-package2.lisp)
> >
> > (defpackage my-package
> > (:nicknames myp :myp)
> > (:use common-lisp)
> > (:export foo))
>
> You are creating or accessing a symbol FOO in some package.
> It is in the package where the DEFPACKAGE form is read - so
> maybe CL-USER. Which may create CL-USER::FOO .
> Additionally you are exporting a symbol MYP:FOO.
>
> So it is better to write:
>
> (defpackage "MY-PACKAGE"
> (:nicknames "MYP")
> (:use "COMMON-LISP")
> (:export "FOO"))
I prefer to write this way:
(defpackage :my-package
(:nicknames :myp)
(:use :common-lisp)
(:export #:foo))
Janis Dzerins
--
If million people say a stupid thing it's still a stupid thing.
In article <··············@asaka.latnet.lv>, Janis Dzerins
<·····@latnet.lv> wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > > I've tried to use DEFPACKAGE (file simple-package2.lisp)
> > >
> > > (defpackage my-package
> > > (:nicknames myp :myp)
> > > (:use common-lisp)
> > > (:export foo))
> >
> > You are creating or accessing a symbol FOO in some package.
> > It is in the package where the DEFPACKAGE form is read - so
> > maybe CL-USER. Which may create CL-USER::FOO .
> > Additionally you are exporting a symbol MYP:FOO.
> >
> > So it is better to write:
> >
> > (defpackage "MY-PACKAGE"
> > (:nicknames "MYP")
> > (:use "COMMON-LISP")
> > (:export "FOO"))
>
> I prefer to write this way:
>
> (defpackage :my-package
> (:nicknames :myp)
> (:use :common-lisp)
> (:export #:foo))
This is better than referring to symbols in other packages
(than the keyword package) - IMHO - but:
This creates symbols in the keyword package plus a
non-interned symbol.
A symbol internally can be seen as a vector of several things:
- a package cell -> package
- a name cell -> string
- a value cell -> any value
- a property list -> NIL or CONS
- a function cell -> any value, usually a FUNCTION
Additionally the symbol takes space in the package's
symbol table.
A string is just a string.
An uninterned symbol leads to (eq '#:foo '#:foo) -> NIL .
Which means you create two symbols - losing the
advantage of interned symbols.
So, if you look for space efficiency depending on the
context you want:
- interned symbols, because they can be reused and
referencing them uses a pointer
- strings, because they don't have the symbol overhead
(just the name, no value, no package, no property list,
no function cell, no reference in the package).
Actually as a style issue, *I* don't like to populate
packages with random symbols. In a large software system
one ends up with random symbols in packages (especially
the keyword package tends to get "misused" for all kinds
of symbols). A symbol in a package should be there for a
reason. Using symbols as indirect
references sometimes leads to package bloat.
I use packages as dictionaries and I query them
for entries to access names. If one populates packages
with random symbols, the value of the query results
degrades.
To give an example with MCL.
I have completion for:
MULT -> finds something starting with MULT in the current package
m-v-b -> finds something starting with substrings M, V and B.
which in CL-USER is likely to find MULTIPLE-VALUE-BIND
:m-v -> would find something starting with substrings M and V
in the KEYWORD package
cl:m-v -> same as above in the CL package
m-v -> can also be used with completion over all packages.
This takes about one second in my Lisp image with
about 57000 symbols in 59 packages.
(multiple results bring up a window with the choices)
So, getting a small set of matching symbols back from a completion
query speeds up input of code in the editor (additionally
to MOUSE-COPY/PASTE, SPACE as arglist lookup, etc.). This is how *I*
use it. If I need tables with fast lookup, I'm using hashtables.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <··············@asaka.latnet.lv>, Janis Dzerins
> <·····@latnet.lv> wrote:
>
> > Rainer Joswig <······@corporate-world.lisp.de> writes:
> >
> > > > I've tried to use DEFPACKAGE (file simple-package2.lisp)
> > > >
> > > > (defpackage my-package
> > > > (:nicknames myp :myp)
> > > > (:use common-lisp)
> > > > (:export foo))
> > >
> > > You are creating or accessing a symbol FOO in some package.
> > > It is in the package where the DEFPACKAGE form is read - so
> > > maybe CL-USER. Which may create CL-USER::FOO .
> > > Additionally you are exporting a symbol MYP:FOO.
> > >
> > > So it is better to write:
> > >
> > > (defpackage "MY-PACKAGE"
> > > (:nicknames "MYP")
> > > (:use "COMMON-LISP")
> > > (:export "FOO"))
> >
> > I prefer to write this way:
> >
> > (defpackage :my-package
> > (:nicknames :myp)
> > (:use :common-lisp)
> > (:export #:foo))
>
> This is better than referring to symbols in other packages
> (than the keyword package) - IMHO - but:
>
> This creates symbols in the keyword package plus a
> non-interned symbol.
This is true. However, if the defpackage form is not captured
(i.e. in '* or any other history mechanism that the lisp might
have), then it will be garbage-collected and all of its components
(including the uninterned symbol) will be gone.
> A symbol internally can be seen as a vector of several things:
>
> - a package cell -> package
> - a name cell -> string
> - a value cell -> any value
> - a property list -> NIL or CONS
> - a function cell -> any value, usually a FUNCTION
>
> Additionally the symbol takes space in the package's
> symbol table.
>
> A string is just a string.
And a garbage-collected uninterned symbol and a string take up
equivalent space.
[ ... ]
> Actually as a style issue, *I* don't like to populate
> packages with random symbols.
Symbols placed into a package are never random. The only symbols in
a package are the ones that have been created by internment into the
package. All other "random" symbols have no direct relationship to
the package.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
In article <·············@beta.franz.com>, Duane Rettig
<·····@franz.com> wrote:
> > > (defpackage :my-package
> > > (:nicknames :myp)
> > > (:use :common-lisp)
> > > (:export #:foo))
> >
> > This is better than referring to symbols in other packages
> > (than the keyword package) - IMHO - but:
> >
> > This creates symbols in the keyword package plus a
> > non-interned symbol.
>
> This is true. However, if the defpackage form is not captured
> (i.e. in '* or any other history mechanism that the lisp might
> have), then it will be garbage-collected and all of its components
> (including the uninterned symbol) will be gone.
This depends on the particular expansion of DEFPACKAGE
and how you read this stuff into your Lisp.
> > A symbol internally can be seen as a vector of several things:
> >
> > - a package cell -> package
> > - a name cell -> string
> > - a value cell -> any value
> > - a property list -> NIL or CONS
> > - a function cell -> any value, usually a FUNCTION
> >
> > Additionally the symbol takes space in the package's
> > symbol table.
> >
> > A string is just a string.
>
> And a garbage-collected uninterned symbol and a string take up
> equivalent space.
Uninterned symbols still have:
- various cells
- and an indirection to the name
> Symbols placed into a package are never random. The only symbols in
> a package are the ones that have been created by internment into the
> package. All other "random" symbols have no direct relationship to
> the package.
I mean by "random" using symbols for naming issues where
the symbols are not really the names (in which package the
names for packages should be? or are they uninterned?).
A symbol is not the name of a package. PACKAGE-NAME does
not return a symbol, it returns a string.
Let's create a package FOOBARFOOBAR:
? (make-package "FOOBARFOOBAR")
#<Package "FOOBARFOOBAR">
? (do-all-symbols (symbol)
(when (string-equal (symbol-name symbol) "FOOBARFOOBAR")
(print symbol)))
NIL
There is no interned symbol FOOBARFOOBAR anywhere.
Let's create a package via :BAZBAZBAZBAZ
? (make-package :BAZBAZBAZBAZ)
#<Package "BAZBAZBAZBAZ">
? (do-all-symbols (symbol)
(when (string-equal (symbol-name symbol) "BAZBAZBAZBAZ")
(print symbol)))
:BAZBAZBAZBAZ
NIL
?
So we had the side effect of creating the symbol. This is all
very unimportant if you have not much packages (my Genera
image has only 179 packages), it can be pain if you have
a lot of symbols (and use long export lists in DEFPACKAGE
for example).
ANSI CL says about that:
The macroexpansion of defpackage could usefully
canonicalize the names into strings, so that even if a
source file has random symbols in the defpackage form,
the compiled file would only contain strings.
It says "COULD" when you have a situation where you
compile a file (also assuming that the Lisp system
is not recording the source forms).
If one is not controlling where and how one is creating
symbols, this ***might*** be a space leak.
Rainer Joswig
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <·············@beta.franz.com>, Duane Rettig
> <·····@franz.com> wrote:
>
> > > > (defpackage :my-package
> > > > (:nicknames :myp)
> > > > (:use :common-lisp)
> > > > (:export #:foo))
> > >
> > > This is better than referring to symbols in other packages
> > > (than the keyword package) - IMHO - but:
> > >
> > > This creates symbols in the keyword package plus a
> > > non-interned symbol.
> >
> > This is true. However, if the defpackage form is not captured
> > (i.e. in '* or any other history mechanism that the lisp might
> > have), then it will be garbage-collected and all of its components
> > (including the uninterned symbol) will be gone.
>
> This depends on the particular expansion of DEFPACKAGE
> and how you read this stuff into your Lisp.
Precisely. You are answering an ease-of-use issue with an efficiency
argument. These are not the same, but they are also not incompatible.
Thus, if you want efficiency and don't care about ease-of-use, you
can just use strings. But if you care both about efficiency and
ease-of-use, you can use uninterned symbols and ensure that the
defpackage form is in a compiled file.
> > > A symbol internally can be seen as a vector of several things:
> > >
> > > - a package cell -> package
> > > - a name cell -> string
> > > - a value cell -> any value
> > > - a property list -> NIL or CONS
> > > - a function cell -> any value, usually a FUNCTION
> > >
> > > Additionally the symbol takes space in the package's
> > > symbol table.
> > >
> > > A string is just a string.
> >
> > And a garbage-collected uninterned symbol and a string take up
> > equivalent space.
>
> Uninterned symbols still have:
>
> - various cells
What various cells? If the symbol is garbage-collected, so will any
various cells that were not shared by something else anyway.
> - and an indirection to the name
What indirection? As above, any references that the uninterned symbol
makes are garbage-collected with it.
> > Symbols placed into a package are never random. The only symbols in
> > a package are the ones that have been created by internment into the
> > package. All other "random" symbols have no direct relationship to
> > the package.
>
> I mean by "random" using symbols for naming issues where
> the symbols are not really the names (in which package the
> names for packages should be? or are they uninterned?).
> A symbol is not the name of a package. PACKAGE-NAME does
> not return a symbol, it returns a string.
>
> Let's create a package FOOBARFOOBAR:
>
> ? (make-package "FOOBARFOOBAR")
> #<Package "FOOBARFOOBAR">
>
> ? (do-all-symbols (symbol)
> (when (string-equal (symbol-name symbol) "FOOBARFOOBAR")
> (print symbol)))
> NIL
>
> There is no interned symbol FOOBARFOOBAR anywhere.
>
> Let's create a package via :BAZBAZBAZBAZ
>
> ? (make-package :BAZBAZBAZBAZ)
> #<Package "BAZBAZBAZBAZ">
>
> ? (do-all-symbols (symbol)
> (when (string-equal (symbol-name symbol) "BAZBAZBAZBAZ")
> (print symbol)))
>
> :BAZBAZBAZBAZ
> NIL
> ?
Try (make-package '#:BAZBAZBAZBAZ)
or (make-package '#:bazbazbazbaz)
Incidentally, the do-all-symbols form does _not_ check whether a symbol
exists in your system or not, because do-all-symbols only iterates over
packages. So although the form you are running above will not show the
#:bazbazbazbaz symbol which probably still exists in the heap. If your
implementation has a tool that will walk the lisp heap searching for
objects, then you would be able to see that #:bazbazbazbaz still exists
when the make-package form is typed at the top-level. But it will also
reveal that no such symbol exists when the form is loaded from a
compiled file, possibly after a global gc.
> So we had the side effect of creating the symbol. This is all
> very unimportant if you have not much packages (my Genera
> image has only 179 packages), it can be pain if you have
> a lot of symbols (and use long export lists in DEFPACKAGE
> for example).
>
> ANSI CL says about that:
>
> The macroexpansion of defpackage could usefully
> canonicalize the names into strings, so that even if a
> source file has random symbols in the defpackage form,
> the compiled file would only contain strings.
>
> It says "COULD" when you have a situation where you
> compile a file (also assuming that the Lisp system
> is not recording the source forms).
>
> If one is not controlling where and how one is creating
> symbols, this ***might*** be a space leak.
This gets back to the issue of efficiency, which I assume you are
concerned with. If you are not concerned with ease-of-use, you can
just use strings in your defpackage form; just be sure to get the case
of the symbol names right. If you are concerned about ease-of-use as
well as efficiency, and if your lisp creates a space leak and thereby
does not provide the efficiency you desire, then you should use a lisp
which does.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
In article <·············@beta.franz.com>, Duane Rettig
<·····@franz.com> wrote:
> > > And a garbage-collected uninterned symbol and a string take up
> > > equivalent space.
> >
> > Uninterned symbols still have:
> >
> > - various cells
>
> What various cells? If the symbol is garbage-collected, so will any
> various cells that were not shared by something else anyway.
If it is GCed. You are assuming that it is file compiled
and the references are replaced. Which will usually be the
case - unless the uninterned symbols are referenced
somewhere (for example inside functions).
> > Let's create a package FOOBARFOOBAR:
> >
> > ? (make-package "FOOBARFOOBAR")
> > #<Package "FOOBARFOOBAR">
> >
> > ? (do-all-symbols (symbol)
> > (when (string-equal (symbol-name symbol) "FOOBARFOOBAR")
> > (print symbol)))
> > NIL
> >
> > There is no interned symbol FOOBARFOOBAR anywhere.
> >
> > Let's create a package via :BAZBAZBAZBAZ
> >
> > ? (make-package :BAZBAZBAZBAZ)
> > #<Package "BAZBAZBAZBAZ">
> >
> > ? (do-all-symbols (symbol)
> > (when (string-equal (symbol-name symbol) "BAZBAZBAZBAZ")
> > (print symbol)))
> >
> > :BAZBAZBAZBAZ
> > NIL
> > ?
>
> Try (make-package '#:BAZBAZBAZBAZ)
> or (make-package '#:bazbazbazbaz)
With changing READTABLE-CASE or not? ;-)
> Incidentally, the do-all-symbols form does _not_ check whether a symbol
> exists in your system or not
Yes, that's is why I said INTERNED symbol. ;-)
> because do-all-symbols only iterates over
> packages. So although the form you are running above will not show the
> #:bazbazbazbaz symbol which probably still exists in the heap. If your
> implementation has a tool that will walk the lisp heap searching for
> objects, then you would be able to see that #:bazbazbazbaz still exists
> when the make-package form is typed at the top-level. But it will also
> reveal that no such symbol exists when the form is loaded from a
> compiled file, possibly after a global gc.
That's right.
> > If one is not controlling where and how one is creating
> > symbols, this ***might*** be a space leak.
>
> This gets back to the issue of efficiency,
A space leak is not about effiency, it is about whether
a certain program might run for a longer time or not.
If you have a web server in Lisp running for months,
and symbols are created, but not GCed, then the space
leak may eat up the available space (I'm reading a discussing
about that in a Lisp mailing list where a user has
a question about this topic.)
> which I assume you are
> concerned with. If you are not concerned with ease-of-use, you can
> just use strings in your defpackage form; just be sure to get the case
> of the symbol names right.
Which is why we have ANSI Common Lisp. If I follow the
rules of the ANSI standard, then it is relatively easy.
When I follow for example your advice, then I have to
worry about the situation dependend setting of
READTABLE-CASE.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <·············@beta.franz.com>, Duane Rettig
> <·····@franz.com> wrote:
>
> > > Let's create a package via :BAZBAZBAZBAZ
> > >
> > > ? (make-package :BAZBAZBAZBAZ)
> > > #<Package "BAZBAZBAZBAZ">
> > >
> > > ? (do-all-symbols (symbol)
> > > (when (string-equal (symbol-name symbol) "BAZBAZBAZBAZ")
> > > (print symbol)))
> > >
> > > :BAZBAZBAZBAZ
> > > NIL
> > > ?
> >
> > Try (make-package '#:BAZBAZBAZBAZ)
> > or (make-package '#:bazbazbazbaz)
>
> With changing READTABLE-CASE or not? ;-)
The answers to this question are the same as for any question dealing
with READTABLE-CASE:
CL-USER(1): (car '(foo))
FOO
CL-USER(2): (setf (readtable-case *readtable*) :downcase)
:|DOWNCASE|
CL-USER(3): (car '(foo))
Error: attempt to call `CAR' which is an undefined function.
[condition type: UNDEFINED-FUNCTION]
Restart actions (select using :continue):
0: Try calling CAR again.
1: Return a value instead of calling CAR.
2: Try calling a function other than CAR.
3: Setf the symbol-function of CAR and call it again.
4: Return to Top Level (an "abort" restart)
5: Abort #<PROCESS Initial Lisp Listener>
[1] CL-USER(4):
> > which I assume you are
> > concerned with. If you are not concerned with ease-of-use, you can
> > just use strings in your defpackage form; just be sure to get the case
> > of the symbol names right.
>
> Which is why we have ANSI Common Lisp. If I follow the
> rules of the ANSI standard, then it is relatively easy.
This is a non sequitur. In this thread, we have been discussing
ANSI CL, using ANSI lisps and ANSI rules. Please look up in your
favorite version of the ANSI spec the definition of cl:defpackage,
section 11.2.19, and look at what are specified for
defined-package-name, nickname, and symbol-name. Be sure to follow
the link to the definition of "string designator". When you are done,
please note that both:
(defpackage "FOO" ...) and (defpackage #:foo ...)
and
(:export "BAR") and (:export #:bar)
are _completely_ within the ANSI specification.
> When I follow for example your advice, then I have to
> worry about the situation dependend setting of
> READTABLE-CASE.
If you are in the habit of reading files with different readtable-cases,
I suspect that you have a lot more to worry about than the defpackage
form. But I am not giving you advice; I assume that you will do what
you want to do. I am, however, defending Janis Dzerins' right to use
an alternative and completely ANSI compliant approach.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
In article <·············@beta.franz.com>, Duane Rettig
<·····@franz.com> wrote:
> > > Try (make-package '#:BAZBAZBAZBAZ)
> > > or (make-package '#:bazbazbazbaz)
> >
> > With changing READTABLE-CASE or not? ;-)
>
> The answers to this question are the same as for any question dealing
> with READTABLE-CASE:
>
> CL-USER(1): (car '(foo))
> FOO
> CL-USER(2): (setf (readtable-case *readtable*) :downcase)
> :|DOWNCASE|
> CL-USER(3): (car '(foo))
> Error: attempt to call `CAR' which is an undefined function.
> [condition type: UNDEFINED-FUNCTION]
>
> Restart actions (select using :continue):
> 0: Try calling CAR again.
> 1: Return a value instead of calling CAR.
> 2: Try calling a function other than CAR.
> 3: Setf the symbol-function of CAR and call it again.
> 4: Return to Top Level (an "abort" restart)
> 5: Abort #<PROCESS Initial Lisp Listener>
> [1] CL-USER(4):
This changes in Franz' modern mode? Above code would run
then both ways?
> > > which I assume you are
> > > concerned with. If you are not concerned with ease-of-use, you can
> > > just use strings in your defpackage form; just be sure to get the case
> > > of the symbol names right.
> >
> > Which is why we have ANSI Common Lisp. If I follow the
> > rules of the ANSI standard, then it is relatively easy.
>
> This is a non sequitur. In this thread, we have been discussing
> ANSI CL, using ANSI lisps and ANSI rules.
Look in Janis' postings. (find-package "cl-user") returning
the CL-USER package didn'� look ANSI compliant to me.
> Please look up in your
> favorite version of the ANSI spec the definition of cl:defpackage,
> section 11.2.19, and look at what are specified for
> defined-package-name, nickname, and symbol-name. Be sure to follow
> the link to the definition of "string designator". When you are done,
> please note that both:
>
> (defpackage "FOO" ...) and (defpackage #:foo ...)
>
> and
>
> (:export "BAR") and (:export #:bar)
>
> are _completely_ within the ANSI specification.
Yes. That's right. I didn't say and didn't want to say
that using uninterned symbols is not ANSI compliant.
> > When I follow for example your advice, then I have to
> > worry about the situation dependend setting of
> > READTABLE-CASE.
>
> If you are in the habit of reading files with different readtable-cases,
> I suspect that you have a lot more to worry about than the defpackage
> form.
Sure, still using #:foo makes you not free from having to
think about case issues - this was my point.
> But I am not giving you advice; I assume that you will do what
> you want to do. I am, however, defending Janis Dzerins' right to use
> an alternative and completely ANSI compliant approach.
This right seems not to be in danger. In **my** view, using
uninterned symbols for example for denoting symbols in export lists
of a DEFPACKAGE is preferrable (just IMHO) to keyword symbols. You
also have shown some of the advantages. Still I even
more prefer to use strings to write down the names,
especially to avoid any unpreciseness in case issues.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig <······@corporate-world.lisp.de> writes:
> Look in Janis' postings. (find-package "cl-user") returning
> the CL-USER package didn'� look ANSI compliant to me.
Where did you see the (find-package "cl-user")?
Janis Dzerins
--
If million people say a stupid thing it's still a stupid thing.
In article <··············@asaka.latnet.lv>, Janis Dzerins
<·····@latnet.lv> wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > Look in Janis' postings. (find-package "cl-user") returning
> > the CL-USER package didn'� look ANSI compliant to me.
>
> Where did you see the (find-package "cl-user")?
Sorry for the confusion. It was in <··············@asaka.latnet.lv>:
"keyword" is not the name of the keyword package
in ANSI Common Lisp. So it was clear to me that you
were not using a "really trying to be ANSI compliant" Lisp.
cl-user(1): (find-symbol "common-lisp" (find-package "keyword"))
:common-lisp
:external
cl-user(2): (find-symbol "user" (find-package "keyword"))
:user
:external
cl-user(3): (find-symbol "cl" (find-package "keyword"))
:cl
:external
cl-user(4):
I did respond to that in <····························@news.is-europe.net>.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig <······@corporate-world.lisp.de> writes:
> "keyword" is not the name of the keyword package in ANSI Common
> Lisp.
That looks correct. But one can write it this way:
(find-package :keyword)
or
(find-package #:keyword)
As I stated earlier in the thread, I use keywords for package
names. The example I gave was just to show that there already are
those keywords I am using so I can freely do:
(in-package :user)
(use-package :myp)
etc.
That's ok with me. That's not ok with you. Let's let other people
choose.
> So it was clear to me that you were not using a "really trying to be
> ANSI compliant" Lisp.
That does not look correct.
Janis Dzerins
--
If million people say a stupid thing it's still a stupid thing.
In article <··············@asaka.latnet.lv>, Janis Dzerins
<·····@latnet.lv> wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > "keyword" is not the name of the keyword package in ANSI Common
> > Lisp.
>
> That looks correct. But one can write it this way:
>
> (find-package :keyword)
> or
> (find-package #:keyword)
>
> As I stated earlier in the thread, I use keywords for package
> names. The example I gave was just to show that there already are
> those keywords I am using so I can freely do:
>
> (in-package :user)
> (use-package :myp)
> etc.
>
> That's ok with me. That's not ok with you. Let's let other people
> choose.
It's just a style issue as I said. I prefer to use package and
symbol names directly. I didn't say that it is not ok.
> > So it was clear to me that you were not using a "really trying to be
> > ANSI compliant" Lisp.
>
> That does not look correct.
Any Common Lisp implementation that does not follow
the standard by
a) having lowercase names for predefined (by the standard)
packages "COMMON-LISP" and "COMMON-LISP-USER"
b) having lowercase names for predefined (by the standard)
names for symbols in the COMMON-LISP (or what
it claims to be the COMMON-LISP) package.
Both are *not* minor problems.
is violating the ANSI CL standard. Thus by freely doing
it so, the vendor is not trying to provide this
as an ANSI CL compliant Lisp implementation.
"modern mode" Allegro Common Lisp is not ANSI CL compliant
in this respect.
Franz provides a different mode, where Allegro Common Lisp
is ANSI compliant in this respect.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig <······@corporate-world.lisp.de> writes:
> "modern mode" Allegro Common Lisp is not ANSI CL compliant
> in this respect.
That is correct. Please see
http://www.franz.com/support/tech_corner/modern.mode.php3
for further info.
> Franz provides a different mode, where Allegro Common Lisp
> is ANSI compliant in this respect.
Also correct.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Rainer Joswig <······@corporate-world.lisp.de> writes:
> Any Common Lisp implementation that does not follow
> the standard by
>
> a) having lowercase names for predefined (by the standard)
> packages "COMMON-LISP" and "COMMON-LISP-USER"
Any CL implementation is free to have "common-lisp" and
"common-lisp-user" packages, just as it is free to have "EXTENSIONS",
"CCL", "KERNEL", "HCL", etc. packages.
> b) having lowercase names for predefined (by the standard)
> names for symbols in the COMMON-LISP (or what
> it claims to be the COMMON-LISP) package.
Having lower-case exported names for predefined symbols in
COMMON-LISP, would not be compliant. Having lower-case exported names
for "predefined" symbols in "common-lisp" would still leave an
implementation compliant, since the ANSI standard doesn't mandate
anything for the contents of the "common-lisp" package.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <··············@asaka.latnet.lv>, Janis Dzerins
> <·····@latnet.lv> wrote:
>
> > Rainer Joswig <······@corporate-world.lisp.de> writes:
> >
> > > So it is better to write:
> > >
> > > (defpackage "MY-PACKAGE"
> > > (:nicknames "MYP")
> > > (:use "COMMON-LISP")
> > > (:export "FOO"))
> >
> > I prefer to write this way:
> >
> > (defpackage :my-package
> > (:nicknames :myp)
> > (:use :common-lisp)
> > (:export #:foo))
>
> This is better than referring to symbols in other packages
> (than the keyword package) - IMHO - but:
>
> This creates symbols in the keyword package plus a
> non-interned symbol.
Keywords for packages are there, anyway. If I want to switch to
"COMMON-LISP-USER" package, I just write (in-package :user) -- that's
a whole lot easier for me. Since there are not very many packages,
creating keywords for them is not a big deal for me. Simple
interaction with ACL gives me this:
cl-user(1): (find-symbol "common-lisp" (find-package "keyword"))
:common-lisp
:external
cl-user(2): (find-symbol "user" (find-package "keyword"))
:user
:external
cl-user(3): (find-symbol "cl" (find-package "keyword"))
:cl
:external
cl-user(4):
So some keywords are already there.
> An uninterned symbol leads to (eq '#:foo '#:foo) -> NIL .
> Which means you create two symbols - losing the
> advantage of interned symbols.
I use uninterned symbols just for this characteristic -- I use them as
/string designators/. And avoid case problems.
And I assume that when the code is compiled these uninterned symbols
are thrown away (gcollected) although I'm not completely sure and
would like some feedback on this.
> So, if you look for space efficiency depending on the
> context you want:
I don't look for space efficiency -- if my assumptions hold I already
have it.
>
> - interned symbols, because they can be reused and
> referencing them uses a pointer
>
> - strings, because they don't have the symbol overhead
> (just the name, no value, no package, no property list,
> no function cell, no reference in the package).
>
> Actually as a style issue, *I* don't like to populate
> packages with random symbols.
Nobody's talking about random symbols.
> In a large software system
> one ends up with random symbols in packages (especially
> the keyword package tends to get "misused" for all kinds
> of symbols).
I agree that this might become a problem.
> A symbol in a package should be there for a
> reason. Using symbols as indirect
> references sometimes leads to package bloat.
Again, this is not the case if my assumptions about uninterned symbols
hold. If they do not hold, well -- they do not hold.
Janis Dzerins
--
If million people say a stupid thing it's still a stupid thing.
Janis Dzerins <·····@latnet.lv> writes:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
...
> So some keywords are already there.
>
> > An uninterned symbol leads to (eq '#:foo '#:foo) -> NIL .
> > Which means you create two symbols - losing the
> > advantage of interned symbols.
>
> I use uninterned symbols just for this characteristic -- I use them as
> /string designators/. And avoid case problems.
What case problems?
Trolling away... :)
--
Marco Antoniotti =============================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Janis Dzerins <·····@latnet.lv> writes:
>
> > Rainer Joswig <······@corporate-world.lisp.de> writes:
> ...
> > So some keywords are already there.
> >
> > > An uninterned symbol leads to (eq '#:foo '#:foo) -> NIL .
> > > Which means you create two symbols - losing the
> > > advantage of interned symbols.
> >
> > I use uninterned symbols just for this characteristic -- I use them as
> > /string designators/. And avoid case problems.
>
> What case problems?
If you recall Ranier's example, he had to type "FOO" whereas Janis' example
allowed him not to worry about case. Remember that Common Lisp is case
sensitive; it is the CL reader which is case insensitive by default. So
you may as well use the reader as a tool to get the proper case of the
symbol you want to intern.
> Trolling away... :)
Troll away...
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Trolling away... :)
>
> Troll away...
I should have added a :-) here.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Marco Antoniotti <·······@cs.nyu.edu> writes:
> >
> > > Trolling away... :)
> >
> > Troll away...
>
> I should have added a :-) here.
>
we know :)
Cheers
--
Marco Antoniotti =============================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
In article <·············@beta.franz.com>, Duane Rettig
<·····@franz.com> wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Janis Dzerins <·····@latnet.lv> writes:
> >
> > > Rainer Joswig <······@corporate-world.lisp.de> writes:
> > ...
> > > So some keywords are already there.
> > >
> > > > An uninterned symbol leads to (eq '#:foo '#:foo) -> NIL .
> > > > Which means you create two symbols - losing the
> > > > advantage of interned symbols.
> > >
> > > I use uninterned symbols just for this characteristic -- I use them as
> > > /string designators/. And avoid case problems.
> >
> > What case problems?
>
> If you recall Ranier's example, he had to type "FOO" whereas Janis' example
> allowed him not to worry about case.
Sure one has to worry about case:
(let ((input-string "#:foo")
(case (readtable-case *readtable*)))
(flet ((show-symbol-name (symbol case)
(format t "~%case= ~a name= ~s find-package=~a"
case
(symbol-name symbol)
(find-package symbol))))
(loop for case in '(:upcase :downcase :preserve :invert)
do (setf (readtable-case *readtable*) case)
do (show-symbol-name (read-from-string "#:foo") case)))
(setf (readtable-case *readtable*) case))
Prints (with added spaces):
case= UPCASE name= "FOO" find-package=#<Package "FOO">
case= DOWNCASE name= "foo" find-package=NIL
case= PRESERVE name= "foo" find-package=NIL
case= invert name= "FOO" find-package=#<Package "FOO">
Depending on readtable-case while reading the code,
you will get the right package name or nor.
> Remember that Common Lisp is case
> sensitive;
The reader is not case sensitive.
> it is the CL reader which is case insensitive by default.
You can change the reader case via (SETF READTABLE-CASE).
> So
> you may as well use the reader as a tool to get the proper case of the
> symbol you want to intern.
I just prefer to write the case I want and not rely on some
situation depended (or even implementation dependent) mechanism.
In ANSI Common Lisp all predefined
package names are UPCASEd. If I want a really portable mechanism
where this is not the case (AFAIK only certain ACL Lisp
images do this differently), I still have to take the
state of the reader into account, which may be one of
upcase, downcase, preserve or invert (or maybe another
implementation dependent extension like :randomize ;-) ).
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
In article <··············@asaka.latnet.lv>, Janis Dzerins
<·····@latnet.lv> wrote:
> Keywords for packages are there, anyway.
No, they are not.
A page name is a string. A keyword is a symbol.
> If I want to switch to
> "COMMON-LISP-USER" package,
The package named COMMON-LISP-USER.
> I just write (in-package :user)
Btw., it is "CL-USER". The "USER" package usually is some different
package. Some Lisp systems may make it the same - but this is
not portable. So it would be (IN-PACKAGE :CL-USER) .
In some Lisps (IN-PACKAGE :USER) would not mean
the package named COMMON-LISP-USER. The USER name is a leftover
from early Common Lisp.
? (find-package "USER")
NIL
? (find-package "CL-USER")
#<Package "COMMON-LISP-USER">
> -- that's
> a whole lot easier for me. Since there are not very many packages,
> creating keywords for them is not a big deal for me. Simple
> interaction with ACL gives me this:
>
> cl-user(1): (find-symbol "common-lisp" (find-package "keyword"))
> :common-lisp
> :external
> cl-user(2): (find-symbol "user" (find-package "keyword"))
> :user
> :external
> cl-user(3): (find-symbol "cl" (find-package "keyword"))
> :cl
> :external
> cl-user(4):
This is just a coincidence.
Again this is not portable. In ANSI Common Lisp the name
of the KEYWORD package is "KEYWORD"
and not "keyword".
? (find-package "keyword")
NIL
? (find-package "KEYWORD")
#<Package "KEYWORD">
?
> So some keywords are already there.
No, they are not. Keywords are not involved. Keywords are
symbols. Package names are strings.
In MCL for example:
? (find-symbol "CL" (find-package "KEYWORD"))
NIL
? (find-symbol "USER" (find-package "KEYWORD"))
:USER
:EXTERNAL
So CL is not there, USER is.
> > An uninterned symbol leads to (eq '#:foo '#:foo) -> NIL .
> > Which means you create two symbols - losing the
> > advantage of interned symbols.
>
> I use uninterned symbols just for this characteristic -- I use them as
> /string designators/. And avoid case problems.
There are no case problems in ANSI Common Lisp. The
name for the package CL-USER is "COMMON-LISP-USER".
Also writing #:foo does not get rid of case problems at all.
The case that the Lisp system sees after reading
#:foo depends on the reader.
> And I assume that when the code is compiled these uninterned symbols
> are thrown away (gcollected) although I'm not completely sure and
> would like some feedback on this.
But your code is referencing them, how can they be GCed then?
> > A symbol in a package should be there for a
> > reason. Using symbols as indirect
> > references sometimes leads to package bloat.
>
> Again, this is not the case if my assumptions about uninterned symbols
> hold. If they do not hold, well -- they do not hold.
Your only reason to use #:foo is because you expect
to get rid of the casing problem. But:
- the names of the packages are usually fixed. In ANSI Common Lisp
the name of the package CL-USER is the upcase string
"COMMON-LISP-USER".
- the symbols are created in the packages at some time.
- *later* you want to refer to such a symbol
But in between the reader case can have been changed. So it is
not valid to assume that #:foo will go through the same
case mechanism anymore. If you would enforce a certain case you
can write: #:|foo| or #:|FOO| . If you want to ensure
that you access the right package and the right symbol,
writing #:foo is in general the wrong mechanism.
I'm sometimes using software which has a reader that preserves
case. So inside Lisp, the symbol is named "FOO", and I'm writing
"foo" - but get a different symbol. In your "case" if you
ever load a software which changes the reader to UPCASE
#:foo will have a symbol-name "FOO" and not "foo".
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> * Rainer Joswig wrote:
> [Uninterned symbols in export lists to DEFPACKAGE forms]
>
> > But your code is referencing them, how can they be GCed then?
>
> No, it is not, or not necessarily. If it occurs at top level in a file
> being loaded, then after the DEFPACKAGE form is evaluated there exists
> no possible reference to the uninterned symbols, since the created
> package contains interned symbols with the same name, so they could
> quite possibly be GCd.
Hmm, for uninterned symbols I'd agree.
Two possible "leaks" might be source code recording and
that the package implementation might store the original
uninterned symbols. But both is relatively unlikely.
> Of course the same could be said for the use of an interned symbol in
> the same place: does that symbol need to exist after a compiled file
> containing a DEFPACKAGE form is loaded? I'm not sure. I'm even less
> sure for something like:
>
> (defun foo (x)
> x)
>
> if this is placed in a file, compiled and loaded, then is X interned
> somewhere?
If it is compiled and loaded by the same Lisp system, I would
say X is interned somewhere (due to the compiler READing the file).
If it is compiled by one lisp system and loaded later into
another, I'd say it doesn't need to. In MCL I can
control this via *FASL-SAVE-DEFINITIONS* and
*FASL-SAVE-LOCAL-SYMBOLS* or via parameters to COMPILE-FILE:
Following interesting case:
(defun foo (bar:x)
bar:x)
Now you compile it in one Lisp which
knows an external symbol X in package BAR.
Later you load it into a Lisp which does not have
a package BAR. What happens? You can construct
slighty modified cases: (defun foo (x) x), where
X is used from some package BAR which is only
available at compile time. Or (defun foo (bar::x) bar::x),
where you reference unexported symbols.
Anyway, here is the MCL documentation for COMPILE-FILE:
COMPILE-FILE filename &key :output-file :verbose :print
:load :features :save-local-symbols :save-doc-strings
:save-definitions
[Function]
produces a compiled version of the file filename. Compiled files (also
called fasl files) can be loaded much more quickly than source code files.
The default values of :verbose and :print are the values of
*compile-verbose* and *compile-print*. The default value of
:save-local-symbols is the value of *fasl-save-local-symbols*;
of :save-doc-strings, the value of *fasl-save-doc-strings*;; and
of save-definitions, the value of *fasl-save-definitions*. The
default value of :output-file is the input file with the file type
*.fasl-pathname*.
*fasl-save-definitions*
Provides a default value for the :save-definitions keyword
argument to compile-file; determines whether lambda
expressions are saved in the compiled file.
Default is nil; lambda expressions are not saved in the
compiled file and are not available when the file is loaded.
If true, lambda expressions are saved. Compiled functions
without lambda expressions cannot be stepped.
*fasl-save-local-symbols*
Provides a default value for the :save-local-symbols
keyword argument to compile-file.
Default is nil; local symbols are not saved in the compiled
file. If true, local symbols are saved in the compiled file and
are available when the file is loaded. Generally increases
.fasl file size by about 15�20 percent.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
* Rainer Joswig wrote:
> If it is compiled and loaded by the same Lisp system, I would
> say X is interned somewhere (due to the compiler READing the file).
> If it is compiled by one lisp system and loaded later into
> another, I'd say it doesn't need to.
That's what I'd expect as well, i think.
--tim
"Vladimir V. Zolotych" <······@eurocom.od.ua> writes:
> I've tried to use DEFPACKAGE (file simple-package2.lisp)
>
> (defpackage my-package
> (:nicknames myp :myp)
This ^^^ isn't necessary.
> (:use common-lisp)
> (:export foo))
You might want to avoid interning new symbols in your defpackage form
for the reasons below. So better do:
(defpackage #:my-package
(:nicknames #:myp)
(:use #:common-lisp)
(:export #:foo))
( Others prefer using keywords, but that approach might create and
intern many keyword symbols, which the approach above avoids, by
using uninterned symbols. )
> (in-package :myp) ; is it necessary ?
Yes, defpackage just defines a package, it doesn't change the current
package.
> What happens ? Please explain me what I've done wrong.
Your original defpackage form will have been read when :cl-user was
the current package. Hence the foo in your export list will have been
interned in cl-user. Once you then use the myp package, its myp:foo
symbol will be in conflict with the cl-user:foo symbol, hence the
error.
If you use the defpackage form above, no accidental symbols will be
interned in random packages, and hence no problems should ensue.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Tim Bradshaw <···@cley.com> writes:
> * Marco Antoniotti wrote:
>
bullshit deleted....
>
> I think this is incredibly difficult. It's definitely not acceptable
> to unintern symbols which have `no definitions' in the sense you give,
> or any other finite sense. For instance such a symbol could be a key
> in an alist which was then prompted for using READ.
>
> What you'd have to do is to capture the whole package state before
> the fomr was read, compare it with that after it was read, and
> unintern suitable symbols. And you have to do this capture *before
> you have read the form*, in other words, *before you know if it is a
> DEFPACKAGE form at all*, in other words: always.
Hit and Sunk! :{
> I think it's just much easier to have a smart macro which converts
> symbols to strings in the expansion (or uninterned symbols even), and
> then rely on compiling this and loading it into a fresh Lisp.
>
> I guess there's an issue as to whether the *compiler* should be
> licensed to do some of this magic uninternery when compiling files.
> That would be more reasonable I think.
It surely could. But in this case you are relying on the fact that
DEFPACKAGE forms *are* in standalone files. Can you rely on this all
the time?
All in all, although my extremely complex proposal about "symbol
lookup" was not finessed, I kind of believe that it was somewhere
right along the path of making life simpler. Isn't this what Common
Lisp is all about? :)
Cheers
--
Marco Antoniotti =============================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> It surely could. But in this case you are relying on the fact that
> DEFPACKAGE forms *are* in standalone files. Can you rely on this all
> the time?
>
> All in all, although my extremely complex proposal about "symbol
> lookup" was not finessed, I kind of believe that it was somewhere
> right along the path of making life simpler. Isn't this what Common
> Lisp is all about? :)
>
Yes I think so, but on the other hand there's an issue of how far you
want to go and how much gain you get. It certainly is the case that
interned-symbol-leakage can be a problem for long-running systems
(I've seen this).
One way of avoiding this would be to specify various behaviours of
things like COMPILE-FILE and so on (so COMPILE-FILE would do hairy
things with uninterning symbols and so on). But this is *really*
hairy to get right I think, and `right' is probably controversial in
any case (the moment you talk too much about the package system,
people will leap out from holes in the skirting-boards and tell you
how what you really want is a module system, and you'll then spend ten
years fighting over it until you die of infected skirting-board
splinter wounds). And, what is worse, it probably doesn't solve the
real problem -- systems that leak symbols don't do it because they
repeatedly call DEFPACKAGE, they do it because they repeatedly call
INTERN in user code, or something like that.
Well, another way of dealing with the problem is to assume that good
implementations will GC uninterned symbols and will GC symbols from
deleted packages, and then to go to some additional user effort to
either use uninterned symbols or use temporary packages. In many
cases you want to do this kind of thing anyway, so it's not *that*
much extra work.
I think what I'm trying to say is that there are tradeoffs here, and I
think that ruthlessly trying to do the right thing can lead to
incredible implementation complexity for possibly very little gain.
So I think I agree in theory with what you are saying (ish) but in
practice I disagree.
--tim
Tim Bradshaw <···@tfeb.org> writes:
....
> Well, another way of dealing with the problem is to assume that good
> implementations will GC uninterned symbols and will GC symbols from
> deleted packages, and then to go to some additional user effort to
> either use uninterned symbols or use temporary packages. In many
> cases you want to do this kind of thing anyway, so it's not *that*
> much extra work.
>
> I think what I'm trying to say is that there are tradeoffs here, and I
> think that ruthlessly trying to do the right thing can lead to
> incredible implementation complexity for possibly very little gain.
>
> So I think I agree in theory with what you are saying (ish) but in
> practice I disagree.
Well, I agree with you in practice. Not that I do not disagree with
myself every once in a while :)
Cheers
--
Marco Antoniotti =============================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp