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. problem 8 / 9 chapter 4, RWH (Michael Litchard)
2. Re: Type classes are not like interfaces, after all
(Ertugrul Soeylemez)
3. case in monadic function (Kovacs David)
4. Re: case in monadic function (Thomas Davie)
5. Re: case in monadic function (Thomas Davie)
6. Re: Type classes are not like interfaces, after all
(Brent Yorgey)
7. Re: Type classes are not like interfaces, after all
(Andrew Wagner)
8. Re: Type classes are not like interfaces, after all
(Jan Jakubuv)
9. Final call for papers: MULTICONF-09 (John Edward)
----------------------------------------------------------------------
Message: 1
Date: Fri, 23 Jan 2009 06:05:57 -0800
From: Michael Litchard <[email protected]>
Subject: [Haskell-beginners] problem 8 / 9 chapter 4, RWH
To: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
I noticed that in problem 4, the use of Either is needed, which hasn't
been introduced yet. I've gotten stuck on 8/9, and am wondering if
there
is something needed that hasn't been introduced yet as well?
Put another way, can problem 8/9 be done given the parts of the
language introduced thus far?
Regards,
Michael Litchard
------------------------------
Message: 2
Date: Fri, 23 Jan 2009 15:08:58 +0100
From: Ertugrul Soeylemez <[email protected]>
Subject: [Haskell-beginners] Re: Type classes are not like interfaces,
after all
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII
Francesco Bochicchio <[email protected]> wrote:
> 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.
Don't confuse this kind of polymorphism with the one you usually find in
OOP languages. Consider your original function again. Let me change
its name to make it clearer:
arbitraryNum :: Num n => n
arbitraryNum = 3 :: Integer
If 'arbitraryNum' is referenced somewhere else, then the result is
expected to be of type 'Num n => n'. It may be referenced as an
Integer, as a Float, as a complex number, etc., whatever is a Num
instance is valid here. So the value you're trying to give
'arbitraryNum' is of a too specific type. You're trying to use
information, which you don't have, namely that 'n' is an Integer. The
only information about 'n' you have is that it's a Num type.
Now the Num type class contains the fromInteger function, which you can
use to convert any Integer to a Num type. So you can write:
arbitraryNum :: Num n => n
arbitraryNum = fromInteger (3 :: Integer)
You take 3, which is an Integer, and use fromInteger to convert it to
'Num n => n'. Try to think for a moment about what the outcome of the
following function can be:
arbitraryValue :: a
arbitraryValue = ...?
You should come to the conclusion that arbitraryValue cannot return
anything, because it doesn't have any information about what it's
supposed to return. What is the type 'a'? What information do you have
about 'a'? No information. Not even enough information to construct a
value of type 'a'. The type 'a' is most polymorphic and its value is
least defined.
Of course, you can write such a function, under the strict requirement
that it never returns a value. You say, the result of such a function
is 'bottom'. For example:
bottom :: a
bottom = bottom
This function never returns. It recurses forever.
Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
------------------------------
Message: 3
Date: Fri, 23 Jan 2009 15:40:01 +0100
From: Kovacs David <[email protected]>
Subject: [Haskell-beginners] case in monadic function
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello!
I have a function like this: http://rafb.net/p/8E66FI29.html, starting
with evalState. The problem is with checkPredName cause it's return type
is SemanticError what's not a monadic value but case waiting for m a (as
the error message sais), but if I use return to checkPredName then ofc
the pattern match will fail. How can I fix this?
Regards, David
------------------------------
Message: 4
Date: Fri, 23 Jan 2009 15:52:12 +0100
From: Thomas Davie <[email protected]>
Subject: Re: [Haskell-beginners] case in monadic function
To: Kovacs David <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On 23 Jan 2009, at 15:40, Kovacs David wrote:
> Hello!
>
> I have a function like this: http://rafb.net/p/8E66FI29.html,
> starting with evalState. The problem is with checkPredName cause
> it's return type is SemanticError what's not a monadic value but
> case waiting for m a (as the error message sais), but if I use
> return to checkPredName then ofc the pattern match will fail. How
> can I fix this?
This looks a lot to me like you need to look at the Error e => Either
e applicative.
Bob
------------------------------
Message: 5
Date: Fri, 23 Jan 2009 15:54:30 +0100
From: Thomas Davie <[email protected]>
Subject: Re: [Haskell-beginners] case in monadic function
To: Kovacs David <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On 23 Jan 2009, at 15:40, Kovacs David wrote:
> Hello!
>
> I have a function like this: http://rafb.net/p/8E66FI29.html,
> starting with evalState. The problem is with checkPredName cause
> it's return type is SemanticError what's not a monadic value but
> case waiting for m a (as the error message sais), but if I use
> return to checkPredName then ofc the pattern match will fail. How
> can I fix this?
Oops, sorry, I meant monad, because this monad unfortunately doesn't
have it's associated Applicative instance (which is much nicer to work
with). You can ofc create the standard applicative instance:
instance Error e => Applicative (Either e) where
pure = return
(<*>) = ap
Bob
------------------------------
Message: 6
Date: Fri, 23 Jan 2009 09:59:49 -0500
From: Brent Yorgey <[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=us-ascii
>
> AbstractInterface a = new ConcreteClass();
In Java, if a variable has type AbstractInterface, it is
*existentially* quantified: it means, this variable references a value
of *some* type, and all you know about it is that it is an instance of
AbstractInterface. Whatever code sets the value of the variable gets
to choose its concrete type; any code that uses the variable cannot
choose what type it should be, but can only use AbstractInterface
methods on it (since that's all that is known).
However, a Haskell variable with type
var :: AbstractInterface a => a
is *universally* quantified: it means, this variable has a polymorphic
value, which can be used as a value of any type which is an instance
of AbstractInterface. Here, it is the code which *uses* var that gets
to choose its type (and indeed, different choices can be made for
different uses); the definition of var cannot choose, and must work
for any type which is an instance of AbstractInterface (hence it must
only use methods of the AbstractInterface type class).
Writing
a :: Num n => n
a = 3 :: Integer
is trying to define a universally quantified value as if it were
existentially quantified.
Now, it *is* possible to have existentially quantification in Haskell;
I can show you how if you like, but I think I'll stop here for now.
Does this help?
-Brent
------------------------------
Message: 7
Date: Fri, 23 Jan 2009 10:20:47 -0500
From: Andrew Wagner <[email protected]>
Subject: Re: [Haskell-beginners] Type classes are not like interfaces,
after all
To: Brent Yorgey <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I think this explanation is positively brilliant. Byorgey++
On Fri, Jan 23, 2009 at 9:59 AM, Brent Yorgey <[email protected]>wrote:
> >
> > AbstractInterface a = new ConcreteClass();
>
> In Java, if a variable has type AbstractInterface, it is
> *existentially* quantified: it means, this variable references a value
> of *some* type, and all you know about it is that it is an instance of
> AbstractInterface. Whatever code sets the value of the variable gets
> to choose its concrete type; any code that uses the variable cannot
> choose what type it should be, but can only use AbstractInterface
> methods on it (since that's all that is known).
>
> However, a Haskell variable with type
>
> var :: AbstractInterface a => a
>
> is *universally* quantified: it means, this variable has a polymorphic
> value, which can be used as a value of any type which is an instance
> of AbstractInterface. Here, it is the code which *uses* var that gets
> to choose its type (and indeed, different choices can be made for
> different uses); the definition of var cannot choose, and must work
> for any type which is an instance of AbstractInterface (hence it must
> only use methods of the AbstractInterface type class).
>
> Writing
>
> a :: Num n => n
> a = 3 :: Integer
>
> is trying to define a universally quantified value as if it were
> existentially quantified.
>
> Now, it *is* possible to have existentially quantification in Haskell;
> I can show you how if you like, but I think I'll stop here for now.
>
> Does this help?
>
> -Brent
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20090123/cafabf49/attachment-0001.htm
------------------------------
Message: 8
Date: Fri, 23 Jan 2009 15:41:18 +0000
From: Jan Jakubuv <[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 Francesco Bochicchio <[email protected]>:
>
>
> 2009/1/23 Jan Jakubuv <[email protected]>
>>
>> hi,
>>
>> 2009/1/23 Francesco Bochicchio <[email protected]>:
>> >
>> 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?
>
Well, in this case of the above constant yes. The main point here is
that when you want to implement a function of a type say (Num a => a
-> a) then the implementation has to work for *all* instances of the
class Num. Usually you can use only "abstract" functions defined in a
class declaration to write such functions.
Try to start with some function that mentions the quantified type in
one of its arguments. They are easier to understand. Constants like
(Num a => a) and functions like (Num a => Bool -> a) are rare (also
they have a special name I can not recall ;-).
Also note that you can take:
a :: (Num t) => t
a = 3
and then specialize it:
spec = (a :: Integer)
Sincerely,
jan.
------------------------------
Message: 9
Date: Fri, 23 Jan 2009 07:51:38 -0800 (PST)
From: John Edward <[email protected]>
Subject: [Haskell-beginners] Final call for papers: MULTICONF-09
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
The 2009 Multi Conference in Computer Science, Information Technology and
Control systems and Computational Science and Computer Engineering
(MULTICONF-09) (website: http://www.PromoteResearch.org) will be held during
July 13-16 2009 in Orlando, FL, USA. We invite draft paper submissions. The
event consists of the following conferences:
· International Conference on Artificial Intelligence and Pattern
Recognition (AIPR-09)
· International Conference on Automation, Robotics and Control Systems
(ARCS-09)
· International Conference on Bioinformatics, Computational Biology,
Genomics and Chemoinformatics (BCBGC-09)
· International Conference on Enterprise Information Systems and Web
Technologies (EISWT-09)
· International Conference on High Performance Computing, Networking
and Communication Systems (HPCNCS-09)
· International Conference on Information Security and Privacy (ISP-09)
· International Conference on Recent Advances in Information Technology
and Applications (RAITA-09)
· International Conference on Software Engineering Theory and Practice
(SETP-09)
· International Conference on Theory and Applications of Computational
Science (TACS-09)
· International Conference on Theoretical and Mathematical Foundations
of Computer Science (TMFCS-09)
The website http://www.PromoteResearch.org contains more details.
Sincerely
John Edward
Publicity committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20090123/cac1ed10/attachment.htm
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 7, Issue 18
****************************************
