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