A simpler ORF

[Roman Cheplyaka]

> It's not possible in your proposal. One could even argue that it was a
> bad idea in the first place, as it may lead to partiality.

On a second thought, isn't your update partial as well?

In

  C { e | f1 = e1, f2 = e2 }

what happens if e's constructor is not in fact C?

This makes me somewhat uncomfortable.

Roman


On 29/01/15 10:14, Roman Cheplyaka wrote:
> 1. I *love* the idea of not generating selector functions. It's worth
> implementing it as a separate extension regardless of this proposal's fate.
> 
> 2. In H98, it is possible to do constructor-agnostic updates:
> 
>   data T = A { n :: Int } | B { n :: Int }
>   f :: T -> T
>   f x = x { n = 2 }
> 
> It's not possible in your proposal. One could even argue that it was a
> bad idea in the first place, as it may lead to partiality.
> 
> 3. Now that fields are not tied to selectors, do we need a separate
> mechanism/set of rules for exporting fields?
> 
> Roman
> 
> On 29/01/15 07:15, Iavor Diatchki wrote:
>> Hello,
>>
>> I've been following the various discussions about changes to Haskell's
>> record system, and I find that most of the current proposals are fairly
>> complex, especially for the benefit they provide.
>>
>> I use Haskell records a lot, and I've been wondering if there might be a
>> simpler alternative, one that:
>>   1. will allow us to reuse field names across records
>>   2. does not require any fancy types
>>   3. it will not preclude continued research on "the right" way to get
>> more type-based record resolution.
>>
>> Based on designs I've seen in the past, my experience with Haskell
>> records, and discussions with colleagues, I put together a document
>> describing a potential design that, I think, satisfies goals 1 to 3:
>>
>> https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Simple
>>
>> I think the proposal should be fairly simple to implement, and I'd be
>> willing to do it, if there is enough support from the community.
>>
>> Let me know what you think!
>>
>> -Iavor
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>