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


In spite of the fact that there is no recent mail on this issue, I'm
bugged that you think this is stable.

I have voiced very strong objection to this proposal and there is no
mention of the fact that I dissent, nor my reasons in the discussion.

[As an aside, I feel compelled to note that I feel that a key distinction
 between the proposals circulated on CL-Cleanup and those circulated
 on CL-Compiler is that the CL-Cleanup forum is extremely concerned with
 getting a fair presentation of everyone's position. In general, Cleanup
 does not drop alternative proposals unless they can achieve consensus
 that it is not worth pursuing the alternate proposals. Since this 
 proposal doesn't satisfy me and others which were closer to correct 
 have been dropped, I do not believe that the presentation is unbiased,
 and I believe a disservice is done to the community. Remember that
 the full community is not necessarily fairly represented within the
 microcosm of CL-Compiler, so just because something is not "receiving
 much support" within CL-Compiler doesn't mean it won't outside. The 
 question is what is technically defensible. The REQUIRE-PREPASS proposal
 was, for example, technically defensible and arguably the right thing.
 Moreover, since you are proposing an incompatible change, my feeling is
 that the burden is on you to demonstrate that you have a compelling 
 justification for doing so. I don't think you've made that case fairly,
 presenting arguments both pro and con. I don't think this presentational
 bias is unique to this issue.]

Returning from the meta-level, let me say that I continue to believe
strongly that this whole issue is ill-presented. I agree that COMPILER-LET
is ill-presented in CLtL, but that doesn't mean it's useless.

This proposal reads like "Well, they didn't describe it right and we
can't figure out how to make sense of it, so let's pretend it served no
purpose and remove it."

I've made a case that it expresses a useful high level concept and that
it can be coherently implemented. The truth is not that it is impossible
to either describe coherently or to implement, only that there is a cost
to some implementations to bring them in line with such a description.

For the presentation to be fair, it must present the following things:

 - The original intent of COMPILER-LET, which acknowledges that it
   had a valid, useful, and potentially portable purpose.

 - A description of why COMPILER-LET was ill-described in CLtL,
   hiding the original intent.

 - A description of how the poor description in CLtL led
   implementations to make certain assumptions about how they could
   implement some kinds of things (like environments).

 - A description of why these assumptions that have been made by
   existing implementations now mean that implementing the correct
   semantics would have a certain non-negligible cost to certain
   implementations, and a serious account of what that cost might be.

 - A description of the two legitimate options:

    * Fix the description of COMPILER-LET.

    * Remove COMPILER-LET.

I want people to make an informed decision. If on the basis of a fairly
presented case, people make a reasoned decision to not go with COMPILER-LET,
I will not be unhappy.

If, instead, you present a proposal which shows only a highly biased
viewpoint with no attempt made to be fair, and people vote on this based
on what I expect will be a misunderstanding of the true situation,
then I will be quite unhappy.

These cleanup writeups will stand as the closest things to rationales
for why we changed the language or did not. I want the record to reflect
the full set of facts, and our ability to make reasoned choices about
hard issues. I do not want the record to reflect someone railroading
something through without proper presentation.

I hope this message suffices to dispell any belief that we are all
basically ready for a vote on this issue as currently presented.