
On Sat, Jan 14, 2012 at 10:48 AM, Brandon Allbery
On Sat, Jan 14, 2012 at 13:38, Johan Tibell
wrote: On Fri, Jan 13, 2012 at 3:52 PM, Simon Peyton-Jones
wrote: I know of no proposal that advocates only (A). It seems that we are agreed that we must make use of types to disambiguate common cases.
I will try to make the case for (A), just so it has been put on the table.
I think the point is more that, given (b), (a) is seen to be redundant.
I agree. The argument for (A) would be to try to avoid the (user*/implementation) complexity of (B). Once you have (B) you (probably) don't want (A).
Which I don't understand; seems to me that, in the context of (b), it's a way to easily provide more information to the type inferencer (which, given that (b) adds more complexity to the inferencer, looks like a way to control that complexity in practice) without hardcoding a type.
I didn't quite follow this part. * Explaining (A) is easy and can be done in a sentence or two e.g. "In addition to module names, type names can now be used to disambiguate record fields. In case of ambiguity between module names and type names, the module name is preferred and the user needs to prefix the type name with a module name to refer to the type name."