Send Beginners mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."


Today's Topics:

   1.  Type classes are not like interfaces, after all
      (Francesco Bochicchio)
   2. Re:  Type classes are not like interfaces, after  all
      (Paul Visschers)
   3. Re:  Type classes are not like interfaces, after  all
      (Jan Jakubuv)
   4. Re:  Type classes are not like interfaces, after  all
      (Francesco Bochicchio)
   5. Re:  Type classes are not like interfaces,        after  all
      (Thomas Davie)
   6. Re:  Type classes are not like interfaces, after  all
      (Francesco Bochicchio)


----------------------------------------------------------------------

Message: 1
Date: Fri, 23 Jan 2009 11:34:49 +0100
From: Francesco Bochicchio <[email protected]>
Subject: [Haskell-beginners] Type classes are not like interfaces,
        after all
To: [email protected]
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

Hi all.
It's about a month I'm trying to learn haskell in my spare time ( and, I
should add, with my spare neuron :-).
I made progress, but more slowly than I expected :-(. I started hasking
question on comp.lang.haskell
(I like newsgroups more than mailing lists), but then realized that this may
be a better places for my newbie
questions. So, here comes the first ...

As many  beginners coming from OOP, i made the mental equation 'type class
== interface'.
It worked well ... unitil yesterday.

Then I discovered that this piece of code  (1) is illegal in askell (ghc
gives the 'rigid type variable' error)

Num n => a :: n
a = 3 :: Integer

I also discovered that this (2) instead is legal:

Num n => a :: n
a = 3

because it is implicitely translated into (3):

Num n => a :: n
a = fromInteger 3

But I don't understand the difference between (1) and (3).  I could not find
the implementation of
fromInteger, but I suspect that it goes like this:

instance Num Integer where
    fromInteger x -> x


To me, it looks like (1) and (3) are equal, but that the compiler needs a
sort of 'formal reassurance' that
the value yielded by 'a' is of Num type. But since Integer is an instance of
Num, I expected that
(1) was already giving this reassurance. At least, it works this way with
interfaces in Java and with class pointers in C++.

But obviously there is something I don't get here ...

Anybody here can explain?

Ciao
-----
FB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://www.haskell.org/pipermail/beginners/attachments/20090123/fea27376/attachment-0001.htm

------------------------------

Message: 2
Date: Fri, 23 Jan 2009 12:07:38 +0100
From: Paul Visschers <[email protected]>
Subject: Re: [Haskell-beginners] Type classes are not like interfaces,
        after   all
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1

Hello,

It seems like you have some trouble with grasping the concept of
polymorphism in this particular case.

The function reverse has the following type:
reverse :: [a] -> [a]
This means that this function will work on a list containing any type,
and it will return that same type.

A sort function would have a type like this:
sort :: (Ord a) => [a] -> [a]
This function also doesn't care what type the list is filled with, but
does require this type to be an instance of the Ord class (so it can be
ordered).

Now an example with the Num class:
(+) :: (Num a) => a -> a -> a
This function works on any type which is an instance of Num, for example
Int and Integer.

The type of fromInteger is:
fromInteger :: (Num a) => Integer -> a
You are correct that literal numbers are internally rewritten, so 3
becomes fromInteger 3, giving the following type:
fromInteger 3 :: (Num a) => a
This means that fromInteger 3 is of type a, for any a that is an
instance of Num.

In your example (which seems to be in a bad syntax), you're saying that
a must be of type:
a :: (Num n) => n
So this is the same type as fromInteger 3. So just saying that
a = 3
or
a = fromInteger 3
will work here. The function a is polymorphic, just like sort or (+)
are. They (have to) work for any type that implements the corresponding
type class.

The problem comes from the extra type annotation:
a = 3 :: Integer
Which says that instead of being of any numeric type, a is of type
Integer. This is less general, since you can't use it when you need an
Int or a Double for example.

I hope I explained it clearly. If not please reply.

Paul

Francesco Bochicchio wrote:
> Hi all.
> It's about a month I'm trying to learn haskell in my spare time ( and, I
> should add, with my spare neuron :-).
> I made progress, but more slowly than I expected :-(. I started hasking
> question on comp.lang.haskell
> (I like newsgroups more than mailing lists), but then realized that this
> may be a better places for my newbie
> questions. So, here comes the first ...
>  
> As many  beginners coming from OOP, i made the mental equation 'type
> class == interface'.
> It worked well ... unitil yesterday.
>  
> Then I discovered that this piece of code  (1) is illegal in askell (ghc
> gives the 'rigid type variable' error)
>  
> Num n => a :: n
> a = 3 :: Integer
>  
> I also discovered that this (2) instead is legal:
>  
> Num n => a :: n
> a = 3
>  
> because it is implicitely translated into (3):
>  
> Num n => a :: n
> a = fromInteger 3
>  
> But I don't understand the difference between (1) and (3).  I could not
> find the implementation of
> fromInteger, but I suspect that it goes like this:
>  
> instance Num Integer where
>     fromInteger x -> x
>   
>  
> To me, it looks like (1) and (3) are equal, but that the compiler needs
> a sort of 'formal reassurance' that
> the value yielded by 'a' is of Num type. But since Integer is an
> instance of Num, I expected that
> (1) was already giving this reassurance. At least, it works this way
> with interfaces in Java and with class pointers in C++.
>  
> But obviously there is something I don't get here ...
>  
> Anybody here can explain?
>  
> Ciao
> -----
> FB
>  
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners



------------------------------

Message: 3
Date: Fri, 23 Jan 2009 11:15:08 +0000
From: Jan Jakubuv <[email protected]>
Subject: Re: [Haskell-beginners] Type classes are not like interfaces,
        after   all
To: Francesco Bochicchio <[email protected]>
Cc: [email protected]
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1

hi,

2009/1/23 Francesco Bochicchio <[email protected]>:
>
> Then I discovered that this piece of code  (1) is illegal in askell (ghc
> gives the 'rigid type variable' error)
>
> Num n => a :: n
> a = 3 :: Integer
>

I guess you mean:

a :: Num n => n

The problem whith your implementation of 'a'

a = 3 :: Integer

is that it provides too specific result. Its type signature says that
its result has to be of the type n for *any* instance of the class
Num. But your result is simply Integer that is just *one* specific
instance of Num. In other words it has to be possible to specialize
("retype") 'a' to any other instance of Num, which is no longer
possible because (3 :: Integer) is already specialized.

> I also discovered that this (2) instead is legal:
>
> Num n => a :: n
> a = 3
>

It's fine because 3 has the type (Num t) => t::

Prelude> :t 3
3 :: (Num t) => t

> because it is implicitely translated into (3):
>
> Num n => a :: n
> a = fromInteger 3
>

also fine:

Prelude> :t fromInteger
fromInteger :: (Num a) => Integer -> a

Sincerely,
  jan.


------------------------------

Message: 4
Date: Fri, 23 Jan 2009 14:37:12 +0100
From: Francesco Bochicchio <[email protected]>
Subject: Re: [Haskell-beginners] Type classes are not like interfaces,
        after   all
To: [email protected]
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

2009/1/23 Paul Visschers <[email protected]>

>  Hello,
>
> It seems like you have some trouble with grasping the concept of
> polymorphism in this particular case.
>
> <...>
>

I think I get the polymorphism. What I don't get is why a specialized type
cannot
replace a more generic type, since the specialized type implements the
interface
defined in the generic type.

As I tried to explain, I'm probably misled by the comparison with  OOP
languages, where polymorphism is implemented via interfaces (Java) or
abstract classes/methods (C++). For instance in Java you can write:

AbstractInterface a = new ConcreteClass();

if ConcreteClass implements AbstractInterface. The complier will handle a as
an instance of AbstractInterface, ignoring
anything that is not specifed in its declaration. This make the substitution
safe: for instance calling
a.AbstractInterfaceMethod() is fine, while calling a.ConcreteClassMethod()
gives you an error.


Now, I understand that this is not the case in haskell, and I understand the
formal reason you give for this.
What I am trying to understand is the _actual_ reason behind the formal
reason: usually a programming language place
limits to avoid ambiguity or misuse of language feature.

<...>

The problem comes from the extra type annotation:
a = 3 :: Integer
Which says that instead of being of any numeric type, a is of type
Integer. This is less general, since you can't use it when you need an
Int or a Double for example.

This is what I don't get : why yielding an Integer is not  good enough for a
function
that promises to yield a num?  What is missing in Integer?


>
>
> I hope I explained it clearly. If not please reply.
>
> Paul
>

You have been clear. I'm probably still too bound to OOP world. Thanks.


Ciao
-------
FB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://www.haskell.org/pipermail/beginners/attachments/20090123/afac5e0d/attachment-0001.htm

------------------------------

Message: 5
Date: Fri, 23 Jan 2009 14:50:47 +0100
From: Thomas Davie <[email protected]>
Subject: Re: [Haskell-beginners] Type classes are not like interfaces,
        after  all
To: Francesco Bochicchio <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"


On 23 Jan 2009, at 14:37, Francesco Bochicchio wrote:

>
>
> 2009/1/23 Paul Visschers <[email protected]>
> Hello,
>
> It seems like you have some trouble with grasping the concept of
> polymorphism in this particular case.
>
> <...>
>
> I think I get the polymorphism. What I don't get is why a  
> specialized type cannot
> replace a more generic type, since the specialized type implements  
> the interface
> defined in the generic type.
>

Suppose I declare this constant:
x :: Num a => a
x = 3 :: Integer

Now suppose I want to use that in a function.  It's type signature  
says that x is *any* numeric type i want it to be, so I'm going to add  
it to another numeric value:

y :: Complex Float
y = x + (5.3 :+ 6.93)

Unfortunately, x *can't* take the form of any Numeric type – it has to  
be an Integer, so I can't add it do Complex Floating point numbers.

The type system is telling you "while Integers may imelement the  
numeric interface, the value 3 :: Integer is not a generic value – it  
can't take the form of *any* numeric value, only a specific type of  
numeric values".

Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://www.haskell.org/pipermail/beginners/attachments/20090123/78b0413c/attachment-0001.htm

------------------------------

Message: 6
Date: Fri, 23 Jan 2009 14:51:17 +0100
From: Francesco Bochicchio <[email protected]>
Subject: Re: [Haskell-beginners] Type classes are not like interfaces,
        after   all
To: [email protected]
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

2009/1/23 Jan Jakubuv <[email protected]>

> hi,
>
> 2009/1/23 Francesco Bochicchio <[email protected]>:
> >
> > Then I discovered that this piece of code  (1) is illegal in askell (ghc
> > gives the 'rigid type variable' error)
> >
> > Num n => a :: n
> > a = 3 :: Integer
> >
>
> I guess you mean:
>
> a :: Num n => n
>

Yes. I'm not _that_ beginner  :-) (although I tend to make this mistake
quite often ).


>
> The problem whith your implementation of 'a'
>
> a = 3 :: Integer
>
> is that it provides too specific result. Its type signature says that
> its result has to be of the type n for *any* instance of the class
> Num. But your result is simply Integer that is just *one* specific
> instance of Num. In other words it has to be possible to specialize
> ("retype") 'a' to any other instance of Num, which is no longer
> possible because (3 :: Integer) is already specialized.
>

Uhm. Now I think I start to get it ...
You are saying that if a value is a Num, it shall be possible to convert it
in _any_ of the num instances?





> Sincerely,
>  jan.
>


Ciao
-------
FB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://www.haskell.org/pipermail/beginners/attachments/20090123/38a72072/attachment.htm

------------------------------

_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners


End of Beginners Digest, Vol 7, Issue 17
****************************************

Reply via email to