Records in Haskell
illissius at gmail.com
Fri Mar 2 01:44:45 CET 2012
On Fri, Mar 2, 2012 at 1:06 AM, Ian Lynagh <igloo at earth.li> wrote:
> On Thu, Mar 01, 2012 at 11:32:27PM +0000, AntC wrote:
>> Yes-ish (leaving aside that issue). Under SORF you hve an extra behaviour:
>> - use String Kinds and your label is public-everywhere and
>> completely uncontrollable.
>> - (So someone who imports your label can't stop it getting re-exported.)
>> - This is unlike any other user-defined name in Haskell.
>> I'm not sure whether to call that extra behaviour a 'feature' (I tend more
>> to 'wart'), but it's certainly another bit of conceptual overload.
> Right, but other people would prefer the SORF behaviour to the DORF
Who and why? What's the use case?
I was trying to tease this out at another point in the thread. What
use case is there for which Haskell's normal and familiar
classes-and-instances mode of polymorphism isn't appropriate, and for
which we want to introduce this new and alien
global-implicit-name-based mode of polymorphism?
Another point which could sway in SORF's favour might be easier
implementation, but DORF actually requires less type system magic than
SORF, and also already has a working prototype implementation, so I
don't think that works, either.
Let's look at this from the other direction. The advantage of DORF
over SORF is that it handles record fields in a "hygienic" way, and
that it works with the module system, rather than around it. What
advantage does SORF have over DORF? My main complaint against DORF is
that having to write fieldLabel declarations for every field you want
to use is onerous. If that could be solved, I don't think there are
any others. (But even if it can't be, I still prefer DORF.)
More information about the Glasgow-haskell-users