The madness of implicit parameters: cured?

[Ben Rudiak-Gould]

Trouble for implicit parameter defaults: consider

	?foo = 0

	let x = ?foo in
	  (x + ?foo) { ?foo = 1 }

This evaluates to 1 when the monomorphism restriction is turned on, and 2
when it's off. This is no worse than the current behavior of implicit
parameters even without defaults, but I still think that it should be
forbidden because it's very important that the monomorphism restriction be
a restriction only.

This doesn't apply to defaults for explicit named parameters, but they
have their own problems: consider

	#foo = 1

	f :: (#foo :: a) => a
	f #foo = g
	g #foo = #foo

	main = print ( f { #foo = 2 } :: Int )

This prints 2 if the type signature for f is included, and 1 if it's
omitted. I think this can be solved by forbidding any name with a default
from appearing more than once in any function type.

Also, reading "Type classes: exploring the design space"
(http://research.microsoft.com/users/simonpj/Papers/type-class-design-space/)
has given me serious doubts about explicit dictionary passing. It seems as
though it would make program behavior too dependent on otherwise minor
changes to the type inference rules.

Even without explicit dictionary passing I think you would still be able
to write

	sort :: (#comparator :: a -> a -> Ordering) => [a] -> [a]

	#comparator = compare


-- Ben