[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
This is a lot better than what's there now, but I still prefer the
I wouldn't expect less.
I don't think this is a problem. Every conforming implementation must
have a notion of files which contain characters and be able to READ
from those files.
Oh? This is an logically valid implication from CLtL, where it implies
use of READ during LOAD and suggests a model for COMPILE-FILE that
uses READ. READ is the only place (I think) where the use of a printed
representation is required. I think we should abandon this requirement.
I don't think that requiring COMPILE-FILE to be
able to READ these files is a great hardship on implementations that
also happen to support files containing source code in some other
structured representation. Of course, these implementations would
probably also want to extend COMPILE-FILE to also accept the
structured input files.
Using your requirement of using READ, any use of COMPILE-FILE would
need to operate on a printed representation. The reason to not use
printed representation is to avoid the cost of parsing tokens which in
most compilers and such tools is the highest single performance
problem. So you're suggesting as the no-problem solution the very thing
these implementations went to the trouble to avoid. Cruel.
Of course, these implementations would probably also want to extend
COMPILE-FILE to also accept the structured input files.
Not if COMPILE-FILE uses READ. Are we still talking about the same thing?
I think the use of the word "fresh" in choice number 2 might have the
wrong connotations here. To me it implies a completely clean
environment containing nothing but the symbols and definitions that
are initially provided by the implementation. I think that what you
really want to say is that the copy *might* be a fresh copy, but leave
open the possibility that it could contain other user-supplied
definitions as well (for example, as a result of previously loading
some other files). Likewise, I would strike the word "immediately"
from choice number 1.
If we say the copy *might* be a fresh copy, we should also say that
the compiled code *might* work. What I want to see clearly explained
is a prescription of the structure of a compilation unit, a
compilation scenario, and a load scenario that is guaranteed to work
in every conforming Common Lisp. Maybe some others will work, and we
can state some general directions for extension that should work. But
we absolutely must specify the safe scenario.
I understand what you meant by using "compatible" here. My question
is, is this new wording you suggest something that you would prefer to
the amendment that was offered at the last meeting (which said
something quite different), and is that your own personal opinion or
are you speaking for the CLOS cabal? To tell the truth, I think that
amendment is going to open up a can of worms and I'd really like to
find some other compromise position.
I was simply mentioning another possibility. The same metaclass
proposal is certainly safe, but maybe overly so. My comment on your
draft, which I phrased as a question, was not meant to trigger any
particular action. Maybe Moon has an opinion?
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Re: 4.2
- From: firstname.lastname@example.org (Sandra J Loosemore)