gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] packages & exported symbols (was: system, load-time-value)


From: Debian User
Subject: [Gcl-devel] packages & exported symbols (was: system, load-time-value)
Date: Mon, 16 Feb 2004 09:11:03 +0000

        | (#<"CONDITIONS" package> #<"SLOT-ACCESSOR-NAME" package>
        |  #<"PCL" package> #<"ITERATE" package> #<"WALKER" package>
        |  #<"TK" package> #<"DEFPACKAGE" package> #<"ANSI-LOOP" package>
        |  #<"SERROR" package> #<"SLOOP" package> #<"COMPILER" package>
        |  #<"SYSTEM" package> #<"KEYWORD" package> #<"COMMON-LISP" package>
        |  #<"COMMON-LISP-USER" package> #<"LISP" package>)
        |
        | This is a 2.7.x item.

        I suppose that we should really look at what is most
        compatible with the other major CL compilers to ease
        porting including, perhaps, aliases of other compilers'
        package names where compatibility of exported symbols
        is substantial.

        For back compatibility with AKCL and/or CLTL1 perhaps
        we could have separate packages for each.

        To avoid exporting extraneous symbols, we should make
        sure that no support functions are exported from those
        packages.

        Other than that I have no preferences.

Currently I have no particular preferences either that I can
think of.  I checked gclcvs with PACKAGE-USED-BY-LIST and
PACKAGE-USE-LIST on the various packages and it looks fine.
The init files in unixport does some explicit exporting/importing
of symbols between the packages which makes the dependencies
between packages a bit hard to see, so I cannot really tell.
Avoiding exporting symbols to COMMON-LISP that don't belong there
should do it -- directly as well as indirectly through use of
other packages.  As for COMMON-LISP-USER I have gotten used to
having "everything" there too.  I haven't discovered any actual
issues with it yet.

It can be changed in the future if need be.  I don't think
of as a problem, just a potential issue to be aware of when
extending GCL with new stuff.

Yours

Dennis Decker Jensen





reply via email to

[Prev in Thread] Current Thread [Next in Thread]