[Haskell-beginners] fromIntegral

[Daniel Fischer]

On Saturday 02 October 2010 23:28:59, Thomas wrote:
> So, instantiating Char for Num would require you to provide
> implementations for (+), (*), (-), negate, abs, signum and fromInteger
> for Char.
> While syntactically possible, I don't see any semantically reasonable
> way to do so.
>

For some values of reasonable, defining the operations via the Enum 
instance is semantically reasonable.

It's however not the best approach, even if for some odd reason you need 
21-bit integers.

> > Is there a way to display a value along with its type during program
> > execution?  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?
>
> AFAIK in GHCi you can do both, but not simultaneously:
> Prelude> let a = 5::Int
> Prelude> :t a
> a :: Int
> Prelude> a
> 5
>

:set +t

makes ghci display the type of an expression entered at the prompt (except 
if it's an IO-action, then it behaves a little different).

> > It makes sense to me to say that [ ] is a function that takes a type
> > as an argument and generates an value. If that's the case, it also
> > makes sense to say that [ ] == [ ] can't be evaluated because there is
> > simply no == for functions.
>
> Prelude> :t []
> [] :: [a]
>
> So [] is a list type, not a function type.
>

Right. [] as a function taking a type as argument is how it's represented 
at the Core level in GHC, not how it's understood at the Haskell level or 
the assembly level.

> Prelude> [] == []
> True
>
> You can actually compare [] to itself.

At the ghci prompt, since that uses extended default rules and chooses to 
compare at the type [()]. In a source file, you'd have to turn on the 
extended default rules ({-# LANGUAGE ExtendedDefaultRules #-}) or tell the 
compiler which type to use.

>
>
> So your reasoning does not seem to be valid to me.
> At least not on the Haskell source code level (which is what you and
> your students work with). Daniel referred to the Core level when saying
> that [] was a function there.
>
>
> My reasoning would go somewhere along the following line:
> [] has a polymorphic type, specifically it's an empty list of elements
> of any type ([] :: [a], type variable a is not restricted)
>
> So, [] will compare to any empty list, no matter what its elements' type
> actually is.

You need an Eq instance, of course.

>
> Given:
>  > let
>  >	xs = []
>  >       ys = 1:xs
>  >       zs = 'a': xs
>
> Then "tail ys == tail zs" will not type check. Neither "tail ys" nor
> "tail zs" are polymorphic:
> ys :: [Integer]

Well, tail ys is polymorphic, its type is

tail ys :: Num a => [a]

the type variable a is defaulted to Integer if there are no further 
constraints on a. If you use it for other stuff, it can be used at other 
types too.

Prelude> let xs = []; ys = 1:xs; ws = length xs:tail ys; vs = pi:tail ys in 
(tail ws, tail vs)
([],[])
it :: (Floating a) => ([Int], [a])

> zs :: [Char]
>
> So the expression "tail ys == tail zs" is invalid - the lhs and rhs must
> have the same type but they do not. Nothing will get compared, no tail
> will be determined - it will just plainly be rejected from the compiler
> (or interpreter).
>
> For comparison: "tail ys == []" is different.
> (tail ys) :: [Integer]
> [] :: [a]
>
> So we set (well, GHC does this for us) type variable a to Integer and
> have: tail ys :: [Integer] == [] :: [Integer]
> which is perfectly valid.
>

Yep.

> > 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.
>
> See above - [] is not a function.
>
> > 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?)
> > 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?
>
> (==) :: (Eq a) => a -> a -> Bool
>
> So, yes, (==) feels a little like an overloaded function.

And such functions are often called overloaded.

> It is a function that accepts any Eq-comparable type.
> However, overloading IIRC does not behave identically.

Overloading in Java, C# etc. behaves differently. Overloading is still a 
good term to describe (==) etc. in my opinion. One has to be aware that the 
word denotes different though related concepts for different languages, of 
course.

> For example function arity is not required to be the same when
> overloading methods - and restrictions on types are very different, too.
>
> HTH,
> Thomas