Re: Issues with the logical consistency of The Third Manifesto

Marshall Spight wrote:
> Okay, so you're right; if we find ourselves is this situation, then we
> have to, as it were, normalize the representation. This is hard. If
> we only have one possible representation for a type and it's always
> normalized, then this isn't an issue. For example, we can have
> a rational type, and normalize the fraction after every operation.
> In this case, comparing the representation and comparing the
> values is the same.

It might be more efficient to store it unnormalised and only normalise before an equality test. Maybe you won't even need to normalise - the standard example is fractions: to test if a/b and c/d are equal you might just test if a*d = b*c for example, instead of worrying about highest common factors.

I guess in theory a type implementation would use some kind of heuristics to decide what's going to be best in any situation.

I think that standard SQL blurs the line between types and relations a bit with its equality test. For example:

  SELECT * FROM t WHERE a = b

The equals is seen more as part of the relational algebra rather than the type algebra. Why can't WHERE clauses take boolean values like this?:

  SELECT * FROM t WHERE equals(a,b)

Maybe it's because SQL doesn't really have proper support for user-defined types yet.

Paul. Received on Tue Nov 16 2004 - 09:28:20 CET