On Sat, Feb 25, 2012 at 10:09 PM, Isaac Dupree
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?