4.2

[Richard P. Gabriel <rpg@lucid.com>]

     This is a lot better than what's there now, but I still prefer the
     original wording.

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?

			-rpg-