GHC support for the new "record" package

[Bardur Arantsson]

On 2015-01-21 17:01, Johan Tibell wrote:
> My thoughts mostly mirror those of Adam and Edward.
[--snip--]
> 
> 3) I don't think it's a good idea to have lots of functions be polymorphic
> in the record types of their arguments. If that falls out for free (like it
> does both in ORF and Nikita's proposals) that's nice, but I think anonymous
> records should be used sparsely.
> 
> To me, anonymous records look a lot like Go's interfaces, which structural
> typing I don't think is a great idea. Go's interfaces give the appearance
> of giving you more polymorphic functions (i.e. functions with arguments of
> type { f :: T, ... }), but you have to express the required laws on these
> record fields purely in terms of comments. With type class-based
> polymorphism you're somewhat more specific and deliberate when you state
> what kind of values your functions are polymorphic over. You don't just say
> "this value must support a function f :: T" but instead "this value must
> support a function f :: T, where the behavior of f is specified by the type
> class it's defined in". I also have extensive experience of duck typing
> from Python and there I think duck typing has not played out well (somewhat
> collaborate by the fact that Python is adding base classes so it's possible
> to talk about the laws I mentioned above.)

I don't think anyone's saying that type classes are going anywhere...?!?

As a counterpoint to duck-typing-in-Python, IME *statically* checked
duck typing works just fine. It's been ages since I programmed in
O'Caml, but I cannot recall a single instance where a problem was caused
by accidentally passing the incorrect wrong duck-ish parameter. (Other
people's experience may differ, of course.)

Do you have concrete experience with Go? I'd of course be skeptical of
taking any lessons from Go in this regard due to the pervasiveness of
the "empty interface" idiom as a replacement for parametric polymorphism
-- there are usually lots of things that can match the empty interface
-- but it'd be interesting to hear, nonetheless :).

Regards,