Records in Haskell

Gábor Lehel illissius at gmail.com
Sat Feb 25 23:10:28 CET 2012


On Sat, Feb 25, 2012 at 10:09 PM, Isaac Dupree
<ml at isaac.cedarswampstudios.org> wrote:
> On 02/25/2012 10:18 AM, Gábor Lehel wrote:
>>>
>>> This seems to me a much simpler approach than building the mechanism in
>>> to the language as DORF does, and it's also more general, because it isn't
>>> hard linked to the module system. Does it have any disadvantages?
>>
>>
>> I can't tell offhand whether it has any drawbacks with respect to
>> expressiveness. It seems to be a good solution to the stated problem,
>> so thank you for proposing it.
>>
>> My objection is that I'm not sure if there is ever a case where "you
>> really want things to be polymorphic over all records". There is
>> nothing (as far as I know) analogous to this kind of implicit
>> name-based polymorphism anywhere in Haskell. [...]
>
>
> True enough.  But DORF doesn't, IMHO, really solve this concern.  If you
> choose to use DORF, then your PersonalName and BrandNames will still be
> overloaded in just the way you don't want.  The only way to avoid this is a
> pretty arbitrary stylistic decision whether to use Haskell98-style
> field-name-prefixes or use new-style overloading.

Could you elaborate on this? (What's the way I don't want? What do you
mean by field-name-prefixes versus new-style overloading?) With DORF I
have control over which fields are polymorphic over which records,
very much like how I have control over which classes are polymorphic
over which types. That's what I want.

>
> Even SORF is better than, say, C++ overloading in the sense that adding
> another overload in SORF cannot cause code not to compile, nor change its
> behaviour.

Sure.

>
> Convince me otherwise.
>

Your position seems to be that unless there is some kind of grave
blocking problem with SORF, then we should go with SORF. I don't
really understand this. I think we should go with the best solution
available. I think DORF is a better solution than SORF, so we should
rather go with DORF than SORF. You've just admitted that there is no
actual use case for the behaviour of SORF, as opposed to that of DORF.
What am I missing?



More information about the Glasgow-haskell-users mailing list