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

Compilation and package system



    Date: Wed, 10 Apr 1985  23:51 EST
    Message-ID: <WHOLEY.12102192890.BABYL@CMU-CS-C.ARPA>
    Sender: WHOLEY@CMU-CS-C.ARPA
    From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
    To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
    Cc:   Common-lisp@SU-AI.ARPA
    Subject: 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.

Don't be silly. Common Lisp programs don't have to run gracefully in all 
implementations, they just have to run. If a person has written -*- ... -*-
and not put (IN-PACKAGE ...), he has not written a common lisp program.
But that doesn't mean the Lisp Machine doesn't support IN-PACKAGE. If a 
person has put (IN-PACKAGE ...) but no -*- ... -*- that means his program
will run in the way Common Lisp says it will, but that doesn't mean it will
interface gracefully to parts of the system not specified by Common Lisp.
The Lisp Machine simply (and reasonably) suggests that in order to work
compatibly with non-Common-Lisp utilities and still be portable, you should
do -*- ... -*- and (IN-PACKAGE ...), redundantly. In fact, I suspect that
users will be content to use simply -*- ... -*- and add (IN-PACKAGE ...) only
when they get around to actually shipping files but that shouldn't matter.

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

Of course, for this sort of thing I usually just write:there's the alternate syntax:
  ;;; -*- Package: ("HACK" :USE ("LISP" "ACCINT" "SAPPH" "SESAME")) -*-
which seems to work OK...

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

Don't forget the Lisp Machine uses -*- ... -*- for other languages besides lisp.
(IN-PACKAGE ...) would not work at the top of files in other languages besides
lisp and we don't have hands in design groups for every existing language so 
cannot always get those languages to add a syntax for specifying the package.
Putting it in a comment is mostly likely to win in all languages since nearly 
every language has a comment syntax and I know of no languages for which the 
comment syntax is not compatible with -*- ... -*-.

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

    --Skef