Re: [Haskell-cafe] monomorphism restriction
On 6/11/08, Jonathan Cast [EMAIL PROTECTED] wrote: 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 10 $ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monomorphism restriction
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monomorphism restriction
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monomorphism restriction
On 6/11/08, Rex Page [EMAIL PROTECTED] wrote: 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 100 $ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monomorphism restriction
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] monomorphism restriction
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monomorphism restriction
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monomorphism restriction
Neil Mitchell wrote: http://haskell.org/hawiki/MonomorphismRestriction Note to others (esp Cale): does this page not appear on the new wiki? I did a very rough quick conversion: http://www.haskell.org/haskellwiki/MonomorphismRestriction The old wiki is locked, for obvious reasons. But wouldn't this be easier if the source text of the old wiki pages were available? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Monomorphism restriction
Hello, I talked for a while with bd_ about this on #haskell, and I think maybe I'm just being silly. But I can't get why: lambda = \x - length (show x) or dot = length . show is different from pre x = length $ show x I read about monomorphism restriction on the haskell 98 report, but I couldn't find where it explains the reason why these different versions influence on type infer. Thanks for any help. -- malebria Marco Túlio Gontijo e Silva Correio (MSN): [EMAIL PROTECTED] Jabber (GTalk): [EMAIL PROTECTED] Ekiga: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] [EMAIL PROTECTED] Skype: marcotmarcot Telefone: 33346720 Celular: 98116720 Endereço: Rua Paula Cândido, 257/201 Gutierrez 30430-260 Belo Horizonte/MG Brasil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
