Re: packages and portability

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

>> Hmmm. I always thought that one of the virtues of having a package system is
>> that you don't have to resort to sticking prefixes on your function names.
>> Defining distinct symbols LISP:COMPILE-FILE and EXCL:COMPILE-FILE seems
>> cleaner to me, if the intent is that EXCL:COMPILE-FILE is a 
>> localized version
>> of LISP:COMPILE-FILE.  I think we should support this sort of thing.
>> -------

 In this particular case, I think that it should be legal for me to add the
:cross-reference argument to the compile-file function in the lisp package.
Do you agree?  Thus I would never have to create the function 
excl-compile-file.  

 However if I decide that I'd like compile-file to have the form
	(compile-file filename &rest functions)
and to compile only those functions listed in the named file, then
I've made a significant change to compile-file and I should give it
a new name (like excl:excl-compile-file).  Using excl:compile-file would
just be confusing.


 
  This example is pretty trivial, let's step back and look at the big 
picture.  The DEC proposal and our proposal are trying to solve the same
problem: creation of a lisp system in which is possible to write portable
programs as well as implementation specific (non-portable) program.

The DEC proposal does this by creating a package of functions which 
follow the spec set out in CLtL, and do nothing more.  Functions which
have extended behavior have the same name and are found in another 
package.  Nothing is said about how different the extended functions
can be from the original ones.

The ExCL proposal is to have a single function to implement
each of the CLtL functions and their extensions, and the only extensions 
that are permitted are those that are upward compatible (and typically 
involve adding a keyword argument).   Furthermore the number of such extensions
will be small and well documented.

  

Under both proposals it is easy to write portable code.  To verify that your 
  code is portable you really have to check your source to see if you've
  used any extensions.  Under the DEC proposal the system will catch 
  non-portabilities in the CLtL functions as the code is running, but 
  of course it won't catch them all unless you exercise every path of the code.
  In the ExCL proposal you have to take the handy 'extensions sheet' and check
  by hand that you haven't used any extensions.  Of course, the careful 
  programmer will simply not use extensions in portable code.

Under the ExCL proposal it is simple and natural to switch between the 
  extended and portable modes.  Under the DEC proposal the procedure is
  more difficult.

The ExCL proposal shows off the power of the package system in the ability
  to easily move into and out of the extended environment.  The DEC
  proposal shows off one of the big misfeatures of the package system: that you
  have to go to so much trouble if you merely want to shadow one symbol
  in the lisp package.  Do we want users to emulate this kind of package
  construction?

If we ever want to do double definitions in the future, then the DEC proposal 
  sets up the framework.  The ExCL proposal doesn't prevent double
  definitions but it doesn't set it up either.  If double definitions will
  be important in the future in order to implement extensions
  then we should be able to come up with a few examples where they would 
  be important.   I can't think of any.  As I see it, either the extension
  is so trivial you can add it to the standard definition, or the extension
  is so large that you'd be better off renaming the extended function to avoid
  confusion.


Sorry for being so longwinded, I think that this is one of the more 
important issues to be resolved.

-john foderaro
 franz inc.