Edison RC3
Robert Dockins
robdockins at fastmail.fm
Wed Apr 5 11:01:32 EDT 2006
On Apr 5, 2006, at 5:12 AM, Nils Anders Danielsson wrote:
> On Wed, 05 Apr 2006, Robert Dockins <robdockins at fastmail.fm> wrote:
>
>> The 3rd release candidate for Edison 1.2 is now avaliable.
>
> In the documentation you write:
>
> An instance of an abstract data type is considered indistinguishable
> from another if all possible applications of unambiguous operations
> to both yield indistinguishable results. In this context, we
> consider bottom to be distinguishable from non-bottom results, and
> indistinguishable from other bottom results.
>
> I believe this wording is somewhat too strong. It is usually very hard
> to achieve what you are claiming above, since (among other things)
> bottom and const bottom are distinguishable.
Ugh! Of course, you are right (eta-conversion bites again!). Most of
this paragraph is left-over from when I was using the terms
'ambiguous' vs 'well-defined' rather than 'ambiguous' vs
'unambiguous'. I felt that I needed to say that 'well-defined' !=
'not bottom', and that meant I had to talk about bottom. Now, I'm
using 'unambiguous' which doesn't have that particular confusion, I
should probably rewrite that paragraph.
> Typically when Haskellers claim various properties for their functions
> they ignore bottoms (and often also infinite values), reasoning in a
> "fast and loose" way. This is seldom explicitly mentioned, though, so
> I guess many may not be aware of this. Your statement makes it seem as
> if you have done more than the ordinary, fast and loose, reasoning,
> and I find it misleading.
So you think it would be clearer if I just ignored bottom as well?
That's certainly easier on me; it means people can't start providing
nasty counterexamples to my function contracts using 'seq'!
> Of course, if you have actually gone to the trouble of verifying your
> statement for all the data structures, then you should keep the
> statement (with an extra note about proofs written or tests
> performed).
No, this has not been done. I have thought about employing
Programmatica to formalize the contracts and verify implementations,
but its just a pipe-dream for now.
> --
> /NAD
>
Thanks for pointing that out (and for letting me know that at least
one person out there reads the documentation! ;-) )
Rob Dockins
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
-- TMBG
More information about the Libraries
mailing list