[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Compilation and package system

    Date: Wednesday, 10 April 1985  22:33-EST
    From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>

        Date: Tue, 9 Apr 1985  22:14 EST
        From: Skef Wholey <Wholey@CMU-CS-C.ARPA>

        First of all, it [the -*- comment convention] is not portable.

    I guess it's a matter of viewpoint which way is non-portable, depending on
    which way you're trying to port.  But let's not get into that.

Let's get into that for just one paragraph.  Nothing in CLTL says anything
about -*- comments.  Files with those comments will have the effect that you
(Dave Moon) expect them to in only one Common Lisp implementation: the
Symbolics CLCP.  The implementations done by DEC, DG, Rutgers, Kyoto
University, and CMU will not understand them.  I realize that (by itself) this
kind of survey is a bad way to decide language design issues, but the reason
that those implementations do not hack -*- the Lisp Machine way is that there's
nothing in the spec that says they should.

    We believe that complex package setups should go in their own files.

I have two programs that I've run on both Perqs and 3600's.  One is a Common
Lisp version of OPS-5, and another is the Spice Lisp microcode assembler.  Each
are contained in exactly one file, and are thus easy to move from system to
system.  Why should I need to double the number of files in such systems?

For us, "complex package setups" are a way of life, because we've chosen to put
the code for communicating with each OS server in its own file.  When I sit
down to write a graphics hack, I begin a file with
	;;; -*- Package: Hack -*-
	(in-package "HACK" :use '("LISP" "ACCINT" "SAPPH" "SESAME")).
I suppose our differences may stem from the fact that we Spice Lispers don't
think that packages are very expensive.  Packages can be used for little hacks
as well as big systems.  In the former case, one shouldn't need to stash this
information in a separate file that then must be loaded by hand (or in my init
file (or by some hook I frob in my init file)).

        The editor knows which package to associate with a buffer created when
        visiting this file, but the compiler and loader and everyone else just
        read Lisp forms, the way Father Lisp wanted them to.

    This all sounds at first like it makes a lot of sense, but wait a minute.
    I fail to see how the editor needs any less information about packages than
    the compiler and the loader.  How does the editor know the names of the
    functions in the file if it doesn't know what package they are relative to?

I guess I was being unclear.  The editor interprets -*- comments, and
associates a package with the buffer the file was read into.  This package is
made the default package (i.e. *package* is bound to it) whenever the editor
parses code in the file (e.g. for incremental compilation) or the echo area
(e.g. when asked to list the argument names of a given function).

If the package does not exist, then the user is asked if it should be created.
If that package uses packages other than LISP, then the user must evaluate the
In-Package or Use-Package or Import or whatever himself before counting on the
editor to parse code correctly.  This last step could be automated, but we
haven't done it.

    In our system all programs that read Lisp forms from files get the package
    information from the same place and they all work consistently.

Ah, but all those programs have to do some magic thing (not part of the Common
Lisp language) to interpret the stuff between -*-'s in the first line of the
file.  Should a user be able to write a portable slow-loader (that just reads
forms from a given file) or not?  I think he should.  People should be able to
write things like program cross-referencers in Common Lisp.  Portable Common
Lisp (whatever that means).

    IN-PACKAGE was put into Common Lisp over my dead body.

The rumors of your death have been greatly exaggerated.

    It might be worth some effort to standardize the semantics of -*-.

How about this: Symbolics could provide a portable -*- comment hacking package.
This would be made part of the yellow pages, and all implementations could
"voluntarily" adopt it as a thing that gets called by Load, Compile-File, etc.
This might then be adopted in Common Lisp Mark II (it's really no worse than
FORMAT, I guess).  I'm still personally biased against this idea (I really do
believe that a slow-loader should just read forms out of a file), but portable
code would make the Lisp Machine convention a lot easier to swallow.

On the other hand, we could decide that -*-'s don't port, and warn users about
differences from system to system.  Rob MacLachlan has suggested a very
sinister solution to the problem: conditionalized constructs in -*- coments...

    -*- #+LISPM{Syntax: Common-Lisp; Uppercase: Mostly;} Package: Zippy -*-