packages and portability

["BIZET::BUY" <buy%bizet.decnet@hudson.dec.com>]

This message is in reply to two previous messages by John Foderaro
about packages and portability.

> >> 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.
> 

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. In the same implementation,
APROPOS and APROPOS-LIST make use of DO-SYMBOLS rather than
DO-ALL-SYMBOLS, as specified in CLtL.  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. Other kinds of
site specific extensions are additional keyword arguments to CLtL
functions, additional values returned by CLtL functions, extensions to
valid input argument types for CLtL functions.

Let us assume that 'X' is a symbol whose CLtL definition was extended
by a particular implementation of Common LISP and let us consider the
issue of what package should contain X. If X is contained in the
extended package only (for portability), the pure Common LISP package
will be incomplete with respect to the specification in CLtL.
Conversely, if X is contained in the pure Common LISP package (for
completeness of an implementation), users may end up inadvertently
using site specific extensions and thus writing non-portable code.
Consequently, the approach of providing two distinct implementations
for certain extended CLtL objects may facilitate writing portable code.
 
>                                ... 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.
> 
> ....
> 
> 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?
> 

In our opinion, the model we proposed represents a reasonable
compromise between ease of use and flexibility. I don't think that the
procedure to switch between the extended and the portable environment
is so difficult as to constitute a serious drawback (see my previous
messages about this). Moreover, the model deals uniformly with double
definitions for objects defined in CLtL. In addition, this model
supports effectively writing portable code. I obviously agree about the
fact that run-time checks for portable code are indeed useful.
Compile-time checks may contribute even more significantly to the
detection of non-portable code.


> 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 thfunction to avoid confusion.


In our opinion, the Franz proposal indeed renders double definitions
substantially more inconvenient to use when trying to switch from a
pure Common LISP to an extended environment and vice versa. I discussed
the reason for this in a previous message.

Thanks for your attention and again sorry for the length of this
message, 

				Ugo Buy
				
				ARPAnet:  BUY%BARTOK.DEC@DECWRL.ARPA
------