Re: packages and portability

[franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)]

>> I agree about the fact that the uniformity of your package model is
>> indeed appealing, however this model may prove inconvenient to use in
>> the case of symbols that have two distinct definitions, one each in
>> the pure Common LISP and in the extended package. In fact, I think
>> that a desirable feature of the future package configuration is not
>> to preclude the possibility for a symbol to be defined in both the
>> pure Common LISP and the extended package. 
  
  I don't like to preclude anything either since I can't predict the future
nor do I know the requirements of other implementations, but I know that 
right now what I've described is the better setup for our implementation.  
We don't have (and never plan to have) any external symbols in common 
between the lisp package and the excl package (nor any of the other 
extension packages), thus users can use and unuse packages with any problems.



>> In addition, it is not immediately obvious to me that the package
>> name EXCL is going to be exclusively used by Franz: it sounds like an
>> acronym for extended Common LISP and may therefore be used by
>> multiple implementations.

By the same token, 'vax-lisp' is a pretty generic package name, and I might 
want to use it to store my vax-only lisp functions.   I think that with
a little cooperation we can manage to avoid stepping on eachother's package 
names.  



>> I agree that extensions to white page objects should be upward
>> compatible, however I don't think it is possible to establish a fixed
>> upper bound on such extensions and on the amount of documentation
>> for each of the extensions (e.g. the VAX LISP User Guide
>> documentation for COMPILE-FILE is three pages long).

I didn't mean to limit the length of the documentation of the extended 
functions, just that it is our goal that the actual list of changes will 
fit on one page.  An example of a change is

  compile-file: takes an extra keyword argument :cross-reference

The documentation that describes compile-file is elsewhere. The 
user interested in portabily can search his code to see if the 
:cross-reference keyword is passed to compile-file.



>> In summary, I
>> think that the most reliable way to deal with white page extended
>> objects is to provide two distinct definitions, one for each of the
>> two packages. Although double definitions may not appear to be
>> necessary for the time being and may be tedious to implement, I think
>> that they should not be precluded a priori from future
>> implementations. 

We agree that double definitions aren't needed now and would be tedious
to implement.   I personally feel that they are also too dangerous.  If it was 
determined that adding something like the :cross-reference argument to
compile-file was an illegal extension, then I would rather create a new
function (excl:excl-compile-file) than create a double definition for
compile-file.

   What extensions do you see in the future that would make double 
definitions necessary?  


-john foderaro
 franz inc.