Definition of f: f = foldr (+) 0 Types: 0 :: (Num t) => t foldr (+) 0 :: Num a => [a] -> a f :: [Integer] -> Integer Please remind me, again, of the advantages of f being something different from the formula defining it. - Rex Page
page:
Definition of f: f = foldr (+) 0 Types: 0 :: (Num t) => t foldr (+) 0 :: Num a => [a] -> a f :: [Integer] -> Integer
Please remind me, again, of the advantages of f being something different from the formula defining it.
Overloaded 'constants' take a dictionary as an argument, so while you think the value might be computed only once, it make actually be recomputed each time. This can be a killer performance penalty for overloaded numeric constants. Of course, disabling this is pretty simple. -- Don
On Wed, 2008-06-11 at 20:24 -0700, Don Stewart wrote:
page:
Definition of f: f = foldr (+) 0 Types: 0 :: (Num t) => t foldr (+) 0 :: Num a => [a] -> a f :: [Integer] -> Integer
Please remind me, again, of the advantages of f being something different from the formula defining it.
Overloaded 'constants' take a dictionary as an argument, so while you think the value might be computed only once, it make actually be recomputed each time. This can be a killer performance penalty for overloaded numeric constants.
Of course, disabling this is pretty simple.
This doesn't apply to f, though --- it has a function type, so the user presumably already knows it won't be subject to updating, no? Distinguishing functions from variables by the form of declaration, rather than the type, seems somewhat questionable to me. jcc
On 6/11/08, Jonathan Cast
This doesn't apply to f, though --- it has a function type, so the user presumably already knows it won't be subject to updating, no? Distinguishing functions from variables by the form of declaration, rather than the type, seems somewhat questionable to me.
Not necessarily, contrast these two definitions: f = foldr (+) 0 f_expensive = let n = head $ drop 100000 $ fibs 1 1 in foldr (+) n With the monomorphism restriction in place, f_expensive only calculates n once. Without, it gets calculated each time f is instantiated. -- ryan
On 6/11/08, Rex Page
Please remind me, again, of the advantages of f being something different from the formula defining it.
fibs !a !b = a : fibs b (a+b) -- fibs :: Num a => a -> a -> [a] n = head $ drop 1000000 $ fibs 1 1 -- n :: Integer (due to monomorphism restriction.) 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. With the monomorphism restriction, n is a CAF and it is updated in place after it's been evaluated for the first time. Evaluating "sumns 1000" could take 1000 times as long without the monomorphism restriction, which definitely seems surprising as a user until you understand whatis going on behind the scenes with dictionary passing. If you do not want the MR, you have these options: 1) turn off explicitly (in GHC you can use -fno-monomorphism restriction) 2) add a type signature yourself (f :: Num a => [a] -> a) 3) eta-expand (f xs = foldr (+) 0 xs) -- ryan
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. 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? Yours Sincerely, Rafal Kolanski.
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
participants (5)
-
Don Stewart -
Jonathan Cast -
Rafal Kolanski -
Rex Page -
Ryan Ingram