[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
if COMPILE-FILE uses READ, and READ is extended
to read structured files, then COMPILE-FILE will do exactly what you
want, and there's no reason to make any chantes to its specification.
Yes, however, I believe the antecedent is false, hence I push on
COMPILE-FILE, which doesn't currently require READ. READ discusses
printed representation explicitly, so changing it is hard.
I've been taking a rather different approach to this -- instead of
trying to specify in what circumstances that loading a compiled file
will "work", I've been thinking more in terms of specifying in what
circumstances a file can be compiled so that it will *always* load
correctly when compiled.
Well, you must be a lot smarter than I am, because I cannot see how
you can specify that the compilation and loading processes will always
work without some constraints on both the compiler process and loader
(Of course, a program might not work for reasons that have nothing to
do with compilation, so effectively we're trying to get loading the
compiled version to exhibit the same behavior as loading the
By the way, conforming source code is supposed to work in any
conforming Common Lisp, but that same code compiled probably does not.
So I guess we cannot achieve your ideal.
If I were a total novice in Common Lisp, I'd rather know how to make a
program I wrote display the semantics I think it should have rather
than know that interpreted and compiled code behaved the same (but not
how I intended it).
Since we're trying specify Common Lisp, it seems we should trying to
specify how a correct program can be correctly run. I think other
languages care about this.
I don't think it's necessary to place any additional constraints on
the Lisp image being "fresh", or the compiled file being loaded
"immediately". What's more, I don't think there's any *reason* for
adding such an arbitrary constraint.
I guess your own parenthetical remark doesn't hold water with you.
- Re: 4.2
- From: email@example.com (Sandra J Loosemore)