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 _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell