Implict parameters and monomorphism

[Simon Peyton-Jones]

| As far as what one would `expect', it's in the very nature of=20
| dynamic binding that it makes the meaning of an expression=20
| depend on its context. I for one would certainly not expect=20
| that inlining a definition bound to such an=20
| expression should preserve its meaning! Inlining changes the=20
| context, so `of course' can change the meaning. So I strongly=20
| prefer (B)!

John: just to check, you do realise that (B) means

a) That adding a type signature can change the dynamic semantics
    of the program.  This would be the first and only occurrence of
    such behaviour.

    (For ordinary type classes, the monomorphism restriction will
    reject some programs that would otherwise be well typed;=20
    for implicit parameters, (B) will accept the program but
    with --- potentially ---- a different meaning.)


b) That whether or not a definition is unconditionally inlinable
    at the source-language level cannot be determined by looking
    at the expression.  You have to do something rather like effects
    analysis: look to see if it calls any function (transitively) that
uses
    an implicit parameter.


These seem like pretty dire properties.  Are you sure it's worth it?

Simon