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,