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
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
.



Relevant Pages

  • GNU coreutils -- release
    ... I am happy to announce a test release of the GNU coreutils. ... The GNU coreutils package is the combination of and replacement ... special permission bits, as POSIX requires. ... destination if the resulting time stamp would be no newer than the ...
    (comp.os.linux.announce)
  • Re: Package-qualified symbols & unUSEable packages -- threat or menace?
    ... Load code that depends on a system package named POSIX, ...
    (comp.lang.lisp)
  • Re: Representing errno in SPARK
    ... operations to another package internal to POSIX (but this means having ... an implementation for the POSIX versions of these subprograms). ... that has the Errno abstraction and the imported subprograms. ...
    (comp.lang.ada)
  • Re: compress, uncompress no sim link to gunzip?
    ... >> Interesting that the man pages are not packaged with that rpm. ... Most likely compress.1p and uncompress.1p for POSIX, ... within the man-pages package. ... To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list ...
    (Fedora)
  • Re: A real package manager in action
    ... I believe package management is about permitting multiple versions of ... libraries should not change their APIs so correctly written programs will ... systems on linux platforms, the multi-version problem can lead to a need to ... merely to install them. ...
    (comp.sys.acorn.apps)