[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Package problem, revisted



    Date: Wed, 19 Aug 1992 11:35 EDT
    From: qobi@unagi.cis.upenn.edu

    I used to use symbols to refer to packages until I ran into the aforementioned
    difficulties. Then I switched to using strings. But this too has its problems.
    CommonLisp systems differ as to whether they use upper or lower case for
    package names (much in the same way as the case of symbol print names can
    differ). So I ran into problems trying to make a program portable across
    numerous CommonLisp implementations. That was about three years ago and I
    don't remember the exact details nor which was the offending implementation.
    (I think it was Allegro on NeXT or some derivative of KCL/AKCL/IBCL).

It was almost certainly Allegro CL.  It has a number of features that
allow it to handle default-lowercase and case-sensitive input,
presumably intended to make porting Franz Lisp programs easier.

    What I seem to remember was that while most implementations would put the
    symbol foo:bar in the package "FOO" one would put it in the package "foo" so
    that if you created a package "FOO" and then interned a symbol foo:bar it
    would go into a different package. I seem to remember that that implementation
    correctly treated the symbols bar and BAR to be equivalent but was case
    sensitive to package prefixes so that foo:BAR and FOO:BAR would be different
    symbols.

    Now I don't know whether that was legitimate behavior within the spec. That
    experience predated CLtL2 and though I haven't read CLtL1 in a while, I think
    that CLtL1 didn't deal with this issue. I remember that the last time I read
    CLtL2, it wasn't explicit on this issue either.

It is not legitimate according to CLtL.  P.173 of CLtL1 and p.250 of
CLtL2 both say, "When the Lisp reader sees a qualified symbol, it
handles the package-name part in the same way as the symbol part with
respect to capitalization."

It is my understanding that these case conversion features are
controlled by various parameters.  ANSI CL in incorporated this in the
form of the READTABLE-CASE function.  But the default settings of these
parameters should be such that the behavior specified in CLtL1 is
provided.

                                                barmar