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
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
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 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
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
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
[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
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
Re: [Haskell-cafe] Monomorphism restriction
Hi This should clear up some of the questions: http://haskell.org/hawiki/MonomorphismRestriction Note to others (esp Cale): does this page not appear on the new wiki? Thanks Neil On 1/23/07, Marco Túlio Gontijo e Silva <[EMAIL PROTECTED]> wrote: 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 ___ 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