Re: Package-qualified symbols & unUSEable packages -- threat or menace?

js@xxxxxxxxxxxxxx writes:
Richard M Kreuter schrieb:
js@xxxxxxxxxxxxxx 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

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.