[Haskell-beginners] fromIntegral

[Daniel Fischer]

On Saturday 02 October 2010 21:53:11, Russ Abbott wrote:
> Daniel, I appreciate your help.  Let me tell you where I'm coming from.
>  I teach an introductory Haskell course once a year.  I'm not a Haskell
> expert, and I tend to forget much of what I knew from one year to the
> next.  Perhaps more importantly, one reason for asking these questions
> is to explain what's going on to students who are just seeing Haskell
> for the first time.

Hrrrmmphhhh.
What's going on behind the scene is complex and implementation dependent 
(and I know only a little about how GHC does it).

Perhaps it's best to say that for the time being, they should regard 
polymorphic expressions like [] as either one symbol denoting different 
values of different types or one value having many types, whichever they 
feel more comfortable with.

Both are possible ways of implementing polymorphism and unless they want to 
build their own implementation they need not choose how to nail it down.
Coming to grips with the gory details is difficult enough when you have a 
good understanding of the higher level.

> We are now 2 weeks into the course.  If this can't
> be explained (at least at an intuitive level) without displaying lots of
> intermediate code, it doesn't help me.

Well, at that point Core is not a good idea. At an intuitive level, I think 
both of the above work.
If you want to know what happens in more detail, you have to look at the 
compiler's intermediate representation(s), but to get proficient in using a 
language, that's not necessary.

>
> So here are a couple of questions about this example.
>
> What does it mean to say a Num instance for Char.

You write an

instance Num Char where

and you say how the operations should work on Chars.

> Can you give me an
> example of what that means in a program that will execute.  (Preferably
> the program would be as simple as possible.)

module Main (main) where

-- ord and chr convert between Char and Int
import Data.Char (ord, chr)

-- Number of elements Char has.
-- One could also choose 256 for example.
charMod :: Int
charMod = ord maxBound + 1

-- We lift addition, subtraction and multiplication
-- from Int, should be familiar from C (1-byte char, 256 values)
-- or Java (2-byte char, 65536 values).
-- negate and fromInteger are not quite the same because
-- the number of Chars is not a power of 2.
instance Num Char where
    a + b = chr $ (ord a + ord b) `mod` charMod
    a - b = chr $ (ord a - ord b) `mod` charMod
    a * b = chr $ (ord a * ord b) `mod` charMod
    negate a = chr $ negate (ord a) `mod` charMod
    abs a = a
    signum a = chr $ signum (ord a)
    fromInteger n = chr $ fromInteger n `mod` charMod

test :: Bool
test = [97] == "a"
-- aka True

main :: IO ()
main = do
    putStrLn
        [67,104,97,114,97,99,116,101,114,115,32,97,115,32,110,117
        ,109,98,101,114,115,44,32,105,116,32,119,111,114,107,115,46]
    putStrLn $ map (8600 -) "The quick brown fox jumps over the lazy dog."

-- That only uses fromInteger, so one could leave the other functions
-- undefined here, but you could substitute e.g. '0'+'1' for 97, 't'-'3' 
for 67, '\n'*11 for 110, ...

>
> Is there a way to display a value along with its type during program
> execution?

At the ghci prompt (or hugs), you can

query the type of an expression with the :t command (or spell it out, 
:type)

Prelude> :type True
True :: Bool
Prelude> :t \f -> [map f [1 .. 4], "now"]
\f -> [map f [1 .. 4], "now"]
  :: (Num a, Enum a) => (a -> Char) -> [[Char]]

Prelude> :set +t
Prelude> length "Hey there!"
10
it :: Int
Prelude> []
[]
it :: [a]

Hugs> :set +t
Hugs> length "Hullo"
5 :: Int
Hugs> []
[] :: [a]

Those print only the type of the final value, so if you want to display the 
types of intermediate values in a real programme, you need something 
different.

> I know about Show; is there something similar like
> ShowWithType (or even ShowType) that (if implemented) will generate a
> string of a value along with its type?

Not really. There is Data.Typeable, though, which contains the typeOf 
function:

Prelude Data.Typeable> :t typeOf
typeOf :: (Typeable a) => a -> TypeRep

it is, however, probably of limited use for that purpose, since

Prelude Data.Typeable> typeOf Nothing

<interactive>:1:0:
    Ambiguous type variable `a' in the constraint:
      `Typeable a' arising from a use of `typeOf' at <interactive>:1:0-13
    Probable fix: add a type signature that fixes these type variable(s)


>
> It makes sense to me to say that [ ] is a function that takes a type as
> an argument and generates an value.

Note that that's an implementation detail. That's not at the Haskell level.

> If that's the case, it also makes
> sense to say that [ ] == [ ] can't be evaluated because there is simply
> no == for functions.

No. [] as a function taking a type as argument is an interpretation below 
the Haskell level, while (==) operates on the Haskell level.

>
> It also makes sense to me to say that == is a collection of more
> concrete functions from which one is selected depending on the type
> required by the expression within which == appears.

That's one way to look at it. Probably the best for the beginning.

>
> Since the required type is known at compile time, it would seem that the
> selection of which == to use could be made at compile time. One
> shouldn't have to carry along a dictionary.  (Perhaps someone said that
> earlier. But if so, why the long discussion about Dictionaries?)

Ah, but what if you compile a library? Then you don't know at which types 
the function will be used in later programmes, so you have to have some 
method of determining which particular (==) to use when you later compile 
the programme.

> This seems like a standard definition of an overloaded function.
> So why is there an objection to simply saying that == is overloaded
> and letting it go at that?

I don't know, I wouldn't object to it. As long as you point out that it's 
not quite the same overloading as e.g. in Java, you can't have an 
overloading of a function with different numbers of arguments in Haskell.

>
> The answer to why tail ['a'] == [ ] is ok would go something like this.
> (Is this ok?)
>
> a. [ ] is a function that takes a type argument and generates the empty
> list of that type. In particular [ ] is not a primitive value.
>
> b. The type of the lhs is [Char].
>
> c. That selects == :: [Char] -> [Char] -> Bool as the version of == to
> use in the expression.
>
> d. That inserts Char as the Type argument to be passed to the [ ]
> function on the rhs.
>
> e. All the preceding can be done at compile time.
>
> f. When executed, the lhs and rhs will both execute the [ ] function
> with argument Char. They both generate the value [ ] :: [Char]. Those
> two values will be identical and the value of the expression will be
> True.
>

If you want to understand what happens at the lower Core level, that's 
okay, but it utterly doesn't work at the Haskell level.

At the Haskell level, we have

(==) :: Eq a => a -> a -> Bool

so (==) takes two arguments of the same type, but it can take two Bools, 
two Ints, ...

The LHS is [Char], hence the RHS must be too if the expression is to be 
well-typed. The RHS, [] has the inferred type [a], i.e. it can be a list of 
any type. That type can be unified with [Char] (since it is more general), 
the unification is done, fixing the type of [] *in this expression* as 
[Char].

>
> All of the preceding is something I would feel comfortable saying to
> someone who is just 2 weeks into Haskell.

I wouldn't.

> There may be a lot of pieces
> to that explanation, but none of them require much prerequisite Haskell
> knowledge.
>
> -- Russ