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

[Camm Maguire]

Greetings!

Debian User <address@hidden> writes:

>       | (#<"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.

Yes, all this init file stuff needs to be cleaned up substantially.
What's in there is an attempt to get as much quick ansi compliance as
possible. 

Take care,

> 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
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah