From: Richard M Kreuter
Subject: Package-qualified symbols & unUSEable packages -- threat or menace?
Date:
Message-ID: <87k60quqm4.fsf@progn.net>
Hello,
Some of the recent Lisp code and documentation available on the net
encourage or require the employment package-delimited symbol names in
source code, and some library packages are being written that can't be
USEd (in the sense of use-package, or a bunch of imports) in packages
that also use the CL package. Examples:
* (From the asdf manual; note that the asdf package is USEable
alongside CL)
| The system foo is loaded (and compiled, if necessary) by evaluating
| the following form in your Lisp implementation:
|
| (asdf:operate 'asdf:load-op 'foo)
* (From the asdf-install tutorial)
| ... you can download and install the library directly by providing
| the download URL of the package like so:
|
| (asdf-install:install "http://weitz.de/files/cl-ppcre.tar.gz")
* (From SBCL's SB-POSIX README; SB-POSIX is /not/ USEable alongside
CL)
| The user is encouraged not to (USE-PACKAGE :SB-POSIX) but instead to
| use the SB-POSIX: prefix on all references, as some of our symbols
| have the same name as CL symbols (OPEN, CLOSE, SIGNAL etc).
What are people's opinions about this way of employing the package
system, as opposed to making USEable packages and USEing them?
For my part, I think this is an unfortunate practice for library code,
for the following reason: when a package is intentionally unUSEable or
customarily unUSEd, the package name becomes de facto interface in the
/source text/, where Lisp can't do much with it.
To switch existing programs from using one implementation of an API
that encourages or requires package-qualified symbol names in source
code to another implementation of the same API (modulo package names,
of course), it's necessary either to audit code, or else to play
tricky games with the package namespace around compilation and
loading. By contrast, when a package is USEable and customarily USEd,
switching between compatible implementations of an interface normally
involves editing some defpackage forms (in case package A exports
symbols not exported from package B, switching from USEing B to A may
require some shadowing or shadowing-import-froms, I suppose).
Concrete examples where there could be practical advantages to
multiply-implementable interfaces aren't hard to imagine: an
implementation might provide POSIX, sockets, or database APIs that are
compatible with some implementation-independent libraries, but
optimized in ways that implementation-independent libraries can't or
wouldn't be (e.g., taking advantage of some imeplementation specific
memory management features, or operating system specific features of
the range of operating systems where the implementation runs).
Programs that employ USEable packages can then take advantage of
implementation-optimized libraries relatively easily, in principle.
Anyhow, I'm curious what people's thoughts are about this.
--
RmK
P.S. It might save time for me to concede up front that unUSEable
packages can have symbols with shorter symbol-names. However, this
only helps people who are writing code in such packages, and there are
a variety of means available for people who are really desparate for
short names in their own code: shadowing CL symbols and defining
symbol macros, using reader macros, etc.
On 17 Dez., 23:03, Richard M Kreuter <·······@progn.net> wrote:
> Hello,
>
> Some of the recent Lisp code and documentation available on the net
> encourage or require the employment package-delimited symbol names in
> source code, and some library packages are being written that can't be
> USEd (in the sense of use-package, or a bunch of imports) in packages
> that also use the CL package. Examples:
>
> * (From the asdf manual; note that the asdf package is USEable
> alongside CL)
>
> | The system foo is loaded (and compiled, if necessary) by evaluating
> | the following form in your Lisp implementation:
> |
> | (asdf:operate 'asdf:load-op 'foo)
>
> * (From the asdf-install tutorial)
>
> | ... you can download and install the library directly by providing
> | the download URL of the package like so:
> |
> | (asdf-install:install "http://weitz.de/files/cl-ppcre.tar.gz")
>
> * (From SBCL's SB-POSIX README; SB-POSIX is /not/ USEable alongside
> CL)
>
> | The user is encouraged not to (USE-PACKAGE :SB-POSIX) but instead to
> | use the SB-POSIX: prefix on all references, as some of our symbols
> | have the same name as CL symbols (OPEN, CLOSE, SIGNAL etc).
>
> What are people's opinions about this way of employing the package
> system, as opposed to making USEable packages and USEing them?
Often I like to have the package name in the source code, since it will
remind me when I'm reading the source where the symbol comes from.
Also using a package can have all kinds of unwanted side effects and
you
can have lots of conflicts in some situations.
As an example:
Consider this code:
Package p1:
(defclass foo ()
((bar)))
(defun bar ())
Now you export BAR from package P1 (probably to have the function BAR
accessible there).
If you use package P1 in package P2, the symbol BAR from
package P1 will be visible.
That means all uses of BAR will refer to that symbol.
And you have exported the symbol BAR, which is used as a slot name
AND as a function.
In package P2:
(defclass baz ()
((bar)))
Again this BAR is the one from the other package, even though you might
only
wanted to export a function. But you can't export functions. You can
only
export symbols and symbols can be used to name many things (class
names, slot names,
functions, variables, ...).
>
> For my part, I think this is an unfortunate practice for library code,
> for the following reason: when a package is intentionally unUSEable or
> customarily unUSEd, the package name becomes de facto interface in the
> /source text/, where Lisp can't do much with it.
>
> To switch existing programs from using one implementation of an API
> that encourages or requires package-qualified symbol names in source
> code to another implementation of the same API (modulo package names,
> of course), it's necessary either to audit code, or else to play
> tricky games with the package namespace around compilation and
> loading. By contrast, when a package is USEable and customarily USEd,
> switching between compatible implementations of an interface normally
> involves editing some defpackage forms (in case package A exports
> symbols not exported from package B, switching from USEing B to A may
> require some shadowing or shadowing-import-froms, I suppose).
>
> Concrete examples where there could be practical advantages to
> multiply-implementable interfaces aren't hard to imagine: an
> implementation might provide POSIX, sockets, or database APIs that are
> compatible with some implementation-independent libraries, but
> optimized in ways that implementation-independent libraries can't or
> wouldn't be (e.g., taking advantage of some imeplementation specific
> memory management features, or operating system specific features of
> the range of operating systems where the implementation runs).
> Programs that employ USEable packages can then take advantage of
> implementation-optimized libraries relatively easily, in principle.
>
> Anyhow, I'm curious what people's thoughts are about this.
>
> --
> RmK
>
> P.S. It might save time for me to concede up front that unUSEable
> packages can have symbols with shorter symbol-names. However, this
> only helps people who are writing code in such packages, and there are
> a variety of means available for people who are really desparate for
> short names in their own code: shadowing CL symbols and defining
> symbol macros, using reader macros, etc.
Richard M Kreuter schrieb:
> For my part, I think this is an unfortunate practice for library code,
> for the following reason: when a package is intentionally unUSEable or
> customarily unUSEd, the package name becomes de facto interface in the
> /source text/, where Lisp can't do much with it.
Thats not quite true. Besides of (unfortunately non-portable)
extensions like local package aliases, you actually have means in Lisp
to handle this. You can programmatically walk over a package's symbols
and create new packages following arbitrary rules. If I understand your
problem right, then you want to be able to do e.g.
(defpackage my-package
(:use :cl
#+cmu "CMU-POSIX"
#+sbcl "SB-POSIX"
...))
(in-package :my-package)
(defun foo ()
(posix-open ...))
instead of
(defpackage my-package
(:use :cl))
(in-package :my-package)
(defun foo ()
(sb-posix:open ...))
There would be several solutions to this problem. One is certainly as
you outlined to use nicknames and/or rename-package to handle this
things. Another possibility is the following:
(defpackage posix
(:use #+cmu "CMU-POSIX"
#+sbcl "SB-POSIX"))
(defpackage my-package
(:use :cl))
(defun foo ()
(posix:open ...))
Oh wait - You may argue right - this doesn't work since USEing the
external symbols of a package does not reexport them again. So you have
to reexport them manually afterwards. If you wrap this up in a new
DEFPACKAGE* macro you can just write for example
(defpackage* posix
(:use :cl)
(:use-and-export #+cmu "CMU-POSIX"
#-sbcl "SB-POSIX"))
(Writing a portable DEFPACKAGE* is left as an excercise to the reader)
If you use Tim Bradshaw's CONDUITS package
(http://www.tfeb.org/lisp/hax.html) you get all this and more.
ciao,
Jochen
In article <··············@progn.net>,
Richard M Kreuter <·······@progn.net> wrote:
> | The user is encouraged not to (USE-PACKAGE :SB-POSIX) but instead to
> | use the SB-POSIX: prefix on all references, as some of our symbols
> | have the same name as CL symbols (OPEN, CLOSE, SIGNAL etc).
>
> What are people's opinions about this way of employing the package
> system, as opposed to making USEable packages and USEing them?
This package is presumably designed to use the names in the POSIX
specification. Unfortunately, many POSIX functions have the same names
as CL functions, so there's an inherent conflict there.
To allow the package to be USEd, they would have to gives these
functions different names, e.g. POSIX-OPEN, POSIX-CLOSE, etc. So
instead of typing POSIX:OPEN, you'd have to type POSIX-OPEN. Is that
really any better?
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
On Dec 17, 8:23 pm, Barry Margolin <······@alum.mit.edu> wrote:
> To allow the package to be USEd, they would have to gives these
> functions different names, e.g. POSIX-OPEN, POSIX-CLOSE, etc. So
> instead of typing POSIX:OPEN, you'd have to type POSIX-OPEN. Is that
> really any better?
I prefer POSIX-OPEN to POSIX:OPEN simply because it does not shadow
COMMON-LISP symbols. The cost of typing POSIX-OPEN comes with the
benefit that Richard desired in his original post, the ability to
switch packages that conform to the API. With POSIX as the package
name, a USEr has the ability to import and shadow OPEN, CLOSE, etc.,
despite recommendations in the documentation. Having POSIX embedded in
the function name prevents such mischief. Furthermore, it does not
require the use of another package to perform advanced package
construction.
To clarify, I am not advocating an emacs lisp style naming convention.
I am arguing that:
* Shadowing COMMON-LISP should be avoided.
* Symbol names in packages should be sufficiently descriptive without
the package name.
* Symbol names should adher to an API when available.
* The overhead of this philosophy is worth the benefit, mainly
simplicity.
To further clarify, since this is a discussion of coding style, I do
not think that this is the "best" way to manage namespace. It is my
preferred method based on my personal calculation of costs and benefits
that is biased towards simplicity.
Cheers,
Tom
Thomas M. Hermann schrieb:
> I prefer POSIX-OPEN to POSIX:OPEN simply because it does not shadow
> COMMON-LISP symbols. The cost of typing POSIX-OPEN comes with the
> benefit that Richard desired in his original post, the ability to
> switch packages that conform to the API. With POSIX as the package
> name, a USEr has the ability to import and shadow OPEN, CLOSE, etc.,
> despite recommendations in the documentation. Having POSIX embedded in
> the function name prevents such mischief. Furthermore, it does not
> require the use of another package to perform advanced package
> construction.
As I've shown, you can switch packages that conform to the API also
when using the
POSIX:OPEN approach. You can do this either by creating appropriate
nicknames or by
"use-and-export" in an empty package. The last thing and more is
offered by Tim Bradshaw's conduits. I don't know if "use-and-export"
can really be counted as "advanced package construction" but IMHO this
thing is one of the places were CL's flexibility is demonstrated. My
personal utility-macro for that purpose (created before I found
conduits) had just 17 lines of portable CL code - it might even get
shorter if one wants to stress that point (I did not care).
> To clarify, I am not advocating an emacs lisp style naming convention.
> I am arguing that:
>
> * Shadowing COMMON-LISP should be avoided.
> * Symbol names in packages should be sufficiently descriptive without
> the package name.
> * Symbol names should adher to an API when available.
> * The overhead of this philosophy is worth the benefit, mainly
> simplicity.
I think that it is a perfectly viable thing to use symbol-names of
symbols in the COMMON-LISP package in your own packages were
appropriate. There are many cases were it is actually much simpler to
do so than to invent "workaround-names". About the second point: I
think this does not have to be necessary. Often it is better to use
(short) package names to include enough context, that the distinction
is clear (examples: mp:process-run-function, capi:collection etc.). In
those cases were even a short package specifier looks bad It is often
possible to construct a package for the application, were the context
is again quite clear throught the actual problem (e. g. shadowing
arithmetic operators for some symbolic math package). I think it is
more often a bad idea to always USE all needed packages than it is to
shadow specific COMMON-LISP symbols.
> To further clarify, since this is a discussion of coding style, I do
> not think that this is the "best" way to manage namespace. It is my
> preferred method based on my personal calculation of costs and benefits
> that is biased towards simplicity.
Well - everyone is free to do so as they like - but I think it is quite
a different thing to mandate library authors to just use symbol-names
disjunct from the ones used in COMMON-LISP. It looks just like an
unnecessary restriction in general and in some cases even like the
worse decision.
ciao,
Jochen
From: Richard M Kreuter
Subject: Re: Package-qualified symbols & unUSEable packages -- threat or menace?
Date:
Message-ID: <87y7p4u8c4.fsf@progn.net>
··@codeartist.org writes:
> As I've shown, you can switch packages that conform to the API also
> when using the POSIX:OPEN approach. You can do this either by
> creating appropriate nicknames or by "use-and-export" in an empty
> package.
Your suggestions only explicitly addressed the wrapping of functions.
It's obvious how macros would be similarly wrapped. What about the
names of variables, structures, CLOS classes, slots, condition
classes, catch tags, block names? Symbol macros might work for some
of these, but they lead to pathological corner cases:
> (defvar *v1* 4)
*V1*
> (define-symbol-macro *v2* *v1*)
*V1*
> *v2*
4
> (symbol-value '*v2*)
4
> (setf *v2* 5)
5
> *v2*
5 ;So far, so good, but...
> (symbol-value '*v2*)
!! Unbound variable *v2*
In any case, it's not clear to me that a library that requires this
sort of wrapping has exported a satisfactory API.
> I think that it is a perfectly viable thing to use symbol-names of
> symbols in the COMMON-LISP package in your own packages were
> appropriate.
What goes on inside a package is up to the authors, of course. The
question I was asking is whether an ordinary library's public
interface ought to export symbols that conflict with symbols in
COMMON-LISP. In some cases, there are practical reasons why a package
ought to do so; but in other cases, I think there are reasons why a
package shouldn't do so.
Some libraries, such as SERIES and CLSQL, export conflicting symbols
precisely because they implement operators that are upwardly
compatible with standard CL ones. It's a good thing, all in all, that
Lisp libraries can do this.
Other systems, such as Pseudoscheme or ThinLisp or Maxima, have
packages with conflicting names because they implement other languages
using a CL substrate.
But ISTM that a library providing a POSIX open(2) or sockets listen(2)
is of a qualitatively different order: these libraries are meant for
employment in ordinary Common Lisp programs, alongside ordinary Common
Lisp operators. When such libraries export names that conflict with
CL, they create unnecessary portability and maintainability burdens
for library clients.
> Well - everyone is free to do so as they like - but I think it is quite
> a different thing to mandate library authors to just use symbol-names
> disjunct from the ones used in COMMON-LISP. It looks just like an
> unnecessary restriction in general and in some cases even like the
> worse decision.
Nobody's in a position to mandate anything in the Lisp community.
However, inasmuch as there are two general opinions here:
* libraries ought to export USEable names, where appropriate,
* libraries neeend't export USEable names
then the former position promotes interfaces that will probably
satisfy most people of either opinion. Assuming that USEable packages
have longer symbol names, the only people who lose when packages are
USEable are those who always package-qualify even those symbols that
can be imported into their packages -- are there such people?. So the
USEable names practice probably satisfies more prospective library
users.
--
RmK
From: Richard M Kreuter
Subject: Re: Package-qualified symbols & unUSEable packages -- threat or menace?
Date:
Message-ID: <87tzzsu6es.fsf@progn.net>
Richard M Kreuter <·······@progn.net> writes:
> ··@codeartist.org writes:
>
>> As I've shown, you can switch packages that conform to the API also
>> when using the POSIX:OPEN approach. You can do this either by
>> creating appropriate nicknames or by "use-and-export" in an empty
>> package.
>
> Your suggestions only explicitly addressed the wrapping of functions.
> It's obvious how macros would be similarly wrapped. What about the
> names of variables, structures, CLOS classes, slots, condition
> classes, catch tags, block names? Symbol macros might work for some
> of these, but they lead to pathological corner cases:
>
>> (defvar *v1* 4)
> *V1*
>> (define-symbol-macro *v2* *v1*)
> *V1*
>> *v2*
> 4
>> (symbol-value '*v2*)
^^^^ *v1* Sorry.
> 4
>> (setf *v2* 5)
> 5
>> *v2*
> 5 ;So far, so good, but...
>> (symbol-value '*v2*)
> !! Unbound variable *v2*
>
> In any case, it's not clear to me that a library that requires this
> sort of wrapping has exported a satisfactory API.
>
>> I think that it is a perfectly viable thing to use symbol-names of
>> symbols in the COMMON-LISP package in your own packages were
>> appropriate.
>
> What goes on inside a package is up to the authors, of course. The
> question I was asking is whether an ordinary library's public
> interface ought to export symbols that conflict with symbols in
> COMMON-LISP. In some cases, there are practical reasons why a package
> ought to do so; but in other cases, I think there are reasons why a
> package shouldn't do so.
>
> Some libraries, such as SERIES and CLSQL, export conflicting symbols
> precisely because they implement operators that are upwardly
> compatible with standard CL ones. It's a good thing, all in all, that
> Lisp libraries can do this.
>
> Other systems, such as Pseudoscheme or ThinLisp or Maxima, have
> packages with conflicting names because they implement other languages
> using a CL substrate.
>
> But ISTM that a library providing a POSIX open(2) or sockets listen(2)
> is of a qualitatively different order: these libraries are meant for
> employment in ordinary Common Lisp programs, alongside ordinary Common
> Lisp operators. When such libraries export names that conflict with
> CL, they create unnecessary portability and maintainability burdens
> for library clients.
>
>> Well - everyone is free to do so as they like - but I think it is quite
>> a different thing to mandate library authors to just use symbol-names
>> disjunct from the ones used in COMMON-LISP. It looks just like an
>> unnecessary restriction in general and in some cases even like the
>> worse decision.
>
> Nobody's in a position to mandate anything in the Lisp community.
> However, inasmuch as there are two general opinions here:
>
> * libraries ought to export USEable names, where appropriate,
>
> * libraries neeend't export USEable names
>
> then the former position promotes interfaces that will probably
> satisfy most people of either opinion. Assuming that USEable packages
> have longer symbol names, the only people who lose when packages are
> USEable are those who always package-qualify even those symbols that
> can be imported into their packages -- are there such people?. So the
> USEable names practice probably satisfies more prospective library
> users.
>
> --
> RmK
Richard M Kreuter schrieb:
> ··@codeartist.org writes:
>
> > As I've shown, you can switch packages that conform to the API also
> > when using the POSIX:OPEN approach. You can do this either by
> > creating appropriate nicknames or by "use-and-export" in an empty
> > package.
>
> Your suggestions only explicitly addressed the wrapping of functions.
> It's obvious how macros would be similarly wrapped. What about the
> names of variables, structures, CLOS classes, slots, condition
> classes, catch tags, block names? Symbol macros might work for some
> of these, but they lead to pathological corner cases:
[snipped example...]
> In any case, it's not clear to me that a library that requires this
> sort of wrapping has exported a satisfactory API.
Hm - I did not suggest to wrap anything up - I suggested to use either
nicknames or to create new custom packages. I don't understand how you
came to this understanding of my posting.
> > I think that it is a perfectly viable thing to use symbol-names of
> > symbols in the COMMON-LISP package in your own packages were
> > appropriate.
>
> What goes on inside a package is up to the authors, of course. The
> question I was asking is whether an ordinary library's public
> interface ought to export symbols that conflict with symbols in
> COMMON-LISP. In some cases, there are practical reasons why a package
> ought to do so; but in other cases, I think there are reasons why a
> package shouldn't do so.
Hm... what is an ordinary library? I think even that depends on what
you actually want to use lisp for.
> Some libraries, such as SERIES and CLSQL, export conflicting symbols
> precisely because they implement operators that are upwardly
> compatible with standard CL ones. It's a good thing, all in all, that
> Lisp libraries can do this.
>
> Other systems, such as Pseudoscheme or ThinLisp or Maxima, have
> packages with conflicting names because they implement other languages
> using a CL substrate.
>
> But ISTM that a library providing a POSIX open(2) or sockets listen(2)
> is of a qualitatively different order: these libraries are meant for
> employment in ordinary Common Lisp programs, alongside ordinary Common
> Lisp operators. When such libraries export names that conflict with
> CL, they create unnecessary portability and maintainability burdens
> for library clients.
I don't think so. Nobody says that one has to always be able to
USE-PACKAGE the package of a library. If you really just use POSIX:OPEN
or POSIX:CLOSE in one or two places of your code there is no reason to
import it into your own package. If you use it more often it might be
one idea to choose a even shorter nickname (like P:OPEN). If you use
only POSIX:OPEN or you use CL:OPEN only a few times you can do a
shadowing-import of POSIX:OPEN and then use CL:OPEN were you need it.
What I want to say is, that I think there is a reason why CL makes it
so easy to construct packages perfectly suited for your particular
problem. IMHO always just using USE-PACKAGE is a quite sloppy and
fragile style of package construction. This just asks for problems. I
don't think there exists any argument for CL that says that it should
be always a good idea to just USE-PACKAGE libraries; completely
ignoring problems that may arise when one of the used libraries changes
anything in their exported interface (means extends it with new
symbols). You might use a package that implements Java-style
collections using a class COLLECTION and at the same time a LispWorks
CAPI gui and will find a conflict between CAPI:COLLECTION and
JAVA-STYLE:COLLECTION. Maybe you even implement yourself a class
ENVIRONMENT with some particular semantics and get conflicts if one of
the libraries, you use, exports a new symbol ENVIRONMENT. Calling a
java-like collection class COLLECTION is IMHO not unreasonable. Symbol
names should not get chosen to make it easy for the library clients to
USE-PACKAGE them but to make it easier to understand what is actually
meant.
> Nobody's in a position to mandate anything in the Lisp community.
> However, inasmuch as there are two general opinions here:
>
> * libraries ought to export USEable names, where appropriate,
>
> * libraries neeend't export USEable names
>
> then the former position promotes interfaces that will probably
> satisfy most people of either opinion. Assuming that USEable packages
> have longer symbol names, the only people who lose when packages are
> USEable are those who always package-qualify even those symbols that
> can be imported into their packages -- are there such people?. So the
> USEable names practice probably satisfies more prospective library
> users.
I don't think that promoters of the second position are really
satisfied using symbols named by workaround-names. At least I'm not
satisfied. It is actually cleaner to resolve the name conflict using
the package system than to wrap POSIX:POSIX-OPEN up in a POSIX:OPEN
function.
ciao,
Jochen
From: Richard M Kreuter
Subject: Re: Package-qualified symbols & unUSEable packages -- threat or menace?
Date:
Message-ID: <877iwntor1.fsf@progn.net>
··@codeartist.org writes:
> Richard M Kreuter schrieb:
>> ··@codeartist.org writes:
>>
>>> As I've shown, you can switch packages that conform to the API
>>> also when using the POSIX:OPEN approach. You can do this either by
>>> creating appropriate nicknames or by "use-and-export" in an empty
>>> package.
>>
>> Your suggestions only explicitly addressed the wrapping of functions.
>> It's obvious how macros would be similarly wrapped. What about the
>> names of variables, structures, CLOS classes, slots, condition
>> classes, catch tags, block names? Symbol macros might work for some
>> of these, but they lead to pathological corner cases:
> [snipped example...]
>> In any case, it's not clear to me that a library that requires this
>> sort of wrapping has exported a satisfactory API.
>
> Hm - I did not suggest to wrap anything up - I suggested to use either
> nicknames or to create new custom packages. I don't understand how you
> came to this understanding of my posting.
I thoroughly misread your earlier posting; I apologize.
Your proposal was to construct intermediate packages that import from
the underlying packages and export to clients. The ability to
construct such "conduits" is pretty cool, but they're not any more
future-proof than the status quo. Suppose you start out deciding that
your package will be a conduit, like so:
(defpackage* "POSIX"
(:use #+sbcl "SB-POSIX"
#+cmu "CMU-POSIX")
(:export ...)
...)
Then you go and write your systems with "posix:open" and so forth.
What do you do if you have to port to an implementation calls its
POSIX package "POSIX", or when you have to integrate some third party
library called "POSIX" (perhaps because you need a third party library
that depends on that POSIX)? Even if all these POSIXes are supersets
of a common API, you might not be able to rename things then --
dependent systems might require a "POSIX" package with a particular
operator that your conduit package doesn't have (e.g., it's probable
that portably implemented libraries or lowest-common-denominator
wrappers won't be able to provide a consistent interface to signal
handlers). Of course, everyone could use long package name
conventions, but that would make package-qualified symbols much worse
on Common Lisps without hierarchical packages.
Package-local nickname namespaces, on the other hand, would solve the
future-proofing problem. Unfortunately, it's hard to see how to get
there from here. Although code that relied on such a facility could be
ported to implementations that didn't have it (by renaming packages
for such systems' requirements), that code would probably exacerbate
the collisions on standard implementations. So there'd be a
disadvantage to using such a facility from the outset.
--
RmK
Richard M Kreuter <·······@progn.net> writes:
> Then you go and write your systems with "posix:open" and so forth.
> What do you do if you have to port to an implementation calls its
> POSIX package "POSIX",
Load code that depends on a system package named POSIX, rename the
system package, load my package named POSIX and proceed.
> or when you have to integrate some third party
> library called "POSIX" (perhaps because you need a third party library
> that depends on that POSIX)?
Load code with package named POSIX, load any code that depends on that
package with that name, rename it, load my package named POSIX and
proceed.
> Even if all these POSIXes are supersets of a common API, you might
> not be able to rename things then -- dependent systems might require
> a "POSIX" package with a particular operator that your conduit
> package doesn't have
Some POSIX packages take POSIX-the-standard more seriously than
others. But still, load the POSIX it needs, load the code, rename that
POSIX, load your POSIX, etc...
You control the state of the package system at any particular time you
care to intervene. If some third party library requires a package
named POSIX with a certain interface, you can provide it when
necessary and un-provide it later.
I haven't had to do any of this yet. Maybe in practice it would be too
annoying. Maybe I lack imagination, but I can't really see it being a
big problem.
Joe Marshall wrote some neat stuff about package system wrangling in
<············@ccs.neu.edu> aka
http://groups.google.com/group/comp.lang.lisp/msg/d23a942023da202c
Maybe he can chime in on the reality of dealing with it for something
of significant size.
Zach
Barry Margolin wrote:
>
> To allow the package to be USEd, they would have to gives these
> functions different names, e.g. POSIX-OPEN, POSIX-CLOSE, etc. So
> instead of typing POSIX:OPEN, you'd have to type POSIX-OPEN. Is that
> really any better?
I think it is. If my code says POSIX:OPEN then I'm committed to using
a package called POSIX. But I might actually want to use MY-POSIX:OPEN
or some other thing.
The boring approach is to change the call to POSIX-OPEN so then I just
need to arrange to use the package of interest somewhere and no other
changes are needed in my code.
A more interesting approach (I think) is to (a) make sure authors give
packages sensible names (no names without '.' in at minimum: such names
should be reserved for the language, perhaps the implementation, and
nicknames in user code) and then (b) use some per-package nickname
thing so that, in my code, POSIX:OPEN is actually blah.POSIX:OPEN. (or
even, since maybe posix stuff is common in my code, to have P:OPEN be
blah.POSIX:OPEN).
My conduits stuff allows this (for Lisps which can be made to support
per-package nicknames, which I think is at least Allegro, LW,
SBCL/CMUCL and probably others).
--tim
Richard M Kreuter <·······@progn.net> writes:
> [...]
> For my part, I think this is an unfortunate practice for library code,
> for the following reason: when a package is intentionally unUSEable or
> customarily unUSEd, the package name becomes de facto interface in the
> /source text/, where Lisp can't do much with it.
> [...]
You're right. But we live in the hope for relative package names or
local package nicknames extensions...
Have a look at:
http://www.franz.com/support/tech_corner/hierpackuser.lhtml
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
From: Richard M Kreuter
Subject: Re: Package-qualified symbols & unUSEable packages -- threat or menace?
Date:
Message-ID: <87fybeumu2.fsf@progn.net>
Pascal Bourguignon <···@informatimago.com> writes:
> Richard M Kreuter <·······@progn.net> writes:
>
>> [...]
>> For my part, I think this is an unfortunate practice for library
>> code, for the following reason: when a package is intentionally
>> unUSEable or customarily unUSEd, the package name becomes de facto
>> interface in the /source text/, where Lisp can't do much with it.
>> [...]
>
> You're right. But we live in the hope for relative package names or
> local package nicknames extensions...
>
> Have a look at:
> http://www.franz.com/support/tech_corner/hierpackuser.lhtml
I don't think this solves the problem I address.
If the tokens in source text are package-qualified, then the package
namespace has to be just right at read time. A hierarchical package
system merely adds the wrinkle that "just right" is defiend to also
depend on the read time value of *package*.
As an aside, the Franz document makes mention of the hierarchical
namespaces in Perl and Java, but the comparisons are misleading,
because both of those languages use the code namespaces for naming
classes and also for naming files in the deployment environment.
What's more, in single-implementation languages, there's not much
benefit to multiply-implemented libraries, since there's only one
implementation to run on. In Common Lisp, both because of the history
of diversity of implementations, and also, perhaps, because of the
tendency to want to fold libraries into the language seamlessly,
there's more of a call for multiply-implemented APIs than in other
languages.
--
RmK
Richard M Kreuter <·······@progn.net> writes:
> Pascal Bourguignon <···@informatimago.com> writes:
>> Richard M Kreuter <·······@progn.net> writes:
>>
>>> [...]
>>> For my part, I think this is an unfortunate practice for library
>>> code, for the following reason: when a package is intentionally
>>> unUSEable or customarily unUSEd, the package name becomes de facto
>>> interface in the /source text/, where Lisp can't do much with it.
>>> [...]
>>
>> You're right. But we live in the hope for relative package names or
>> local package nicknames extensions...
>>
>> Have a look at:
>> http://www.franz.com/support/tech_corner/hierpackuser.lhtml
>
> I don't think this solves the problem I address.
>
> If the tokens in source text are package-qualified, then the package
> namespace has to be just right at read time. A hierarchical package
> system merely adds the wrinkle that "just right" is defiend to also
> depend on the read time value of *package*.
Indeed, Franz's hierarchical packages are only part of the solution.
But the same technique (or just rewritting the lisp reader) could be
used to implement package relative nicknames. What is needed, is that
package nicknames be in a name space relative to the current package,
instead of a global name space. Then we could write for example:
(defpackage "P1"
(:use "COM.INFORMATIMAGO.COMMON-LISP.STRING" :as "STR")
(:use #+feature-1 "COM.INFORMATIMAGO.COMMON-LISP.HTML"
#+feature-2 "SOME.OTHER.HTML-PACKAGE"
:as "HTML"))
(in-package "P1")
(html:p () "Some paragraph")
(in-package "P2")
(use-package "YET.ANOTHER.HTML" :as "HTML")
(html:p (html:pcdata "Some other paragraph"))
...
--
__Pascal Bourguignon__ http://www.informatimago.com/
Grace personified,
I leap into the window.
I meant to do that.
Pascal Bourguignon schrieb:
> Richard M Kreuter <·······@progn.net> writes:
[...]
> > I don't think this solves the problem I address.
> >
> > If the tokens in source text are package-qualified, then the package
> > namespace has to be just right at read time. A hierarchical package
> > system merely adds the wrinkle that "just right" is defiend to also
> > depend on the read time value of *package*.
>
> Indeed, Franz's hierarchical packages are only part of the solution.
> But the same technique (or just rewritting the lisp reader) could be
> used to implement package relative nicknames. What is needed, is that
> package nicknames be in a name space relative to the current package,
> instead of a global name space. Then we could write for example:
>
> (defpackage "P1"
> (:use "COM.INFORMATIMAGO.COMMON-LISP.STRING" :as "STR")
> (:use #+feature-1 "COM.INFORMATIMAGO.COMMON-LISP.HTML"
> #+feature-2 "SOME.OTHER.HTML-PACKAGE"
> :as "HTML"))
> (in-package "P1")
> (html:p () "Some paragraph")
>
> (in-package "P2")
> (use-package "YET.ANOTHER.HTML" :as "HTML")
> (html:p (html:pcdata "Some other paragraph"))
Cool, I thought about the same solution. But isn't this syntax
ambigous, since ":as" can be interpreted as package name as well?
I'd prefer the simpler syntax
(defpackage #:p1
...
;; only one pair allowed
(:use-as #:com.informatigamo.common-lisp.string #:str)
...)
and
(use-package-as #:yet.another.html #:html)
Hierarchical and relative package names are bad, IMO. For example,
renaming a package (and moving to another hierarchical level) requires
editing (and first finding!) all places that accessed symbols of the
package via relative names from other packages. Whereas with :use-as
the package name needs to be changed only where the package is
":use-as"d.
Isn't this a good candidate for a CDR?
(message (Hello 'Richard)
(you :wrote :on '(Sun, 17 Dec 2006 17:03:47 -0500))
(
RM> What are people's opinions about this way of employing the package
RM> system, as opposed to making USEable packages and USEing them?
i see nothing wrong with it, it's a widely used practice in C++, for
example.
i think it depends on a kind of package -- if you're relatively
infrequently use symbols from it, it's not feasible to USE it.
RM> For my part, I think this is an unfortunate practice for library code,
RM> for the following reason: when a package is intentionally unUSEable or
RM> customarily unUSEd, the package name becomes de facto interface in the
RM> /source text/, where Lisp can't do much with it.
i don't think it's a real problem
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Richard M Kreuter wrote:
> What are people's opinions about this way of employing the package
> system, as opposed to making USEable packages and USEing them?
It depends on the situation. Suppose you are preparing a suite of
packages, all under your control. Sure, why not USE some of them inside
others?
If you USE some third-party package, then you are at the mercy of
whatever it exports now, and in any future version. Today, you might
not have any clashes. Tomorrow, when new versions of some of the
packages come out, the same USE directive will bring in new material.
This doesn't happen when specific symbols are imported.
> For my part, I think this is an unfortunate practice for library code,
> for the following reason: when a package is intentionally unUSEable or
> customarily unUSEd, the package name becomes de facto interface in the
> /source text/, where Lisp can't do much with it.
What stops you from importing the specific symbols that you want?
If a package has symbols like OPEN and SIGNAL, and you USE both it and
CL, you will have clashes.
One possibility is to USE the CL package, and then SHADOWING-IMPORT
specific symbols from other packages. That way you can use CL:SIGNAL to
refer to the CL one, and SIGNAL to refer to the POSIX binding provided
by the package.
> To switch existing programs from using one implementation of an API
> that encourages or requires package-qualified symbol names in source
> code to another implementation of the same API (modulo package names,
> of course), it's necessary either to audit code, or else to play
> tricky games with the package namespace around compilation and
> loading.
Or you could set up some intermediate package to contain the API.
Import into it exactly the symbols which are needed, and even give it a
version.
(defpackage :api-2-0
(:import-from :library :open :signal ...)
(:export :open :signal ...))
This API-2-0 package selectively imports symbols from LIBRARY, and then
re-exports them. So now, this new package is USE-able. And as a bonus,
because it is versioned, it will never export anything new. A future
version that exports more things can be called API-2-1.
Kaz Kylheku wrote:
> Or you could set up some intermediate package to contain the API.
> Import into it exactly the symbols which are needed, and even give it a
> version.
>
> (defpackage :api-2-0
> (:import-from :library :open :signal ...)
> (:export :open :signal ...))
>
> This API-2-0 package selectively imports symbols from LIBRARY, and then
> re-exports them. So now, this new package is USE-able. And as a bonus,
> because it is versioned, it will never export anything new. A future
> version that exports more things can be called API-2-1.
Blowing my own trumpet, but what you are describing here is a conduit
package. Using conduits you'd define this as:
(defpackage :api-2-0
(:use)
(:extends/including :library #:open #:signal))
(you don't really need the null :use list, but I always have it because
there is 0 point in a conduit using any other package.)
There are also :extends, :extends/excluding options. You can extend
multiple packages:
(defpackage :org.tfeb.clc
(:use)
(:extends/excluding :cl
#:export #:unexport #:defpackage #:delete-package #:rename-package)
(:extends/including :org.tfeb.conduit-packages
#:recompute-conduits))
This example gives a better feel for why conduits are useful: you don't
have to know all the
symbols you care about, because it will find them for you. The package
being defined above is, of course, the one you use instead of CL if you
want the conduits version of DEFPACKAGE :-)
--tim
Tim Bradshaw schrieb:
> Blowing my own trumpet, but what you are describing here is a conduit
> package. Using conduits you'd define this as:
... snipped rest
Have you ever thought about creating a CDR for your conduits library?
IMHO local package nicknames and the extensions of how packages can get
constructed are a very valueable tool. I would offer to help if you
decide it to be a good idea.
ciao,
Jochen
"Tim Bradshaw" <··········@tfeb.org> writes:
> ··@codeartist.org wrote:
> > Have you ever thought about creating a CDR for your conduits library?
>
> What's a CDR (other than half a CONS)?
I think it's CL Document Repository set up by Pascal C:
http://cdr.eurolisp.org/
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Tim Bradshaw wrote:
> ··@codeartist.org wrote:
>> Have you ever thought about creating a CDR for your conduits library?
>
> What's a CDR (other than half a CONS)?
http://cdr.eurolisp.org/
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/