[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: packages and portability
- To: Alan Snyder <ucbkim!hplabs.HP.COM!snyder%hplsny>
- Subject: Re: packages and portability
- From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
- Date: Tue, 17 Jun 86 19:21:03 PST
- Cc: email@example.com
- In-reply-to: Your message of Tue, 17 Jun 86 09:58:20 GMT. <8606171658.AA00290@hplsny>
>> 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
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
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
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
Sorry for being so longwinded, I think that this is one of the more
important issues to be resolved.