Re: packages and portability

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

>> I think that site specific extensions may be of various kinds. For
>> example, the VAX LISP implementation of FORMAT includes 8 directives in
>> addition to those specified in CLtL. 

This is an upward compatible change and doesn't force double definitions.

>> In the same implementation,
>> APROPOS and APROPOS-LIST make use of DO-SYMBOLS rather than
>> DO-ALL-SYMBOLS, as specified in CLtL.  

This is a good example of the kind of extensions we want to avoid.  It
isn't upward compatible and it is only going to confuse the poor user
who is trying to program in common lisp using CLtL.  Why not choose
other names for your apropos functions?


>> In ZETALISP the special form IF
>> can take more than three arguments and arguments after the second are
>> assumed to be the ELSE clause with an implicit PROGN. 

I also dislike the common lisp 'if' special form, but rather than modify
it, I wrote a new macro, and gave it the name 'if*'.   In your case
I would suggest something similar.     I don't like typing 'if*' when
I really mean 'if', but the benefits far outweigh this inconvenience.
Besides, now code using 'if*' can be ported as long as I carry along
the definition of my if* macro.  


>> ...
>> Consequently, the approach of providing two distinct implementations
>> for certain extended CLtL objects may facilitate writing portable code.

 I disagree only slightly with this: you can write portable code 
regardless of the package layout, where your package setup helps is in testing 
for non-portableness (both by compiling the code and running it). 
But as the saying goes, "Testing only proves the presence of bugs, not the
absence", thus we agree that it would be foolish to use this as 
the only mechanism to test for portability.  
  And how can one ever test whether the user is using the correct 
version of 'apropos' in your system? The previous sentence is perhaps 
the key point:  unless we can agree to assign one meaning to each of 
the functions in common lisp, how can we ever achieve portability?  
If the presence of double definitions is a license to change CLtL 
functions at will, then I would be against using double definitions
for that reason alone.  

-john foderaro
 franz inc.