Implict parameters and monomorphism

[Jeffrey R. Lewis]

Simon Peyton-Jones wrote:

> | As far as what one would `expect', it's in the very nature of
> | dynamic binding that it makes the meaning of an expression
> | depend on its context. I for one would certainly not expect
> | that inlining a definition bound to such an
> | expression should preserve its meaning! Inlining changes the
> | context, so `of course' can change the meaning. So I strongly
> | 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.
>

Certainly a point well worth thinking about...

>
>
> 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.

This apparently esoteric effects analysis is called `type inference' ;-)

Oh for better programming environments where it's easy to ask questions about the types of things.

But the fun thing is, a) that analysis is way too conservative, and b) it is not even necessary in order to actually do the inlining safely.

To do the inlining, you have to be careful to observe any `with' bindings that *statically scope* over the location of the inlining, and do some dynamic variable renaming to avoid capture.

Yes, this isssue is well worth thinking about from a design decision point of view, but the situation is not as dire as it seems at first sight.

--Jeff