[r6rs-discuss] [Formal] blame assignment for contract violations
At Tue, 31 Oct 2006 18:34:34 +0100, Michael Sperber wrote:
>
> "Carl Eastlund" <cce_at_ccs.neu.edu> writes:
>
> > If module B needs to be sure of module C, it needs to add a contract
> > to the point where it hands off F, so that C will be blamed for
> > violating that additional contract before B gets blamed for the
> > original one.
> >
> > Does that clarify the issue?
>
> Yes, thanks.
>
> Now, I confirm the current draft does not identify the entity that's
> to blame explicitly. However, *some* entity broke the contract with
> the entity named in the call to `contract-violation'. As Robby
> pointed out, identifying who's to blame is tricky. (And the notion
> you describe makes sense formally, but certainly other notions as to
> who's to blame may be equally useful. Your notion doesn't always
> coincide with "what code needs to be fixed.")
> While having the name
> of who's to blame is certainly preferable, it's not clear to me why
> the term should be inapplicable if we don't.
The English definition of the word "contract" is all about agreements
between particular parties, etc. The other, perfectly good, English
word is "assertion" and there is certainly a track record for its use
in programming languages. (I prefer real contracts, but I understand if
r6 isn't ready to do that!)
Of course, one could say "contract" with the intention that there are
always the same two parties, namely r6 and the program itself. In that
case, the blame always rests with the program, and it is implicit in
the use of the `contract-violation' function that the program is to be
blamed.
In this world it would be, in some sense, "unsound" to hand out the
contract-violation function to the program, since it could blame
itself, even when it hadn't done anything wrong. (But this is kind of a
silly thing, of course.)
Robby
Received on Tue Oct 31 2006 - 12:48:51 UTC
This archive was generated by hypermail 2.3.0
: Wed Oct 23 2024 - 09:15:01 UTC