On Fri, Mar 2, 2012 at 1:06 AM, Ian Lynagh
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 behaviour.
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.)