Re: [BUG]Collection>>removeAll:

On Thursday, August 29, 2002, at 02:10 AM, Richard A. O'Keefe wrote:

> Allen Wirfs-Brock <Allen_Wirfs-Brock@xxxxxxxxxxxxxxxxxx> wrote:
>         I must have missed the messages where you quoted the standard,
>         but I did consult the actual text of the actual standard (not a
>         draft).  The words are what they are and I see how you could
>         interpret them such that they allow the position you are taking.
>
> GOOD.  Thank you very much.
>
>         However, as a very active participant in the drafting of the
>         standard, I can tell you that it was not the committee's intent
>         to require this!
>
> At least in this country, when they interpret a law, judges are 
> required
> to interpret the text of the law itself, in the light of other laws and
> how courts have interpreted them and the law in question.  But they are
> NOT allowed to consider Parliament's intent.

Now it's my turn to say, Oh Come On.  Richard, having abandoned 
technical argument, has turned to legal advocacy instead.  While I 
welcome a parry or two on my home turf, I think there is really no 
place in this forum for such sophistry.

For perspective, Richard, the opposite is true in the United States -- 
although it is a question of judicial philosophy.  I am no expert on 
the subject, however, but I am aware of several recent UK opinions 
involving technology law where judges did precisely what you state they 
are not permitted to do to resolve ambiguities in the law, expressly 
distinguishing between Common Law jurisdictions, such as the UK, (most 
of the) US and Canada, and civil law jurisdictions.

In general, where a law does not clearly state how an issue is to be 
resolved, or states in different places conflicting suggestions, it is 
quite common to use (among a huge litany of other devices) legislative 
history manifesting original intent to determine what is the law.

> The same is generally held to apply to programming language standards,
> at least that's how it has been done in the case of C and Ada.

Huh?  Where is this written?  Is this simply the rule you are adopting 
because any other puts your conclusion in jeopardy?  Indeed, I don't 
believe it is true: the original Ada standard was so full of holes 
there could be no conforming implementation.  Ultimately, the standard 
and implementations moved until it was possible to certify one or two.

> Indeed,
> there is a very clear clash between the C89 standard and the express
> intent of the people who wrote it, and the text of the standard was 
> held
> to be definitive, NOT the authors' intent.

"held to be definitive"  By which court of chancery?  Come on, Richard. 
 As between you and Alan,

> The reason for this is obvious.  People trying to implement what the
> standard says, and people trying to use the standard as reference
> material to determine what they can expect, have in the past been
> most unlikely to have access to the authors or any other way of 
> determining
> their intent other than the text itself.

1) Who is trying to implement the ANSI standard?
2) I thought you were arguing what the standard SHOULD be, not what it 
was.  Where Alan Wirfs-Brock informs us that the standard, to the 
extent you are relying upon it, would be likely to be revised even to 
the extent you stretch the words to support your position, isn't that a 
powerful argument that your position is, well, at least, tenuous or 
hyper-legalistic?

> Nor can we always appeal to prior art.

Why not?  Is it, perhaps, because such argument might not support your 
conclusion?

> Sometimes a standard extends
> the coverage of things.  That's the case in ANSI C, for example.
> Before the ANSI standard, malloc(0) was undefined and so was 
> free(NULL).
> In many systems, they didn't work.  The ANSI C standard said they had 
> to.
>
> The prior art for #removeAll: may well have been broken; although you
> will search textbooks and reference manuals in vain for any hint of 
> this.

To the contrary, the existing "prior art" may have been correct, and 
the existing textbooks and reference manuals, which describe the 
principle of the non-mutating iterand, hint dramatically to the 
contrary of Richard's position.  Perhaps he is marginalizing twenty 
years of wisdom, not only because he believes it is mistaken, but 
rather because it does not support his desired result?

> Someone with access to the ANSI Smalltalk standard discovering this 
> could
> reasonably conclude that it was the intent of the ANSI committee that 
> the
> bug be fixed.

Yeah, that well-published ANSI Smalltalk standard is just so well-known 
and commonly relied upon by newbies and experts alike.  Be real.  If 
this is your strongest argument, the battle is lost.

> Indeed, the _only_ thing about #removeAll: that makes the
> "fixed" interpretation implausible is returning the argument instead of
> the receiver, and someone noting that the return value is unspecified 
> in
> ANSI Smalltalk could again reasonably conclude that this removed the
> only barrier to an exceptionless reading.

Duh.  That is to some of us a powerful argument why it can't mean what 
Richard says it means.

>         This is an issue we missed.
>
> And #addAll:, and whether #hash may be applied to cyclic objects, and 
> ...

It would appear that Richard relies heavily on the standard to support 
the points he loves, and disses it otherwise.  Of course the standard 
is flawed.  It is, after all, the first draft, and recently adopted.  
The "authoritative" view will be time-tested, and we shouldn't resolve 
the interstices and obvious omissions by legalistic mumbo-jumbo.  Take 
it from me as a seasoned lawyer -- such argument rarely leads to 
justice.

> This is another reason why we have to work with the text,
> rather than with the intent of the committee.

Nobody has to work with the text.  This is the difference between a 
promulgated standard and the law.

At the end of the day, the question is this -- what should Squeak do?  
Richard argument from the text of the standard is only arguable, and to 
the extent arguable, Alan's explanation only further reinforces the 
extent to which Richard is mistaken about what the rule should be.  At 
any rate, I see no need to "jump on the standards bandwagon" as the 
sole basis for proceeding, in view of the obvious controversy.

We should either do nothing, or catch the error.  Nothing more.