[Hugs-users] Trex label names: leaky abstraction

[Anthony Clayden]

Gaster & Jones 1996 says
"We consider two rows to be equivalent if they include the same fields
regardless of the order in which they are listed." [section 3.2]

But this is tricky: Figure 6 shows there is an ordering on labels, so that
in effect records are compiled to tuples with left-to-right ordering of
label names alphabetically.

The User Manual says
"The order of fields in a record pattern *is* significant because it
determines the order---from left to right---in which they are matched."
In particular, a pattern match on a record with a field value `undefined`
might succeed if some other field label is mentioned first in the pattern;
but throw an error if it's the undefined field's label mentioned first.

It's not difficult to expose this behaviour. Consider

> import Hugs.Trex
>
> x5y = (x = 5, y = 'y');   x7y = (x = 7, y = undefined)
> z5y = (z = 5, y = 'y');   z7y = (z = 7, y = undefined)
>
> x5y == x7y     -- returns False
> z5y == z7y     -- throws error Prelude.undefined

The tuples with label `z` are compiled to put that field second, regardless
of the order of appearing in the expression. Then (==) applies by comparing
field values in left-to-right alphabetic ordering. Field `x` is
alphabetically before `y`; and the `x` values differ; so the comparison
returns False without comparing the `y` values. Then in comparing the field
`z` records, the `y` fields are compared first (ignoring that the `z`
values differ), exposing that one `y` field is `undefined`.

This is similar to comparing tuples

> (5, 'y') == (7, undefined)   -- returns False
> ('y', 5) == (undefined, 7)   -- throws error

There seems to be some infelicity when building records:

> f ... rho ... = (y = 'y' | rho)

This throws strange errors depending whether `rho` includes labels that are
alphabetically before `y`. Bug report incoming ...


AntC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/hugs-users/attachments/20181109/9e34b2b3/attachment.html>