[Haskell-cafe] type inference and named fields

[Christian Maeder]

Malcolm Wallace wrote:
> Here is a strawman proposal, which does not fix the consecutive update
> problem, but which might address the original typing problem.

I think it does not really address the original typing problem.

It would allow you to write:

> voidcast v@(VariantWithTwo{}) = v { field1 = Void , field2 = Void }
> voidcast v@(VariantWithOne{}) = v { field1 = Void , field2 = Void }

Setting field2 only assures type correctness, but the value of field2
would be ignored at runtime.

I'ld rather define an empty polymorphic element and update that one:

e = VariantWithOne { field1 = undefined }

voidcast VariantWithOne{} = e { field1 = Void }

In the last line e is (only) instantiated (and not casted).

> The Report (section 3.15) defines the following conditions on a named
> field update:
> 
>     * all labels must be taken from the same datatype
>     * at least one constructor must define all of the labels mentioned
>       in the update
>     * no label may be mentioned more than once
>     * an execution error occurs when the value being updated does
>       not contain all of the specified labels.
> 
> Now, this last condition is rather nasty - a runtime error - and I
> would like to eliminate it.  I think we can do so by also eliminating
> the second condition.  That is, I would like to be able to use a set of
> labels that might not be contained solely within a single constructor.
> The obvious semantics is that if a constructed value does not contain
> a label of that type, that part of the update is discarded.  Hence,
> I could write a single expression that updated all possible variants
> of a type, simply by unioning all their possible labels.

I want to detect errors as early as possible.

Christian