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. Re: case in monadic function (Daniel Schoepe)
2. Re: case in monadic function (Daniel Schoepe)
3. Re: case in monadic function (Kovacs David)
4. Re: Type classes are not like interfaces, after all
(Francesco Bochicchio)
5. Re: Type classes are not like interfaces, after all
(Brent Yorgey)
6. Re: Type classes are not like interfaces, after all
(Brandon S. Allbery KF8NH)
7. Re: Type classes are not like interfaces, after all
(Eric Macaulay)
8. ($) operator (John Hartnup)
----------------------------------------------------------------------
Message: 1
Date: Fri, 23 Jan 2009 16:52:39 +0100
From: Daniel Schoepe <[email protected]>
Subject: Re: [Haskell-beginners] case in monadic function
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
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?
>
> Regards, David
You can use liftM/fmap to lift a function into a monad:
case (checkPredName pn . snd) `fmap` get of ...
------------------------------
Message: 2
Date: Fri, 23 Jan 2009 17:00:43 +0100
From: Daniel Schoepe <[email protected]>
Subject: Re: [Haskell-beginners] case in monadic function
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Daniel Schoepe wrote:
> You can use liftM/fmap to lift a function into a monad:
> case (checkPredName pn . snd) `fmap` get of ...
I'm sorry, I misunderstood the problem, so this suggestion wouldn't work
either. Could you give some more information on what SemanticResult is?
------------------------------
Message: 3
Date: Fri, 23 Jan 2009 17:04:18 +0100
From: Kovacs David <[email protected]>
Subject: Re: [Haskell-beginners] case in monadic function
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Daniel Schoepe wrote:
> Daniel Schoepe wrote:
>
>
>> You can use liftM/fmap to lift a function into a monad:
>> case (checkPredName pn . snd) `fmap` get of ...
>>
>
> I'm sorry, I misunderstood the problem, so this suggestion wouldn't work
> either. Could you give some more information on what SemanticResult is?
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
It looks like this:
data SemanticResult = Ok | Error String;
------------------------------
Message: 4
Date: Fri, 23 Jan 2009 17:46:11 +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 Brent Yorgey <[email protected]>
> >
> > 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?
>
>
Yes thanks.
>From other answers, I also got the essence of it, but now I know the exact
terminology: I met the terms
'existentially quantification' and 'universal quantification' before, but
did not have any idea of their meaning.
I did not now than embarking in studying haskell I had to study phylosophy
too :-)
Joking apart, I believe something like your explanation should be reported
in tutorials helping to learn haskell, especially the
ones for people coming from other languages. As I said in my initial post
the analogy 'type class are like interfaces' is a good
starting point, but carried too far it is misleading.
Thanks again to all the posters that replied to my question. This seems a
lively forum: expect to see soon other questions from me :-).
Ciao
------
FB
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20090123/b196a1e6/attachment-0001.htm
------------------------------
Message: 5
Date: Fri, 23 Jan 2009 14:10:57 -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
On Fri, Jan 23, 2009 at 05:46:11PM +0100, Francesco Bochicchio wrote:
> 2009/1/23 Brent Yorgey <[email protected]>
>
> > 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?
> >
> >
> Yes thanks.
> >From other answers, I also got the essence of it, but now I know the exact
> terminology: I met the terms
Glad it helped! And just so you know, I made a typo; that should say
'existential quantificataion', not 'existentially quantification'. =)
-Brent
------------------------------
Message: 6
Date: Sat, 24 Jan 2009 00:14:06 -0500
From: "Brandon S. Allbery KF8NH" <[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="us-ascii"
On 2009 Jan 23, at 8:37, Francesco Bochicchio 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.
Try it this way. The declaration
> a :: Num n => n
> a = 3 :: Integer
is not the same as
> AbstractInterface a = new ConcreteClass();
because Integer doesn't implement *all* of Num, in particular nothing
needed for the Float, Double, or Complex instances. In a sense,
instances in Haskell are inverses of interfaces in Java; in Java you
accept more specific but in Haskell you accept *less* specific. This
is because an instance actually asserts a "for all possible matching
types" requirement, whereas Java asserts an "any matching type"
requirement. (Pedantically:
> a :: forall n. Num n => n
You don't have to write (and in Haskell 98, can't write, just as in
Java you can't explicitly write "forany" in an interface definition)
the "forall"; in Haskell98 (and Java respectively) it's there by
definition, in Haskell extensions it's implied for top level types for
backward compatibility.)
In many cases you can treat the two the same because the member types
happen to have an exact relationship such that "forall" and "forany"
are both satisfied, but Num is too wide (and far too complex; the
ideal structure of the Haskell numeric classes is constantly
debated). So the equivalence of typeclasses and interfaces is a "most
of the time" thing, not a definition or requirement.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [email protected]
system administrator [openafs,heimdal,too many hats] [email protected]
electrical and computer engineering, carnegie mellon university KF8NH
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20090124/e9014272/attachment-0001.htm
------------------------------
Message: 7
Date: Sat, 24 Jan 2009 13:28:41 +0000 (UTC)
From: Eric Macaulay <[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=utf-8
Francesco Bochicchio <bieffe62 <at> gmail.com> writes:
>
> 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)
>Â a :: Num n => n
> a = 3 :: IntegerÂ
A way to understand the type of a is that it has an implicit parameter:
a :: {n:Type} -> Num n -> n
Now we can see why the definition you gave doesn't work - the type n is
provided by the caller of your function which *must* return a value of
that type. If your function was called with
a {Float} _ 0.0
then you must return a Float. Your definition specifically declares you
return an integer, which is wrong.
Hope this helps,
Eric
------------------------------
Message: 8
Date: Sat, 24 Jan 2009 19:37:29 +0000
From: John Hartnup <[email protected]>
Subject: [Haskell-beginners] ($) operator
To: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hi.
I'm working through Real World Haskell, and although it's going well
(I just finished the exercise to write a glob matcher without using a
regex library, and I'm pleased as punch), I keep seeing the ($)
operator, and I'm not sure I understand its use. If the book explains
it, I've been unable to find it.
Empirically, it seems like:
a $ b c d e f
.. is equivalent to ..
a (b c d e f)
But is that it's only purpose? To placate the LISP haters by removing
parentheses?
(1 +) 2 does the same thing as (1 +) $ 2, and has the same type.
Am I missing something?
Thanks,
John
--
"There is no way to peace; peace is the way"
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 7, Issue 19
****************************************
