Talk:Haskell/Type basics II

Initial comment
In this form, this page could well be called "Numerical types". But at least for now it seems a good idea to have a generic name, so that we are free to add other non-numerical things and keep the focus on the type system features illustrated by numbers. --Duplode (talk) 05:12, 8 June 2010 (UTC)

Type error on "x + 3.1" example
Actually, writing

let x = 3

let y = x + 3.1

produces type error ("no instance for Fractional... arising from 3.1")


 * That is why that test must be loaded from a source file. I changed the passage to make that a little more obvious. Roughly, it doesn't work the same in the way you tried because GHC(i) will "de-generalize" the types of values defined in a let. You can override that by adding the type signature in the let, as in
 * Duplode (discuss • contribs) 20:34, 17 August 2013 (UTC)
 * Duplode (discuss • contribs) 20:34, 17 August 2013 (UTC)

Why wasn't / defined with type (Num a, Fractional b) => a -> a -> b ?
Is it merely the taste of the language designers or is there a deeper reason? For example, is there perhaps some other natural-looking expression that would become illegal?

I would appreciate a brief note (here or in the text.)


 * I suppose it has to do with simplicity and a dislike of implicit casts. Also, note that your proposed signature is a little too general, as there are no guarantees that a  can be converted into a  . The closest thing in Prelude is , which converts values of the   class. Thus your version of   might be written as:


 * But if the actual  operator was like that you'd have to remember the implied   usage and account for what it would do with your values every time you divide something. Under the status quo at least it is obvious that something else other than mere division is going on, as there are either explicit conversion functions calls or custom operators being used.


 * There is interesting commentary on this issue at the Haskell Wiki in the Generic number type page. For an example of  with no obvious conversion to , consider matrix types like this or this. Duplode (discuss • contribs) 21:45, 17 August 2013 (UTC)

(+) :: a -> a -> a is technically possible
"If (+) really had that type signature we would be able to add up two Bool, or two Char, which would make no sense – and is indeed impossible."

it is technically possible to  two chars, etc., since one can simply redefine (+). i know it's nit-picky, but i'm mildly averse to small incorrect details like these in computer language tutorials. they may give false insights or assurances, and therefore breed assumptions later. (for instance, someone might bang their head against the wall for hours while debugging a program because they didn't realize someone could redefine  or .) however, i doubt that this chapter is the place to fully address the issue. i was hoping to think of a natural expression that that wasn't awkward. however i couldn't think of anything that sounded as nice as what's currently there.

-- Sudozero (discuss • contribs) 02:44, 5 July 2014 (UTC)


 * I found and applied a simple fix. -- Sudozero (discuss • contribs) 02:58, 5 July 2014 (UTC)


 * One potential issue with my change is that if "very little sense" is a substantial change in writing style, it might stand out as something that has greater sense than it actually does. I only wanted to convey that the sense was non-zero, but pretty close to it. I hope it's not confusing and doesn't inpsire people to 'overload' function definitions like one can in C++, if it's not good style in Haskell. -- Sudozero (discuss • contribs) 03:18, 5 July 2014 (UTC)

Incorrect reason for not being able to represent the reals in memory
Footnote 2 says that one reason the reals cannot be represented in computer memory is that "between any two real numbers there are infinitely many real numbers". But that is also true of rationals, and there is no problem representing them. The problem isn't the order being dense but rather the uncountable cardinality. Smcpeak (discuss • contribs) 00:30, 30 June 2016 (UTC)


 * I have changed "infinitely" to "uncountably". There might be an even better way of phrasing that in this context. --Duplode (discuss • contribs) 09:04, 21 November 2016 (UTC)

"polymorphic constant" reads like an oxymoron
I'm new to Haskell. I'm not knowledgeable enough to explain the underlying mechanism that constitutes the "polymorphic constant". But I find the term confusing. From what I gather in this chapter, it's sort of like a "Num class instance".

It doesn't appear to be constant because it "morphs" when applicable. I suspect that the intention of using the word "constant" is to impress upon the reader that the numerical value doesn't just suddenly change on them, or perhaps as a reminder that variables in Haskell are generally considered to be constants. The addition of another sentence would bring clarity to this topic if such is the case.

However, if it truly is more variable-like than constant-like, perhaps calling it a "polymorphic instance" (of the Num type-class) will do?

Thanks!

--נהאל (discuss • contribs) 15:39, 5 July 2017 (UTC)


 * Thanks for pointing that out; "polymorphic constant" indeed isn't the best way of phrasing it. As you say, it is redundant, as all values are constant. That being so, I have changed it simply to "polymorphic value". A related (and appropriate) expression you may stumble upon is "polymorphic literal", which refers to expressions such as  (as opposed to, say, , a polymorphic variable).


 * That said, note that the "morphing" discussed here doesn't make the values non-constant. While a  variable may end up becoming an , a   or something else depending on how you use it in your program, it will never be an   in one place and a   in another one. Also, "polymorphic instance" wouldn't work as an alternative: in Haskell, types are instances of classes (eg.   and   are instances of  ), and not values.


 * Cheers, Duplode (discuss • contribs) 00:59, 7 July 2017 (UTC)


 * That makes sense. I think if I were reading it again for the first time, I wouldn't trip up on it now. Thanks for making it better, and I look forward to learning more!


 * --נהאל (discuss • contribs) 02:41, 8 July 2017 (UTC)

New Page, Focussing on Numbers?
(Dup of comment I put on the Classes & Types page by mistake)

Hello - I've been working on a page specifically about numbers. A draft is here. It's still WIP and currently has a few issues (including quite a lot of overlap with this and other pages. It's probably also too long.). I'd be happy to hear any opinions anyone has about it, but will continue with it for now. Thanks. --Davjam2


 * That will be pretty useful indeed, good work! I can picture your chapter being placed at the third track of the book ("Haskell in Practice"), with links to it at the end of Type Basics II and/or Classes and Types. That way, we don't have to worry about the deep dive into this particular topic affecting the flow of the initial parts of the book. I will make more specific comments on your draft when I get to read it in full -- it might take a while, but I'll get there eventually :) Cheers, Duplode (discuss • contribs) 00:17, 2 March 2021 (UTC)