thoughts on the record update problem

[Greg Weber]

On Thu, Mar 8, 2012 at 12:37 PM, Chris Smith <cdsmith at gmail.com> wrote:
> On Thu, Mar 8, 2012 at 1:00 PM, Greg Weber <greg at gregweber.info> wrote:
>> This discussion has largely centered around trying to come up with a
>> hack that desugars to Haskell's existing language constructs.
>
>> There is an alternative to a desugaring hack: add a real record
>> construct to the language.
>
> I am not sure what distinction you are making between "real record
> construct" and "desugaring hack".  As far as I can see, all major
> proposals currently desugar to type classes... not as a "hack" but
> because type classes *are* how Haskell does type-directed resolution.
> I don't think there are any ground rules set against proposing a
> system that doesn't use type classes.  If you wanted, you could
> certainly propose a system that defines brand new and potentially very
> different semantics for a desired record system from scratch, and has
> nothing to do with type classes.  I tend to think it would be a poor
> idea, both because it would be a large amount of work to be sure the
> semantics are even nailed down well, and because then the progress of
> abstraction over that new construct would happen independently from
> the existing progress of abstraction over type classes, and we'd end
> up with a more complex and warty language as a result.
>
> In any case, I'm in agreement that "stop arguing about semantics and
> just implement something" is a very bad idea.  We aren't arguing about
> implementation choices here; we're arguing about pretty fundamental
> questions of semantics of records and labels, and the way to settle
> fundamental questions about the record system we hope to be using in
> 10 years time is not based on who has time after work for GHC hacking
> this month.
>
> --
> Chris Smith

Just because Haskell currently resolves its types through type-classes
does not mean we are forced to stop at type-classes for every aspect
of the implementation. Moreover, with our best proposal here we are
left in the peculiar position of declaring victory of resolving
through type-classes without annotations, but now requiring a new form
of type annotation for all record updates. It would make more sense
just to not go full force on the type-class resolution and instead
require a normal type annotation.

The semantics that will be exposed to users have already been largely
decide upon. If we like, we can continue to debate the fine details of
the semantics we would like to expose. The problem is that we have
been mixing the semantics with the implementation details and using it
as an excuse to hold up any implementation.