How does the Haskell compiler emit code for `(==) (fromInteger 0) (fromInteger 0)` when the intermediary...












3















My question is related to type class instance deduction in the presence of ambiguously typed intermediary values



Prelude> :t fromInteger 0
fromInteger 0 :: Num a => a
Prelude> :t (==)
(==) :: Eq a => a -> a -> Bool
Prelude> :t (==) (fromInteger 0)
(==) (fromInteger 0) :: (Eq a, Num a) => a -> Bool
Prelude> :t (==) (fromInteger 0) (fromInteger 1)
(==) (fromInteger 0) (fromInteger 1) :: Bool
Prelude> (==) (fromInteger 0) (fromInteger 1)
False


Magic! It's unclear how or whether a was made concrete, yet the code ran successfully!



According to the type inference rules, the type variables denoted by a above unify successfully with each other because they have compatible Num a constraints across the different terms. However, a never binds to a concrete type. My question is, at runtime, which instance dictionary (or specialization, whatever) is used for the (==) function?



Is this a case where Haskell relies on a simple binary memcmp style comparison? Or perhaps it just picks the first instance in its list of Num instances since in theory it shouldn't matter (as long as the algebraic properties of that instance are implemented correctly...)










share|improve this question





























    3















    My question is related to type class instance deduction in the presence of ambiguously typed intermediary values



    Prelude> :t fromInteger 0
    fromInteger 0 :: Num a => a
    Prelude> :t (==)
    (==) :: Eq a => a -> a -> Bool
    Prelude> :t (==) (fromInteger 0)
    (==) (fromInteger 0) :: (Eq a, Num a) => a -> Bool
    Prelude> :t (==) (fromInteger 0) (fromInteger 1)
    (==) (fromInteger 0) (fromInteger 1) :: Bool
    Prelude> (==) (fromInteger 0) (fromInteger 1)
    False


    Magic! It's unclear how or whether a was made concrete, yet the code ran successfully!



    According to the type inference rules, the type variables denoted by a above unify successfully with each other because they have compatible Num a constraints across the different terms. However, a never binds to a concrete type. My question is, at runtime, which instance dictionary (or specialization, whatever) is used for the (==) function?



    Is this a case where Haskell relies on a simple binary memcmp style comparison? Or perhaps it just picks the first instance in its list of Num instances since in theory it shouldn't matter (as long as the algebraic properties of that instance are implemented correctly...)










    share|improve this question



























      3












      3








      3








      My question is related to type class instance deduction in the presence of ambiguously typed intermediary values



      Prelude> :t fromInteger 0
      fromInteger 0 :: Num a => a
      Prelude> :t (==)
      (==) :: Eq a => a -> a -> Bool
      Prelude> :t (==) (fromInteger 0)
      (==) (fromInteger 0) :: (Eq a, Num a) => a -> Bool
      Prelude> :t (==) (fromInteger 0) (fromInteger 1)
      (==) (fromInteger 0) (fromInteger 1) :: Bool
      Prelude> (==) (fromInteger 0) (fromInteger 1)
      False


      Magic! It's unclear how or whether a was made concrete, yet the code ran successfully!



      According to the type inference rules, the type variables denoted by a above unify successfully with each other because they have compatible Num a constraints across the different terms. However, a never binds to a concrete type. My question is, at runtime, which instance dictionary (or specialization, whatever) is used for the (==) function?



      Is this a case where Haskell relies on a simple binary memcmp style comparison? Or perhaps it just picks the first instance in its list of Num instances since in theory it shouldn't matter (as long as the algebraic properties of that instance are implemented correctly...)










      share|improve this question
















      My question is related to type class instance deduction in the presence of ambiguously typed intermediary values



      Prelude> :t fromInteger 0
      fromInteger 0 :: Num a => a
      Prelude> :t (==)
      (==) :: Eq a => a -> a -> Bool
      Prelude> :t (==) (fromInteger 0)
      (==) (fromInteger 0) :: (Eq a, Num a) => a -> Bool
      Prelude> :t (==) (fromInteger 0) (fromInteger 1)
      (==) (fromInteger 0) (fromInteger 1) :: Bool
      Prelude> (==) (fromInteger 0) (fromInteger 1)
      False


      Magic! It's unclear how or whether a was made concrete, yet the code ran successfully!



      According to the type inference rules, the type variables denoted by a above unify successfully with each other because they have compatible Num a constraints across the different terms. However, a never binds to a concrete type. My question is, at runtime, which instance dictionary (or specialization, whatever) is used for the (==) function?



      Is this a case where Haskell relies on a simple binary memcmp style comparison? Or perhaps it just picks the first instance in its list of Num instances since in theory it shouldn't matter (as long as the algebraic properties of that instance are implemented correctly...)







      haskell instance






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 2 at 3:01







      Will Bradley

















      asked Jan 2 at 2:52









      Will BradleyWill Bradley

      1,3561125




      1,3561125
























          1 Answer
          1






          active

          oldest

          votes


















          9














          Yes it is made concrete by defaulting, which is pretty much your second theory.




          The expression [..] is ambiguous because the literal 4 is of Num a => a type in Haskell. 4 can be an Int, a Float or any other type that is an instance of Num, so the compiler can’t choose any particular type for the same reason above. But the Haskell Committee thought that this is too much restriction. After much debates, they compromised and added an ad-hoc rule for choosing a particular default type.




          (Although it does matter which instance is chosen. For example 2^64 == 0 is True if Int is chosen, but False if Integer is chosen. Integer is first in the default list for good reason.)






          share|improve this answer

























            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%2f54000708%2fhow-does-the-haskell-compiler-emit-code-for-frominteger-0-frominteger-0%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









            9














            Yes it is made concrete by defaulting, which is pretty much your second theory.




            The expression [..] is ambiguous because the literal 4 is of Num a => a type in Haskell. 4 can be an Int, a Float or any other type that is an instance of Num, so the compiler can’t choose any particular type for the same reason above. But the Haskell Committee thought that this is too much restriction. After much debates, they compromised and added an ad-hoc rule for choosing a particular default type.




            (Although it does matter which instance is chosen. For example 2^64 == 0 is True if Int is chosen, but False if Integer is chosen. Integer is first in the default list for good reason.)






            share|improve this answer






























              9














              Yes it is made concrete by defaulting, which is pretty much your second theory.




              The expression [..] is ambiguous because the literal 4 is of Num a => a type in Haskell. 4 can be an Int, a Float or any other type that is an instance of Num, so the compiler can’t choose any particular type for the same reason above. But the Haskell Committee thought that this is too much restriction. After much debates, they compromised and added an ad-hoc rule for choosing a particular default type.




              (Although it does matter which instance is chosen. For example 2^64 == 0 is True if Int is chosen, but False if Integer is chosen. Integer is first in the default list for good reason.)






              share|improve this answer




























                9












                9








                9







                Yes it is made concrete by defaulting, which is pretty much your second theory.




                The expression [..] is ambiguous because the literal 4 is of Num a => a type in Haskell. 4 can be an Int, a Float or any other type that is an instance of Num, so the compiler can’t choose any particular type for the same reason above. But the Haskell Committee thought that this is too much restriction. After much debates, they compromised and added an ad-hoc rule for choosing a particular default type.




                (Although it does matter which instance is chosen. For example 2^64 == 0 is True if Int is chosen, but False if Integer is chosen. Integer is first in the default list for good reason.)






                share|improve this answer















                Yes it is made concrete by defaulting, which is pretty much your second theory.




                The expression [..] is ambiguous because the literal 4 is of Num a => a type in Haskell. 4 can be an Int, a Float or any other type that is an instance of Num, so the compiler can’t choose any particular type for the same reason above. But the Haskell Committee thought that this is too much restriction. After much debates, they compromised and added an ad-hoc rule for choosing a particular default type.




                (Although it does matter which instance is chosen. For example 2^64 == 0 is True if Int is chosen, but False if Integer is chosen. Integer is first in the default list for good reason.)







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Jan 2 at 3:14









                user2864740

                44.1k671150




                44.1k671150










                answered Jan 2 at 3:10









                luquiluqui

                48.3k6114168




                48.3k6114168
































                    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%2f54000708%2fhow-does-the-haskell-compiler-emit-code-for-frominteger-0-frominteger-0%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

                    android studio warns about leanback feature tag usage required on manifest while using Unity exported app?

                    SQL update select statement

                    'app-layout' is not a known element: how to share Component with different Modules