Why does GHC infer a monomorphic type here, even with MonomorphismRestriction disabled? The Next CEO of Stack OverflowResolving the type of `f = f (<*>) pure`NoMonomorphismRestriction helps preserve sharing?How can eta-reduction of a well typed function result in a type error?Can I write such polymorphic function? What language extensions do I need?GHC rewrite rule specialising a function for a type classType Inference in PatternsHow to type check recursive definitions using Algorithm W?What is the monomorphism restriction?Why are higher rank types so fragile in HaskellWhy can't GHC typecheck this function involving polymorphism and existential types?Problems With Type Inference on (^)

Opposite of a diet

Return the Closest Prime Number

What does "Its cash flow is deeply negative" mean?

How can I quit an app using Terminal?

Why is there a PLL in CPU?

What is the difference between "behavior" and "behaviour"?

How long to clear the 'suck zone' of a turbofan after start is initiated?

How to safely derail a train during transit?

What happens if you roll doubles 3 times then land on "Go to jail?"

Why is Miller's case titled R (Miller)?

What is the meaning of "rider"?

Can a single photon have an energy density?

When did Lisp start using symbols for arithmetic?

How to write the block matrix in LaTex?

Removing read access from a file

What is the point of a new vote on May's deal when the indicative votes suggest she will not win?

Why do professional authors make "consistency" mistakes? And how to avoid them?

Why does standard notation not preserve intervals (visually)

Why were Madagascar and New Zealand discovered so late?

Customer Requests (Sometimes) Drive Me Bonkers!

Fastest way to shutdown Ubuntu Mate 18.10

Grabbing quick drinks

How can I get through very long and very dry, but also very useful technical documents when learning a new tool?

How to use tikz in fbox?



Why does GHC infer a monomorphic type here, even with MonomorphismRestriction disabled?



The Next CEO of Stack OverflowResolving the type of `f = f (<*>) pure`NoMonomorphismRestriction helps preserve sharing?How can eta-reduction of a well typed function result in a type error?Can I write such polymorphic function? What language extensions do I need?GHC rewrite rule specialising a function for a type classType Inference in PatternsHow to type check recursive definitions using Algorithm W?What is the monomorphism restriction?Why are higher rank types so fragile in HaskellWhy can't GHC typecheck this function involving polymorphism and existential types?Problems With Type Inference on (^)










13















This was prompted by Resolving the type of `f = f (<*>) pure`, which discusses a more complicated example, but this one works too.



The following definition compiles without problem:



w :: Integral a => a
w = fromInteger w


...Of course it doesn't work runtime-wise, but that's beside the question. The point is that the definition of w itself uses a specialised version of w :: Integer. Clearly that is a suitable instantiation, and therefore typechecks.



However, if we remove the signature, then GHC infers not the above type, but only the concrete one:



w' = fromInteger w'


GHCi> :t w
w :: Integral a => a
GHCi> :t w'
w' :: Integer


Well, when I saw this, I was fairly sure this was the monomorphism restriction at work. It's well known that also e.g.



i = 3


GHCi> :t i
i :: Integer


although i :: Num p => p would be perfectly possible. And indeed, i :: Num p => p is inferred if -XNoMonomorphismRestriction is active, i.e. if the monomorphism restriction is disabled.



However, in case of w' only the type Integer is inferred even when the monomorphism restriction is disabled.



To count out that this has something to do with defaulting:



fromFloat :: RealFrac a => Float -> a
q :: RealFrac a => a
q = fromFloat q
q' = fromFloat q'


GHCi> :t q
q :: RealFrac a => a
GHCi> :t q'
q' :: Float


Why is the polymorphic type not inferred?










share|improve this question
























  • Doesn't the monomorphism restriction apply only to simple bindings anyways (and w' = fromInteger w', being recursive, is not simple)?

    – Alec
    4 hours ago











  • @Alec possible, but still – why does something like the monomorphism restriction seem to kick in here?

    – leftaroundabout
    4 hours ago











  • I'm probably being dense and missing something here, but fromInteger has type (Num a) => Integer -> a, and since w' is used as the input to fromInteger, doesn't that mean Integer is the only possible type for it? Indeed I'm rather surprised that the version with the polymorphic type signature compiles. (So as I said, probably missing something.)

    – Robin Zigmond
    4 hours ago











  • @RobinZigmond Integer is certainly the only possible monomorphic type for w', but as w demonstrates a polymorphic type is perfectly fine as well. After all, a polymorphic type can be instantiated to a monomorphic one, provided it fulfills the constraints.

    – leftaroundabout
    4 hours ago
















13















This was prompted by Resolving the type of `f = f (<*>) pure`, which discusses a more complicated example, but this one works too.



The following definition compiles without problem:



w :: Integral a => a
w = fromInteger w


...Of course it doesn't work runtime-wise, but that's beside the question. The point is that the definition of w itself uses a specialised version of w :: Integer. Clearly that is a suitable instantiation, and therefore typechecks.



However, if we remove the signature, then GHC infers not the above type, but only the concrete one:



w' = fromInteger w'


GHCi> :t w
w :: Integral a => a
GHCi> :t w'
w' :: Integer


Well, when I saw this, I was fairly sure this was the monomorphism restriction at work. It's well known that also e.g.



i = 3


GHCi> :t i
i :: Integer


although i :: Num p => p would be perfectly possible. And indeed, i :: Num p => p is inferred if -XNoMonomorphismRestriction is active, i.e. if the monomorphism restriction is disabled.



However, in case of w' only the type Integer is inferred even when the monomorphism restriction is disabled.



To count out that this has something to do with defaulting:



fromFloat :: RealFrac a => Float -> a
q :: RealFrac a => a
q = fromFloat q
q' = fromFloat q'


GHCi> :t q
q :: RealFrac a => a
GHCi> :t q'
q' :: Float


Why is the polymorphic type not inferred?










share|improve this question
























  • Doesn't the monomorphism restriction apply only to simple bindings anyways (and w' = fromInteger w', being recursive, is not simple)?

    – Alec
    4 hours ago











  • @Alec possible, but still – why does something like the monomorphism restriction seem to kick in here?

    – leftaroundabout
    4 hours ago











  • I'm probably being dense and missing something here, but fromInteger has type (Num a) => Integer -> a, and since w' is used as the input to fromInteger, doesn't that mean Integer is the only possible type for it? Indeed I'm rather surprised that the version with the polymorphic type signature compiles. (So as I said, probably missing something.)

    – Robin Zigmond
    4 hours ago











  • @RobinZigmond Integer is certainly the only possible monomorphic type for w', but as w demonstrates a polymorphic type is perfectly fine as well. After all, a polymorphic type can be instantiated to a monomorphic one, provided it fulfills the constraints.

    – leftaroundabout
    4 hours ago














13












13








13


2






This was prompted by Resolving the type of `f = f (<*>) pure`, which discusses a more complicated example, but this one works too.



The following definition compiles without problem:



w :: Integral a => a
w = fromInteger w


...Of course it doesn't work runtime-wise, but that's beside the question. The point is that the definition of w itself uses a specialised version of w :: Integer. Clearly that is a suitable instantiation, and therefore typechecks.



However, if we remove the signature, then GHC infers not the above type, but only the concrete one:



w' = fromInteger w'


GHCi> :t w
w :: Integral a => a
GHCi> :t w'
w' :: Integer


Well, when I saw this, I was fairly sure this was the monomorphism restriction at work. It's well known that also e.g.



i = 3


GHCi> :t i
i :: Integer


although i :: Num p => p would be perfectly possible. And indeed, i :: Num p => p is inferred if -XNoMonomorphismRestriction is active, i.e. if the monomorphism restriction is disabled.



However, in case of w' only the type Integer is inferred even when the monomorphism restriction is disabled.



To count out that this has something to do with defaulting:



fromFloat :: RealFrac a => Float -> a
q :: RealFrac a => a
q = fromFloat q
q' = fromFloat q'


GHCi> :t q
q :: RealFrac a => a
GHCi> :t q'
q' :: Float


Why is the polymorphic type not inferred?










share|improve this question
















This was prompted by Resolving the type of `f = f (<*>) pure`, which discusses a more complicated example, but this one works too.



The following definition compiles without problem:



w :: Integral a => a
w = fromInteger w


...Of course it doesn't work runtime-wise, but that's beside the question. The point is that the definition of w itself uses a specialised version of w :: Integer. Clearly that is a suitable instantiation, and therefore typechecks.



However, if we remove the signature, then GHC infers not the above type, but only the concrete one:



w' = fromInteger w'


GHCi> :t w
w :: Integral a => a
GHCi> :t w'
w' :: Integer


Well, when I saw this, I was fairly sure this was the monomorphism restriction at work. It's well known that also e.g.



i = 3


GHCi> :t i
i :: Integer


although i :: Num p => p would be perfectly possible. And indeed, i :: Num p => p is inferred if -XNoMonomorphismRestriction is active, i.e. if the monomorphism restriction is disabled.



However, in case of w' only the type Integer is inferred even when the monomorphism restriction is disabled.



To count out that this has something to do with defaulting:



fromFloat :: RealFrac a => Float -> a
q :: RealFrac a => a
q = fromFloat q
q' = fromFloat q'


GHCi> :t q
q :: RealFrac a => a
GHCi> :t q'
q' :: Float


Why is the polymorphic type not inferred?







haskell recursion type-inference parametric-polymorphism






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 2 hours ago







leftaroundabout

















asked 4 hours ago









leftaroundaboutleftaroundabout

80.1k3119237




80.1k3119237












  • Doesn't the monomorphism restriction apply only to simple bindings anyways (and w' = fromInteger w', being recursive, is not simple)?

    – Alec
    4 hours ago











  • @Alec possible, but still – why does something like the monomorphism restriction seem to kick in here?

    – leftaroundabout
    4 hours ago











  • I'm probably being dense and missing something here, but fromInteger has type (Num a) => Integer -> a, and since w' is used as the input to fromInteger, doesn't that mean Integer is the only possible type for it? Indeed I'm rather surprised that the version with the polymorphic type signature compiles. (So as I said, probably missing something.)

    – Robin Zigmond
    4 hours ago











  • @RobinZigmond Integer is certainly the only possible monomorphic type for w', but as w demonstrates a polymorphic type is perfectly fine as well. After all, a polymorphic type can be instantiated to a monomorphic one, provided it fulfills the constraints.

    – leftaroundabout
    4 hours ago


















  • Doesn't the monomorphism restriction apply only to simple bindings anyways (and w' = fromInteger w', being recursive, is not simple)?

    – Alec
    4 hours ago











  • @Alec possible, but still – why does something like the monomorphism restriction seem to kick in here?

    – leftaroundabout
    4 hours ago











  • I'm probably being dense and missing something here, but fromInteger has type (Num a) => Integer -> a, and since w' is used as the input to fromInteger, doesn't that mean Integer is the only possible type for it? Indeed I'm rather surprised that the version with the polymorphic type signature compiles. (So as I said, probably missing something.)

    – Robin Zigmond
    4 hours ago











  • @RobinZigmond Integer is certainly the only possible monomorphic type for w', but as w demonstrates a polymorphic type is perfectly fine as well. After all, a polymorphic type can be instantiated to a monomorphic one, provided it fulfills the constraints.

    – leftaroundabout
    4 hours ago

















Doesn't the monomorphism restriction apply only to simple bindings anyways (and w' = fromInteger w', being recursive, is not simple)?

– Alec
4 hours ago





Doesn't the monomorphism restriction apply only to simple bindings anyways (and w' = fromInteger w', being recursive, is not simple)?

– Alec
4 hours ago













@Alec possible, but still – why does something like the monomorphism restriction seem to kick in here?

– leftaroundabout
4 hours ago





@Alec possible, but still – why does something like the monomorphism restriction seem to kick in here?

– leftaroundabout
4 hours ago













I'm probably being dense and missing something here, but fromInteger has type (Num a) => Integer -> a, and since w' is used as the input to fromInteger, doesn't that mean Integer is the only possible type for it? Indeed I'm rather surprised that the version with the polymorphic type signature compiles. (So as I said, probably missing something.)

– Robin Zigmond
4 hours ago





I'm probably being dense and missing something here, but fromInteger has type (Num a) => Integer -> a, and since w' is used as the input to fromInteger, doesn't that mean Integer is the only possible type for it? Indeed I'm rather surprised that the version with the polymorphic type signature compiles. (So as I said, probably missing something.)

– Robin Zigmond
4 hours ago













@RobinZigmond Integer is certainly the only possible monomorphic type for w', but as w demonstrates a polymorphic type is perfectly fine as well. After all, a polymorphic type can be instantiated to a monomorphic one, provided it fulfills the constraints.

– leftaroundabout
4 hours ago






@RobinZigmond Integer is certainly the only possible monomorphic type for w', but as w demonstrates a polymorphic type is perfectly fine as well. After all, a polymorphic type can be instantiated to a monomorphic one, provided it fulfills the constraints.

– leftaroundabout
4 hours ago













1 Answer
1






active

oldest

votes


















13














Polymorphic recursion (where a function calls itself at a different type than the one at which it was called) always requires a type signature. The full explanation is in Section 4.4.1 of the Haskell 2010 Report:




If a variable f is defined without providing a corresponding type signature declaration, then each use of f outside its own declaration group (see Section 4.5) is treated as having the corresponding inferred, or principal type. However, to ensure that type inference is still possible, the defining occurrence, and all uses of f within its declaration group must have the same monomorphic type (from which the principal type is obtained by generalization, as described in Section 4.5.2).




The same section later presents an example of polymorphic recursion supported by a type signature.



My understanding is that unaided type inference is generally undecidable in the presence of polymorphic recursion, so Haskell doesn't even try.



In this case, the type checker starts with



w :: a


where a is a meta-variable. Since fromInteger is called with w as an argument within its own declaration (and therefore within its declaration group), the type checker unifies a with Integer. There are no variables left to generalize.






share|improve this answer




















  • 1





    My bachelor was about a simple type inferencer for a subset of Haskell including typeclasses & polymorphic recursion. A very simple approach is to limit the depth of the polymorphic recursion up to k depth. Most useful cases of polymorphic recursion can be inferred with a very low depth bound (like k=1 or k=2). Anyway Haskell type inference is already undecidable so that's not the only reason why it's not allowed. An other reason is probably performance, it surely makes type inference O(k·f(n)) instead of O(f(n)) since you may need to do all over again for k times.

    – Bakuriu
    3 hours ago






  • 1





    @Bakuriu, I am pretty sure that Haskell 2010 without polymorphic recursion has full type inference--it's basically Hindley-Milner at that point, plus type classes and defaulting. Do you have a reference saying otherwise? As for some limited recursion depth: that sounds like a potentially useful extension, but it has a very different flavor from what the Haskell Report tends to do. I would find such a feature most useful for discovering the right type signatures for polymorphic recursive code.

    – dfeuer
    2 hours ago












  • Yes, but I think all extensions to the type systems on top of Haskell2010 make type inference undecidable. Note that for example Type families are "artificially" limited to avoid undecidable instances by forbidding certain well-formed programs by default, so allowing a "k-recursive" polymorphic recursion would not be very different from that case, IMHO.

    – Bakuriu
    1 hour ago











Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55402733%2fwhy-does-ghc-infer-a-monomorphic-type-here-even-with-monomorphismrestriction-di%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









13














Polymorphic recursion (where a function calls itself at a different type than the one at which it was called) always requires a type signature. The full explanation is in Section 4.4.1 of the Haskell 2010 Report:




If a variable f is defined without providing a corresponding type signature declaration, then each use of f outside its own declaration group (see Section 4.5) is treated as having the corresponding inferred, or principal type. However, to ensure that type inference is still possible, the defining occurrence, and all uses of f within its declaration group must have the same monomorphic type (from which the principal type is obtained by generalization, as described in Section 4.5.2).




The same section later presents an example of polymorphic recursion supported by a type signature.



My understanding is that unaided type inference is generally undecidable in the presence of polymorphic recursion, so Haskell doesn't even try.



In this case, the type checker starts with



w :: a


where a is a meta-variable. Since fromInteger is called with w as an argument within its own declaration (and therefore within its declaration group), the type checker unifies a with Integer. There are no variables left to generalize.






share|improve this answer




















  • 1





    My bachelor was about a simple type inferencer for a subset of Haskell including typeclasses & polymorphic recursion. A very simple approach is to limit the depth of the polymorphic recursion up to k depth. Most useful cases of polymorphic recursion can be inferred with a very low depth bound (like k=1 or k=2). Anyway Haskell type inference is already undecidable so that's not the only reason why it's not allowed. An other reason is probably performance, it surely makes type inference O(k·f(n)) instead of O(f(n)) since you may need to do all over again for k times.

    – Bakuriu
    3 hours ago






  • 1





    @Bakuriu, I am pretty sure that Haskell 2010 without polymorphic recursion has full type inference--it's basically Hindley-Milner at that point, plus type classes and defaulting. Do you have a reference saying otherwise? As for some limited recursion depth: that sounds like a potentially useful extension, but it has a very different flavor from what the Haskell Report tends to do. I would find such a feature most useful for discovering the right type signatures for polymorphic recursive code.

    – dfeuer
    2 hours ago












  • Yes, but I think all extensions to the type systems on top of Haskell2010 make type inference undecidable. Note that for example Type families are "artificially" limited to avoid undecidable instances by forbidding certain well-formed programs by default, so allowing a "k-recursive" polymorphic recursion would not be very different from that case, IMHO.

    – Bakuriu
    1 hour ago















13














Polymorphic recursion (where a function calls itself at a different type than the one at which it was called) always requires a type signature. The full explanation is in Section 4.4.1 of the Haskell 2010 Report:




If a variable f is defined without providing a corresponding type signature declaration, then each use of f outside its own declaration group (see Section 4.5) is treated as having the corresponding inferred, or principal type. However, to ensure that type inference is still possible, the defining occurrence, and all uses of f within its declaration group must have the same monomorphic type (from which the principal type is obtained by generalization, as described in Section 4.5.2).




The same section later presents an example of polymorphic recursion supported by a type signature.



My understanding is that unaided type inference is generally undecidable in the presence of polymorphic recursion, so Haskell doesn't even try.



In this case, the type checker starts with



w :: a


where a is a meta-variable. Since fromInteger is called with w as an argument within its own declaration (and therefore within its declaration group), the type checker unifies a with Integer. There are no variables left to generalize.






share|improve this answer




















  • 1





    My bachelor was about a simple type inferencer for a subset of Haskell including typeclasses & polymorphic recursion. A very simple approach is to limit the depth of the polymorphic recursion up to k depth. Most useful cases of polymorphic recursion can be inferred with a very low depth bound (like k=1 or k=2). Anyway Haskell type inference is already undecidable so that's not the only reason why it's not allowed. An other reason is probably performance, it surely makes type inference O(k·f(n)) instead of O(f(n)) since you may need to do all over again for k times.

    – Bakuriu
    3 hours ago






  • 1





    @Bakuriu, I am pretty sure that Haskell 2010 without polymorphic recursion has full type inference--it's basically Hindley-Milner at that point, plus type classes and defaulting. Do you have a reference saying otherwise? As for some limited recursion depth: that sounds like a potentially useful extension, but it has a very different flavor from what the Haskell Report tends to do. I would find such a feature most useful for discovering the right type signatures for polymorphic recursive code.

    – dfeuer
    2 hours ago












  • Yes, but I think all extensions to the type systems on top of Haskell2010 make type inference undecidable. Note that for example Type families are "artificially" limited to avoid undecidable instances by forbidding certain well-formed programs by default, so allowing a "k-recursive" polymorphic recursion would not be very different from that case, IMHO.

    – Bakuriu
    1 hour ago













13












13








13







Polymorphic recursion (where a function calls itself at a different type than the one at which it was called) always requires a type signature. The full explanation is in Section 4.4.1 of the Haskell 2010 Report:




If a variable f is defined without providing a corresponding type signature declaration, then each use of f outside its own declaration group (see Section 4.5) is treated as having the corresponding inferred, or principal type. However, to ensure that type inference is still possible, the defining occurrence, and all uses of f within its declaration group must have the same monomorphic type (from which the principal type is obtained by generalization, as described in Section 4.5.2).




The same section later presents an example of polymorphic recursion supported by a type signature.



My understanding is that unaided type inference is generally undecidable in the presence of polymorphic recursion, so Haskell doesn't even try.



In this case, the type checker starts with



w :: a


where a is a meta-variable. Since fromInteger is called with w as an argument within its own declaration (and therefore within its declaration group), the type checker unifies a with Integer. There are no variables left to generalize.






share|improve this answer















Polymorphic recursion (where a function calls itself at a different type than the one at which it was called) always requires a type signature. The full explanation is in Section 4.4.1 of the Haskell 2010 Report:




If a variable f is defined without providing a corresponding type signature declaration, then each use of f outside its own declaration group (see Section 4.5) is treated as having the corresponding inferred, or principal type. However, to ensure that type inference is still possible, the defining occurrence, and all uses of f within its declaration group must have the same monomorphic type (from which the principal type is obtained by generalization, as described in Section 4.5.2).




The same section later presents an example of polymorphic recursion supported by a type signature.



My understanding is that unaided type inference is generally undecidable in the presence of polymorphic recursion, so Haskell doesn't even try.



In this case, the type checker starts with



w :: a


where a is a meta-variable. Since fromInteger is called with w as an argument within its own declaration (and therefore within its declaration group), the type checker unifies a with Integer. There are no variables left to generalize.







share|improve this answer














share|improve this answer



share|improve this answer








edited 2 hours ago

























answered 4 hours ago









dfeuerdfeuer

33.5k349133




33.5k349133







  • 1





    My bachelor was about a simple type inferencer for a subset of Haskell including typeclasses & polymorphic recursion. A very simple approach is to limit the depth of the polymorphic recursion up to k depth. Most useful cases of polymorphic recursion can be inferred with a very low depth bound (like k=1 or k=2). Anyway Haskell type inference is already undecidable so that's not the only reason why it's not allowed. An other reason is probably performance, it surely makes type inference O(k·f(n)) instead of O(f(n)) since you may need to do all over again for k times.

    – Bakuriu
    3 hours ago






  • 1





    @Bakuriu, I am pretty sure that Haskell 2010 without polymorphic recursion has full type inference--it's basically Hindley-Milner at that point, plus type classes and defaulting. Do you have a reference saying otherwise? As for some limited recursion depth: that sounds like a potentially useful extension, but it has a very different flavor from what the Haskell Report tends to do. I would find such a feature most useful for discovering the right type signatures for polymorphic recursive code.

    – dfeuer
    2 hours ago












  • Yes, but I think all extensions to the type systems on top of Haskell2010 make type inference undecidable. Note that for example Type families are "artificially" limited to avoid undecidable instances by forbidding certain well-formed programs by default, so allowing a "k-recursive" polymorphic recursion would not be very different from that case, IMHO.

    – Bakuriu
    1 hour ago












  • 1





    My bachelor was about a simple type inferencer for a subset of Haskell including typeclasses & polymorphic recursion. A very simple approach is to limit the depth of the polymorphic recursion up to k depth. Most useful cases of polymorphic recursion can be inferred with a very low depth bound (like k=1 or k=2). Anyway Haskell type inference is already undecidable so that's not the only reason why it's not allowed. An other reason is probably performance, it surely makes type inference O(k·f(n)) instead of O(f(n)) since you may need to do all over again for k times.

    – Bakuriu
    3 hours ago






  • 1





    @Bakuriu, I am pretty sure that Haskell 2010 without polymorphic recursion has full type inference--it's basically Hindley-Milner at that point, plus type classes and defaulting. Do you have a reference saying otherwise? As for some limited recursion depth: that sounds like a potentially useful extension, but it has a very different flavor from what the Haskell Report tends to do. I would find such a feature most useful for discovering the right type signatures for polymorphic recursive code.

    – dfeuer
    2 hours ago












  • Yes, but I think all extensions to the type systems on top of Haskell2010 make type inference undecidable. Note that for example Type families are "artificially" limited to avoid undecidable instances by forbidding certain well-formed programs by default, so allowing a "k-recursive" polymorphic recursion would not be very different from that case, IMHO.

    – Bakuriu
    1 hour ago







1




1





My bachelor was about a simple type inferencer for a subset of Haskell including typeclasses & polymorphic recursion. A very simple approach is to limit the depth of the polymorphic recursion up to k depth. Most useful cases of polymorphic recursion can be inferred with a very low depth bound (like k=1 or k=2). Anyway Haskell type inference is already undecidable so that's not the only reason why it's not allowed. An other reason is probably performance, it surely makes type inference O(k·f(n)) instead of O(f(n)) since you may need to do all over again for k times.

– Bakuriu
3 hours ago





My bachelor was about a simple type inferencer for a subset of Haskell including typeclasses & polymorphic recursion. A very simple approach is to limit the depth of the polymorphic recursion up to k depth. Most useful cases of polymorphic recursion can be inferred with a very low depth bound (like k=1 or k=2). Anyway Haskell type inference is already undecidable so that's not the only reason why it's not allowed. An other reason is probably performance, it surely makes type inference O(k·f(n)) instead of O(f(n)) since you may need to do all over again for k times.

– Bakuriu
3 hours ago




1




1





@Bakuriu, I am pretty sure that Haskell 2010 without polymorphic recursion has full type inference--it's basically Hindley-Milner at that point, plus type classes and defaulting. Do you have a reference saying otherwise? As for some limited recursion depth: that sounds like a potentially useful extension, but it has a very different flavor from what the Haskell Report tends to do. I would find such a feature most useful for discovering the right type signatures for polymorphic recursive code.

– dfeuer
2 hours ago






@Bakuriu, I am pretty sure that Haskell 2010 without polymorphic recursion has full type inference--it's basically Hindley-Milner at that point, plus type classes and defaulting. Do you have a reference saying otherwise? As for some limited recursion depth: that sounds like a potentially useful extension, but it has a very different flavor from what the Haskell Report tends to do. I would find such a feature most useful for discovering the right type signatures for polymorphic recursive code.

– dfeuer
2 hours ago














Yes, but I think all extensions to the type systems on top of Haskell2010 make type inference undecidable. Note that for example Type families are "artificially" limited to avoid undecidable instances by forbidding certain well-formed programs by default, so allowing a "k-recursive" polymorphic recursion would not be very different from that case, IMHO.

– Bakuriu
1 hour ago





Yes, but I think all extensions to the type systems on top of Haskell2010 make type inference undecidable. Note that for example Type families are "artificially" limited to avoid undecidable instances by forbidding certain well-formed programs by default, so allowing a "k-recursive" polymorphic recursion would not be very different from that case, IMHO.

– Bakuriu
1 hour ago



















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55402733%2fwhy-does-ghc-infer-a-monomorphic-type-here-even-with-monomorphismrestriction-di%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Благоевград Съдържание География | История | Население | Политика | Икономика и инфрастуктура | Здравеопазване | Образование и наука | Култура и забавления | Забележителности | Личности | Литература | Външни препратки | Бележки | Навигация42°01′18.99″ с. ш. 23°05′51″ и. д. / 42.021944° с. ш. 23.0975° и. д.*БлагоевградразширитередактиранеОфициален уебсайт на община БлагоевградНовинарски портал на Благоевград – blagoevgrad.euСайтове за БлагоевградНационален статистически институтdariknews.bgГригоровичъ, Викторъ. „Очеркъ путешествія по Европейской Турціи“. Москва, 1877.Стрезов, Георги. Два санджака от Източна Македония. Периодично списание на Българското книжовно дружество в Средец, кн. XXXVII и XXXVIII, 1891, стр. 18 – 19.Македония. Етнография и статистикаГаджанов, Димитър Г. Мюсюлманското население в Новоосвободените земи, в: Научна експедиция в Македония и Поморавието 1916, Военноиздателски комплекс „Св. Георги Победоносец“, Университетско издателство „Св. Климент Охридски“, София, 1993, стр. 244.паметник на незнайния четник&cd=18&hl=en&ct=clnk&client=firefox-a „История на днешен Благоевград“, взето от www.museumblg.com на 16 март 2010 г.„Справка за населението на град Благоевград, община Благоевград, област Благоевград, НСИ“„The population of all towns and villages in Blagoevgrad Province with 50 inhabitants or more according to census results and latest official estimates“„Ethnic composition, all places: 2011 census“История на Неврокопска епархия.Национален статистически институтМюсюлманско изповедание. Главно мюфтийствоНационален публичен регистър на храмовете в БългарияМюсюлманско изповедание. Главно мюфтийствоwww.dnes.bg Джамията в Благоевград не била паленаwww.sesc-bg.orgСписък на побратимени градовеТехническо побратимяванеГУМ грейва в цветовете на нощен Лас Вегас под името „Largo“, „МОЛ Благоевград“..., в. „Струма“grabo.bgwww.cinemaxbg.comррр4238731-067cad53a-0546-417b-a3d3-51e49b1d2232147736077147736077

What is the best defense strategy for Survival in Grand Theft Auto Online?What is JP used for in Grand Theft Auto Online?How do I setup a Crew HQ in Grand Theft Auto Online?How does stealth work in Grand Theft Auto Online?Is it possible to own more than 10 cars in Grand Theft Auto online?Where to find truck/trailers in Grand Theft Auto OnlineWhat are some of the best missions to do on Grand Theft Auto 5 onlineFastest Car in Grand Theft Auto V PCHow to setup a Crew vs Crew online session in Grand Theft Auto Online?Grand theft auto 5 crossplayingRestart Grand Theft Auto V Online?

How does Billy Russo acquire his 'Jigsaw' mask? Unicorn Meta Zoo #1: Why another podcast? Announcing the arrival of Valued Associate #679: Cesar Manara Favourite questions and answers from the 1st quarter of 2019Why does Bane wear the mask?Why does Kylo Ren wear a mask?Why did Captain America remove his mask while fighting Batroc the Leaper?How did the OA acquire her wisdom?Is Billy Breckenridge gay?How does Adrian Toomes hide his earnings from the IRS?What is the state of affairs on Nootka Sound by the end of season 1?How did Tia Dalma acquire Captain Barbossa's body?How is one “Deemed Worthy”, to acquire the Greatsword “Dawn”?How did Karen acquire the handgun?