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: Why is this not a "category"? (Kim-Ee Yeoh)
2. Re: Help on first program (John M. Dlugosz)
3. Re: understanding MTL (Karl Voelker)
----------------------------------------------------------------------
Message: 1
Date: Sun, 30 Mar 2014 02:29:01 +0700
From: Kim-Ee Yeoh <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Why is this not a "category"?
Message-ID:
<CAPY+ZdQwLO3WB_TO0vJDmyUNbnqyG18LrrCqjdre_d=hqjt...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Sat, Mar 29, 2014 at 12:18 PM, John M. Dlugosz
<[email protected]>wrote:
> "(Harder.) If we add another morphism to the above example, it fails to be
> a category. Why? Hint: think about associativity of the composition
> operation."
One has to be careful with crowd-sourced wikipedia-like learning material.
They aren't always helpful, although 80% of the time they are.
In this case, the 2 exercises probably belong right after the section on
"Category Laws" but _before_ "Hask, the Haskell category."
That way, there's less confusion about what the exercises refer to and what
they do NOT refer to. They certainly don't refer to Hask.
That said, the exercises presume acquaintance with partial orders / posets
so there's some web-trawling to be done if the requirement is unmet.
And I'll also argue that the exercises aren't helpful. They may have their
place in some musty math textbook. But for a general audience, it's like
having some obscure concept (category) explained in terms of another
obscure concept (partial order), with no-one getting any wiser.
p.s. if you are still stuck email me off-list for the answer.
-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140330/3dca9f83/attachment-0001.html>
------------------------------
Message: 2
Date: Sat, 29 Mar 2014 18:42:08 -0500
From: "John M. Dlugosz" <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] Help on first program
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 3/28/2014 11:22 PM, Brandon Allbery wrote:
> Can they be spread out among different source files or be discontiguous
> within one file?
>
> Neither one; they must be together in the same file with nothing intervening,
> since they
> get rewritten into a single function. They also must all have the same number
> of
> parameters, even if one of them could take advantage of eta reduction
Many thanks.
------------------------------
Message: 3
Date: Sat, 29 Mar 2014 21:19:14 -0700
From: Karl Voelker <[email protected]>
To: "The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell" <[email protected]>
Subject: Re: [Haskell-beginners] understanding MTL
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
On Sat, Mar 29, 2014, at 03:32 AM, Dennis Raddle wrote:
He then said I don't want to put StateT and ErrorT in the same newtype
declaration, so it would be something like
newtype Er m a = Er { runEr :: StateT ErState m a }
On this point I'm confused. I don't know how to get from a line like
the above to eventually making a type that combines error handling and
state. Furthermore I need to define instances for things like
MonadError.
I don't think there was really anything wrong with your prior approach.
It seems like the advice you got was to make the Er type more generic,
which may or may not be appropriate in the context of your application.
At this point, Er is now a monad transformer. It's not really a monad
until the "m" type parameter is instantiated. For example:
type ErActuallyAMonad a = Er Error a
Notice that the value inside the newtype will then be a "StateT ErState
Error a", which is almost the same as the "ErrorT (State ErState) a"
you had originally.
He got me started with the line
instance MonadError e m => MonadError e (Er m) where
... define throwError and catchError which I have no idea how to do ...
An instance declaration like this is saying that if you have a
MonadError monad m, and you transform it with the transformer Er, then
the resulting monad will also be a MonadError monad. These instance
declarations are pretty common in the MTL.
-Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140329/33f22a88/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 69, Issue 47
*****************************************
