9 ms·

Haskell and the "foul stench of cargo cult mathematics"

65 points by fogus 16y ago

dfranke 16y ago
He's not the first mathematician to get annoyed by how poorly designed the numeric classes in the Haskell prelude are. But there are better alternatives already out there. http://hackage.haskell.org/package/numeric-prelude http://hackage.haskell.org/package/numeric-prelude
- aristidb 16y ago
  No, he seems to get tripped up by the open world assumption, which is a limitation of Haskell's type system. It allows separate compilation of different modules, for example. But nobody said that Haskell's type system is without limitations, right?
- applicative 16y ago
  On what grounds are you affirming that this guy http://symbo1ics.com/blog/?page_id=2 http://symbo1ics.com/blog/?page_id=2 is a mathematician?
  - reikonomusha 16y ago
    On what grounds are you affirming that guy's not?
    - applicative 16y ago
      I didn't make any affirmation. I don't know what the criteria are for coming under the heading "mathematician". I would count an undergraduate degree as adequate -- but he is 20; he does not call himself a mathematician; he says rather that he is 'passionate about mathematics, mathematical exposition and programming'. One could also study the internal evidence of the post.
jerf 16y ago
I find myself wondering if this is getting upvoted by Haskell contrarians who aren't actually reading the article and noticing that it not about Haskell "being too mathematical", but not being out-of-the-box suitable as a really convenient ring theory explorer. I bet a lot of the upvoters would actually consider this a good sign rather than a bad one, on average.... There's still some room for Haskell syntax improvements. I've found the recent OverloadedStrings to be a big step forward, allowing you to directly use strings in places where it actually wants another type, removing a ton of useless and hard-to-factor-out code converting strings to ByteStrings, Text, and various other types that are there simply to label Strings as something more specific. As dfrankes says, it is known the Prelude isn't perfect, but I'm not sure there's actually a perfect formulation regardless of what you do. Even if you could get all the mathematicians to agree completely about what all relevant mathematical entities are, something that is a lot harder than it sounds because it turns out a lot of them can have arbitrarily-chosen fiddly details when you really get down to it (how many set theories are there again?), you'll never bridge the gulf between a conventional programmer and any mathematician, and I think Haskell's promise as an interesting language lies rather more with the conventional programmer case than making mathematicians happy. (Not because the latter is bad, but because it is a sufficiently hard problem that trying to reconcile the needs of such a beast with something still useful is probably impossible.)
- xi 16y ago
  I find myself wondering if this is getting upvoted by Haskell contrarians who aren't actually reading the article and noticing that it not about Haskell "being too mathematical", but not being out-of-the-box suitable as a really convenient ring theory explorer. I love how you, in the same sentence, managed to put in doubt credibility of the upvoters and downplay the issue in hand. To answer your question: yes, I actually read the article. Why I upvoted it? Haskell's way of wrapping integer literals with implicit `fromInteger` seems to be a clever hack that alleviates some pain when dealing with basic arithmetics, but I always wondered what kind of unexpected problems it may cause. I got an answer in this article.
  - jerf 16y ago
    "downplay the issue in hand." No, I don't. The issue is serious. I'm personally a proponent of tossing the current Prelude and replacing it with something more useful. I think the supposed costs are smaller than expected (it's already modular) and the benefits underestimated. I'm not a Haskell booster, I'm an interested skeptic. I just think an article about a relatively esotoric issue about Haskell got upvoted suspiciously quickly on a holiday weekend. It's not a bad article by any means.
llimllib 16y ago
Cached: http://webcache.googleusercontent.com/search?hl=en&safe=off&biw=912&bih=765&q=cache%3Ahttp%3A%2F%2Fsymbo1ics.com%2Fblog%2F%3Fp%3D788&aq=f&aqi=&aql=&oq=&gs_rfai= http://webcache.googleusercontent.com/search?hl=en&safe=...
contextfree 16y ago
I guess because Conal explains the type inference limitation in question using mathematical terminology, it's tripped the author's "cargo cult mathematics" detector, but it actually sounds more like a software engineering concern. They want to avoid having new instance declarations break existing code (inferences), which seems like a reasonable property to not want to have from a software engineering POV. It makes more sense when building from code files than in interactive mode.
notallama 16y ago
does this guy not know how to use type declarations? [1,2,3,4,5] :: [Int] problem solved!
- xyzzyz 16y ago
  He knows, as it is clearly visible in his article. His point is, he should not need to.
  - alnayyir 16y ago
    This is a property of many statically typed languages, and Haskell isn't known for being one of the more forgiving languages in that family. I appreciate that his goals were more mathematically oriented than not, but surely he would've seen something like this coming?
  - hesselink 16y ago
    Actually, you don't need to in most real programs. You usually use the elements of a list with some function that makes it clear what type they have. In GHCi (the interpreter) this doesn't happen. It has some defaulting rules to alleviate this, but I don't quite understand them, so I can't say why they didn't kick in in this case.
    - rtperson 16y ago
      The thing with Haskell is that it doesn't automatically coerce types the way other languages do. It uses Hindley-Milner type inference up front if you don't specify your types, but this is far from foolproof. Once it's decided you're using type Foo, you're stuck. You need explicit typing in many cases. One of the first things you learn as a Haskell programmer is to treat type inference with suspicion.
      - jwatzman 16y ago
        Languages like SML and OCaml also use this sort of type inference, but you tend to not need type annotations in those languages except in very special cases. I think this is also fairly true of Haskell -- type inference works in 99% of the cases, and explicit type annotations are just a stylistic thing.
postfuturist 16y ago
The syntax highlighting on this blog creates some yellow-on-white text that is difficult to read or even look at.
jemfinch 16y ago
I don't think "cargo cult" means what the author thinks it means. It's not just a general epithet.
- gammarator 16y ago
  I think he's making an appropriate reference to Feynman's definition of "cargo cult science" (http://www.lhup.edu/~DSIMANEK/cargocul.htm http://www.lhup.edu/~DSIMANEK/cargocul.htm): "So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they're missing something essential... It's a kind of scientific integrity, a principle of scientific thought that corresponds to a kind of utter honesty... In summary, the idea is to try to give all of the information to help others to judge the value of your contribution; not just the information that leads to judgment in one particular direction or another."
  - applicative 16y ago
    Why is this 'appropriate' rather than unjust slander against conal and mauke?
    - reikonomusha 16y ago
      Because it's not slander against either of them. See the comments.
      - applicative 16y ago
        Oh I hadn't realized I was dealing with another of his sock puppets. It is slander against them as I point out in [my comment on your comment](http://symbo1ics.com/blog/?p=788 http://symbo1ics.com/blog/?p=788) . If you cut out all use of the text from #haskell, it would be just another uninformed farrago of lies about Haskell, like the other one you generate in your comment -- the one about the Monad type class, there are perhaps several other -- which is a criminal slander directed against Philip Wadler in particular. He introduced type classes in the late 80's thinking in particular of ML. See the papers assembled on http://homepages.inf.ed.ac.uk/wadler/topics/type-classes.html http://homepages.inf.ed.ac.uk/wadler/topics/type-classes.htm... (It is by the way this rather unremarkable use of type classes that is the source of your difficulties). Note that even in the 1995 co-authored paper "Type classes in Haskell" makes no mention of a Monad typeclass; indeed type classes that operate not on individual types, but on type formers like Maybe or IO etc. are no where envisaged. Later, following the lead of Moggi's 'monadic' semantical doctrine, he saw that a programming language could internalize this idea, and moreover that he could introduce a type class Monad into Haskell itself, a move far outstripping anything you could previously have anticipated from the type class concept. Papers on this are to be found here http://homepages.inf.ed.ac.uk/wadler/topics/monads.html http://homepages.inf.ed.ac.uk/wadler/topics/monads.html Haskell was well under way before this move was made. Type class Monad was a rather late introduction. Now, you declare these actions of Wadler's to be a "use of ... pseudo-mathematics as reasoning in the decision-process for the Haskell language". You suggest that Wadler was unaware that every monad on a category is a functor from the category to itself. And you suggest that Wadler can be brought under this heading: "These individuals assimilate the concepts, and then pervert them, giving them names which are not appropriate — a kind of pseudo-mathematics." This is all outright slander. Here your rigorous mathematical meditation on the pitiful wanna-be and fraud Wadler in full: There are individuals, however, who thrive on the “mysteriousness” afforded by this unapproachability. They revel, rather than find distaste, in the “genius” image pinned to those who can speak in this technical tongue. These individuals assimilate the concepts, and then pervert them, giving them names which are not appropriate — a kind of pseudo-mathematics. Haskell’s Monad is a prime and very uncontrived example. It is impossible to ensure that a monad within Haskell conforms to the monadic axioms (in other words, it is impossible to ensure a monad within Haskell is actually a monad). Furthermore, though it is often regarded as a historical mistake, monads in Haskell are not instances of the Functor type class. This is particularly strange, because monads in category theory are functors by definition. By considering the use of this pseudo-mathematics as reasoning in the decision-process for the Haskell language, we arrive at the conundrum described in the post. Claiming mathematics as the reasoning for such errors contradicts the flagrant disregard for mathematical correctness with Monad or Num, for example. It is this contradiction with which I take severe offense.
necrobious 16y ago
"We have to clarify that 5 is an Int? Seriously?" Yup, just like you do in most statically typed languages.
- reikonomusha 16y ago
  (* Standard ML of New Jersey v110.72 [built: Sun May 16 15:16:12 2010] *) - 5; val it = 5 : int (* Objective Caml version 3.11.2 *) # 5;; - : int = 5 // D programming language void main(string[] args){ writefln(typeid(typeof(5))); } // Output: int // C# 4.0 var n = 5; // int // Go programming language var n = 5 // int // Welcome to Scala version 2.7.7final (OpenJDK 64-Bit Server VM, Java 1.6.0_20). scala> 5; res0: Int = 5 // C++ #include <iostream> #include <typeinfo> int main(){ cout << typeid(5).name() << endl; return 0; } // Output: i I see...
  - deleted 16y ago
    [deleted]
  - deleted 16y ago
    [deleted]
  - deleted 16y ago
    [deleted]
  - applicative 16y ago
    reikonomusha, you left one out: // GHCi, version 6.12.3: http://www.haskell.org/ghc/ Prelude> :set +t Prelude> 5 5 it :: Integer
    - reikonomusha 16y ago
      :set +t
      - deleted 16y ago
        [deleted]
Aaronontheweb 16y ago
Am I the only one seeing this? "Well, we have a list of integers [Math Processing Error]. And [Math Processing Error] for monoid [Math Processing Error]. So [Math Processing Error] since [Math Processing Error] is a monoid, yes? Of course."
- pohl 16y ago
  Looks like the author marked up mathematical notation using this: http://www.mathjax.org/ ...which must be broken for your environment.
  - MrMan 16y ago
    The whole post is about math processing errors.
hesselink 16y ago
As an aside, note that this isn't the recommended way to make Int an instance of Monoid, since there is another, equally valid definition using '1' and '*'. The recommended way is to make a newtype. In fact, the Sum and Product newtypes are already defined in Data.Monoid for this reason.
jrockway 16y ago
A programming language where you have to tell it the type of expressions if the type is ambiguous? That would be a deal killer, no wonder nobody uses Haskell. Java handles this much better: Integer i = new Integer(5); I mean, look at how concise and readable that is. Java knows that 5 is an Integer and you don't even have to tell it. Oh wait, the opposite. Basically, the author seems upset that "5" is a Number rather than an Integer. But that's fine, because it's true. 5 is a real fraction. 5 is a complex fraction. 5 is a double. 5 is a char. 5 is an unsigned long long. 5 is a lot of things to a computer. So sometimes, you have to tell it which one you want. This isn't cargo-cult mathematics, but rather reflects that Haskell is a computer programming language. There is a lot of math in there, sure, but at the end of the day, you are writing computer programs to run on computers. And computers don't know what an Integer is. It just knows that it has some bits in memory and that it should interpret them in a certain way. This guy's blog is weird.
- Zaak 16y ago
  > Basically, the author seems upset that "5" is a Number rather than an Integer. But that's fine, because it's true. 5 is a real fraction. 5 is a complex fraction. 5 is a double. 5 is a char. 5 is an unsigned long long. 5 is a lot of things to a computer. So sometimes, you have to tell it which one you want. A contributing factor here is that there are no subtype relations in Haskell. In math, "5" is all of those things simultaneously, but in Haskell it can only be one at a time.
  - thesz 16y ago
    >In math, "5" is all of those things simultaneously, but in Haskell it can only be one at a time. How is that? Excerpts from ghci dialog: Prelude> :t 5 5 :: (Num t) => t class (Num a) => Fractional a where (/) :: a -> a -> a recip :: a -> a fromRational :: Rational -> a Prelude Data.Complex> :i RealFrac class (Real a, Fractional a) => RealFrac a where ... Prelude Data.Complex> :i RealFloat class (RealFrac a, Floating a) => RealFloat a where ... Prelude Data.Complex> :i Complex data (RealFloat a) => Complex a = !a :+ !a instance (RealFloat a) => Eq (Complex a) So, 5 is an Int, Integer, Rational, Double and Complex (which, actually, could be Complex Int or Complex Double).

65 points by fogus 16y ago

He's not the first mathematician to get annoyed by how poorly designed the numeric classes in the Haskell prelude are. But there are better alternatives already out there. http://hackage.haskell.org/package/numeric-prelude http://hackage.haskell.org/package/numeric-prelude

aristidb 16y ago
No, he seems to get tripped up by the open world assumption, which is a limitation of Haskell's type system. It allows separate compilation of different modules, for example. But nobody said that Haskell's type system is without limitations, right?
applicative 16y ago
On what grounds are you affirming that this guy http://symbo1ics.com/blog/?page_id=2 http://symbo1ics.com/blog/?page_id=2 is a mathematician?
- reikonomusha 16y ago
  On what grounds are you affirming that guy's not?
  - applicative 16y ago
    I didn't make any affirmation. I don't know what the criteria are for coming under the heading "mathematician". I would count an undergraduate degree as adequate -- but he is 20; he does not call himself a mathematician; he says rather that he is 'passionate about mathematics, mathematical exposition and programming'. One could also study the internal evidence of the post.

jerf 16y ago

I find myself wondering if this is getting upvoted by Haskell contrarians who aren't actually reading the article and noticing that it not about Haskell "being too mathematical", but not being out-of-the-box suitable as a really convenient ring theory explorer. I bet a lot of the upvoters would actually consider this a good sign rather than a bad one, on average.... There's still some room for Haskell syntax improvements. I've found the recent OverloadedStrings to be a big step forward, allowing you to directly use strings in places where it actually wants another type, removing a ton of useless and hard-to-factor-out code converting strings to ByteStrings, Text, and various other types that are there simply to label Strings as something more specific. As dfrankes says, it is known the Prelude isn't perfect, but I'm not sure there's actually a perfect formulation regardless of what you do. Even if you could get all the mathematicians to agree completely about what all relevant mathematical entities are, something that is a lot harder than it sounds because it turns out a lot of them can have arbitrarily-chosen fiddly details when you really get down to it (how many set theories are there again?), you'll never bridge the gulf between a conventional programmer and any mathematician, and I think Haskell's promise as an interesting language lies rather more with the conventional programmer case than making mathematicians happy. (Not because the latter is bad, but because it is a sufficiently hard problem that trying to reconcile the needs of such a beast with something still useful is probably impossible.)

xi 16y ago
I find myself wondering if this is getting upvoted by Haskell contrarians who aren't actually reading the article and noticing that it not about Haskell "being too mathematical", but not being out-of-the-box suitable as a really convenient ring theory explorer. I love how you, in the same sentence, managed to put in doubt credibility of the upvoters and downplay the issue in hand. To answer your question: yes, I actually read the article. Why I upvoted it? Haskell's way of wrapping integer literals with implicit `fromInteger` seems to be a clever hack that alleviates some pain when dealing with basic arithmetics, but I always wondered what kind of unexpected problems it may cause. I got an answer in this article.
- jerf 16y ago
  "downplay the issue in hand." No, I don't. The issue is serious. I'm personally a proponent of tossing the current Prelude and replacing it with something more useful. I think the supposed costs are smaller than expected (it's already modular) and the benefits underestimated. I'm not a Haskell booster, I'm an interested skeptic. I just think an article about a relatively esotoric issue about Haskell got upvoted suspiciously quickly on a holiday weekend. It's not a bad article by any means.

llimllib 16y ago

Cached: http://webcache.googleusercontent.com/search?hl=en&safe=off&biw=912&bih=765&q=cache%3Ahttp%3A%2F%2Fsymbo1ics.com%2Fblog%2F%3Fp%3D788&aq=f&aqi=&aql=&oq=&gs_rfai= http://webcache.googleusercontent.com/search?hl=en&safe=...

contextfree 16y ago

I guess because Conal explains the type inference limitation in question using mathematical terminology, it's tripped the author's "cargo cult mathematics" detector, but it actually sounds more like a software engineering concern. They want to avoid having new instance declarations break existing code (inferences), which seems like a reasonable property to not want to have from a software engineering POV. It makes more sense when building from code files than in interactive mode.

notallama 16y ago

does this guy not know how to use type declarations? [1,2,3,4,5] :: [Int] problem solved!

xyzzyz 16y ago
He knows, as it is clearly visible in his article. His point is, he should not need to.
- alnayyir 16y ago
  This is a property of many statically typed languages, and Haskell isn't known for being one of the more forgiving languages in that family. I appreciate that his goals were more mathematically oriented than not, but surely he would've seen something like this coming?
- hesselink 16y ago
  Actually, you don't need to in most real programs. You usually use the elements of a list with some function that makes it clear what type they have. In GHCi (the interpreter) this doesn't happen. It has some defaulting rules to alleviate this, but I don't quite understand them, so I can't say why they didn't kick in in this case.
  - rtperson 16y ago
    The thing with Haskell is that it doesn't automatically coerce types the way other languages do. It uses Hindley-Milner type inference up front if you don't specify your types, but this is far from foolproof. Once it's decided you're using type Foo, you're stuck. You need explicit typing in many cases. One of the first things you learn as a Haskell programmer is to treat type inference with suspicion.
    - jwatzman 16y ago
      Languages like SML and OCaml also use this sort of type inference, but you tend to not need type annotations in those languages except in very special cases. I think this is also fairly true of Haskell -- type inference works in 99% of the cases, and explicit type annotations are just a stylistic thing.

postfuturist 16y ago

The syntax highlighting on this blog creates some yellow-on-white text that is difficult to read or even look at.

jemfinch 16y ago

I don't think "cargo cult" means what the author thinks it means. It's not just a general epithet.

gammarator 16y ago
I think he's making an appropriate reference to Feynman's definition of "cargo cult science" (http://www.lhup.edu/~DSIMANEK/cargocul.htm http://www.lhup.edu/~DSIMANEK/cargocul.htm): "So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they're missing something essential... It's a kind of scientific integrity, a principle of scientific thought that corresponds to a kind of utter honesty... In summary, the idea is to try to give all of the information to help others to judge the value of your contribution; not just the information that leads to judgment in one particular direction or another."
- applicative 16y ago
  Why is this 'appropriate' rather than unjust slander against conal and mauke?
  - reikonomusha 16y ago
    Because it's not slander against either of them. See the comments.
    - applicative 16y ago
      Oh I hadn't realized I was dealing with another of his sock puppets. It is slander against them as I point out in [my comment on your comment](http://symbo1ics.com/blog/?p=788 http://symbo1ics.com/blog/?p=788) . If you cut out all use of the text from #haskell, it would be just another uninformed farrago of lies about Haskell, like the other one you generate in your comment -- the one about the Monad type class, there are perhaps several other -- which is a criminal slander directed against Philip Wadler in particular. He introduced type classes in the late 80's thinking in particular of ML. See the papers assembled on http://homepages.inf.ed.ac.uk/wadler/topics/type-classes.html http://homepages.inf.ed.ac.uk/wadler/topics/type-classes.htm... (It is by the way this rather unremarkable use of type classes that is the source of your difficulties). Note that even in the 1995 co-authored paper "Type classes in Haskell" makes no mention of a Monad typeclass; indeed type classes that operate not on individual types, but on type formers like Maybe or IO etc. are no where envisaged. Later, following the lead of Moggi's 'monadic' semantical doctrine, he saw that a programming language could internalize this idea, and moreover that he could introduce a type class Monad into Haskell itself, a move far outstripping anything you could previously have anticipated from the type class concept. Papers on this are to be found here http://homepages.inf.ed.ac.uk/wadler/topics/monads.html http://homepages.inf.ed.ac.uk/wadler/topics/monads.html Haskell was well under way before this move was made. Type class Monad was a rather late introduction. Now, you declare these actions of Wadler's to be a "use of ... pseudo-mathematics as reasoning in the decision-process for the Haskell language". You suggest that Wadler was unaware that every monad on a category is a functor from the category to itself. And you suggest that Wadler can be brought under this heading: "These individuals assimilate the concepts, and then pervert them, giving them names which are not appropriate — a kind of pseudo-mathematics." This is all outright slander. Here your rigorous mathematical meditation on the pitiful wanna-be and fraud Wadler in full: There are individuals, however, who thrive on the “mysteriousness” afforded by this unapproachability. They revel, rather than find distaste, in the “genius” image pinned to those who can speak in this technical tongue. These individuals assimilate the concepts, and then pervert them, giving them names which are not appropriate — a kind of pseudo-mathematics. Haskell’s Monad is a prime and very uncontrived example. It is impossible to ensure that a monad within Haskell conforms to the monadic axioms (in other words, it is impossible to ensure a monad within Haskell is actually a monad). Furthermore, though it is often regarded as a historical mistake, monads in Haskell are not instances of the Functor type class. This is particularly strange, because monads in category theory are functors by definition. By considering the use of this pseudo-mathematics as reasoning in the decision-process for the Haskell language, we arrive at the conundrum described in the post. Claiming mathematics as the reasoning for such errors contradicts the flagrant disregard for mathematical correctness with Monad or Num, for example. It is this contradiction with which I take severe offense.

necrobious 16y ago

"We have to clarify that 5 is an Int? Seriously?" Yup, just like you do in most statically typed languages.

reikonomusha 16y ago
(* Standard ML of New Jersey v110.72 [built: Sun May 16 15:16:12 2010] *) - 5; val it = 5 : int (* Objective Caml version 3.11.2 *) # 5;; - : int = 5 // D programming language void main(string[] args){ writefln(typeid(typeof(5))); } // Output: int // C# 4.0 var n = 5; // int // Go programming language var n = 5 // int // Welcome to Scala version 2.7.7final (OpenJDK 64-Bit Server VM, Java 1.6.0_20). scala> 5; res0: Int = 5 // C++ #include <iostream> #include <typeinfo> int main(){ cout << typeid(5).name() << endl; return 0; } // Output: i I see...
- deleted 16y ago
  [deleted]
- deleted 16y ago
  [deleted]
- deleted 16y ago
  [deleted]
- applicative 16y ago
  reikonomusha, you left one out: // GHCi, version 6.12.3: http://www.haskell.org/ghc/ Prelude> :set +t Prelude> 5 5 it :: Integer
  - reikonomusha 16y ago
    :set +t
    - deleted 16y ago
      [deleted]

Aaronontheweb 16y ago

Am I the only one seeing this? "Well, we have a list of integers [Math Processing Error]. And [Math Processing Error] for monoid [Math Processing Error]. So [Math Processing Error] since [Math Processing Error] is a monoid, yes? Of course."

pohl 16y ago
Looks like the author marked up mathematical notation using this: http://www.mathjax.org/ ...which must be broken for your environment.
- MrMan 16y ago
  The whole post is about math processing errors.

hesselink 16y ago

As an aside, note that this isn't the recommended way to make Int an instance of Monoid, since there is another, equally valid definition using '1' and '*'. The recommended way is to make a newtype. In fact, the Sum and Product newtypes are already defined in Data.Monoid for this reason.

jrockway 16y ago

A programming language where you have to tell it the type of expressions if the type is ambiguous? That would be a deal killer, no wonder nobody uses Haskell. Java handles this much better: Integer i = new Integer(5); I mean, look at how concise and readable that is. Java knows that 5 is an Integer and you don't even have to tell it. Oh wait, the opposite. Basically, the author seems upset that "5" is a Number rather than an Integer. But that's fine, because it's true. 5 is a real fraction. 5 is a complex fraction. 5 is a double. 5 is a char. 5 is an unsigned long long. 5 is a lot of things to a computer. So sometimes, you have to tell it which one you want. This isn't cargo-cult mathematics, but rather reflects that Haskell is a computer programming language. There is a lot of math in there, sure, but at the end of the day, you are writing computer programs to run on computers. And computers don't know what an Integer is. It just knows that it has some bits in memory and that it should interpret them in a certain way. This guy's blog is weird.

Zaak 16y ago
> Basically, the author seems upset that "5" is a Number rather than an Integer. But that's fine, because it's true. 5 is a real fraction. 5 is a complex fraction. 5 is a double. 5 is a char. 5 is an unsigned long long. 5 is a lot of things to a computer. So sometimes, you have to tell it which one you want. A contributing factor here is that there are no subtype relations in Haskell. In math, "5" is all of those things simultaneously, but in Haskell it can only be one at a time.
- thesz 16y ago
  >In math, "5" is all of those things simultaneously, but in Haskell it can only be one at a time. How is that? Excerpts from ghci dialog: Prelude> :t 5 5 :: (Num t) => t class (Num a) => Fractional a where (/) :: a -> a -> a recip :: a -> a fromRational :: Rational -> a Prelude Data.Complex> :i RealFrac class (Real a, Fractional a) => RealFrac a where ... Prelude Data.Complex> :i RealFloat class (RealFrac a, Floating a) => RealFloat a where ... Prelude Data.Complex> :i Complex data (RealFloat a) => Complex a = !a :+ !a instance (RealFloat a) => Eq (Complex a) So, 5 is an Int, Integer, Rational, Double and Complex (which, actually, could be Complex Int or Complex Double).