[m-dev.] Re: for review: big rats
fjh at cs.mu.OZ.AU
Fri Apr 10 00:25:34 AEST 1998
On 09-Apr-1998, Peter Schachte <pets at students.cs.mu.oz.au> wrote:
> > I've done this, but I think adding the `where equality is <blah>'
> > approach may be preferable since it makes the code blindingly obvious:
> > it does what it says not what the comments say.
> > (Who has any faith in comments?)
> Not me. But this won't work, if what I said above is true. It'll only fix
> the problem for unification, not for other places where the representation
> is assumed to be normalized.
I think Bert meant adding `where equality is <the usual equality>'
(basically just as a comment, to emphasise the fact that the representation
must be kept normalised), not a `where equality is <some other relation>'
(which could allow non-normalised representations).
> This is interesting: there are actually two potential problems with types:
> 1) when the type is not canonical (two distinct objects represent the same
> value), and 2) when the type is not total (some instances of the type are
> not admissible). Unfortunately, 'where equality is ...' only solves the
> first problem.
What exactly is the problem in case (2)?
Case (2) is actually a very common case.
But it seems to me that in practice you can get along OK
without any additional language support for this case.
Certainly we've managed to do so thus far without
any significant practical problems sticking out.
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh at 188.8.131.52 | -- the last words of T. S. Garp.
More information about the developers