Re: [Haskell-cafe] type inference and named fields

27 Jun 2005


      Christian Maeder  writes:
...
Typing fails in your original example:
    voidcast v@VariantWithOne{} = v {field1 = Void}
but not in the "lambda equivalent"
    voidcast v@VariantWithOne{} =
       (\ (VariantWithOne a) -> VariantWithOne Void) v
Hmm.  Yes, that was my original point.
...
But
    voidcast v@VariantWithOne{} = ( \ x -> case x of
       VariantWithTwo a b -> VariantWithTwo Void b
       VariantWithOne a -> VariantWithOne Void) v
fails like the field notation.
Yes, this is a more accurate translation of the field notation to a
lambda expression, and therefore suffers the same problem.

My proposal was to allow
    voidcast v = v { field1 = P, field2 = Q }
to be interpreted as the lambda expression
    voidcast v = ( \ x -> case x of
       VariantWithTwo a b -> VariantWithTwo P Q
       VariantWithOne a -> VariantWithOne P) v
where the information about field2=Q is omitted from the clauses where
no field2 exists.  (I'm using P and Q instead of Void, to highlight
the apparent loss of information on the RHS of the pattern-match.)
...
I think writing "VariantWithOne {field1 = Void}" instead of
"v {field1 = Void}" is as clear as writing "Right r" again on the rhs
instead of "x" from the pattern "x@(Right r)"
I can only repeat myself, that the field being updated (and
type-converted) is only one of many, and all other fields should
carry the same value in the updated structure as in the original.
There is no good way to write this at the moment.  If there were no
type-conversion, a field update would work just great.  But because
of the conversion, one is forced to use explicit construction.

Regards,
    Malcolm

Re: [Haskell-cafe] type inference and named fields

Malcolm Wallace