[Haskell-cafe] monomorphism restriction

[Jonathan Cast]

On Sat, 2008-06-14 at 17:19 +1000, Rafal Kolanski wrote:
> Ryan Ingram wrote:
> > sumns 0 = 0
> > sumns x = sumns (x-1) + n
> > 
> > Without the monomorphism restriction, computing n is a function call;
> > it is evaluated each time it is asked for.
> 
> I'm relatively new to Haskell, and since this topic already came up, I
> was wondering if anyone could explain to me how this ties into implicit
> parameters which "escape" from their respective functions?
> 
> For instance, if I just state:
> maxLength = maxLengthParameter ?config
> without providing a type signature and then use it, I get warned that
> ?config "escapes" from maxLength and that I should provide a type
> signature or turn off the monomorphism restriction.

Which means you have to declare ?config at top level and then maxLength
has that value baked into it.

> I find implicit parameters are a really nice way to pass a configuration
> to a whole tree of functions (in this case an LZSS compressor) without
> having to explicitly add it as a parameter to every single one of the
> functions.
> 
> What are the performance implications of turning off the restriction and
> allowing implicit parameters to "escape"? Are there general performance
> implications of implicit parameters I am not aware of?

Implicit parameters get turned into real parameters under the hood.
Turning off the monomorphism restriction (e.g., giving a type signature)
just leaves the implicit parameter in place, so maxLength is a function,
not a value.  You probably /want/ maxLength to be computed from
whatever ?config happens to be in scope, so you won't mind in this case.
But Haskell wants to be sure you know that it is a function, and
laziness's automatic memoization doesn't work for it, before it will
proceed.  That's all that's going on here.

jcc