Thanks for an excellent clarification. I have been known to be rather
daft at times so I just wanted to make sure I understood everything
correctly. Thanks!
/M
On Sun, Jan 28, 2007 at 12:56:56 +0200, Yitzchak Gale wrote:
>Hi Magnus,
>
>You wrote:
>>This piece has type problems. I couldn't get
Hi Magnus,
You wrote:
This piece has type problems. I couldn't get ghci to
accept it without making some changes...
You are absolutely correct, and I apologize for the errors.
I will try one more time to give a corrected version below.
Let me point out, though, that this does not exactly sol
You are suggesting later in this thread that the old ListT could be used
to solve my initial problem. I don't see how, so I'm wondering if you'd
mind sorting some things out for me?
On Tue, Jan 23, 2007 at 11:59:58 +0200, Yitzchak Gale wrote:
[..]
>test = do
> a <- liftIO getChar
> guard $ a /= '
Dan Piponi wrote:
No, definitely the new one. The old one is:
newtype ListT m a = ListT { runListT :: m [a] }
which treats the entire list as one uninterleavable lump.
The new one is:
data MList' m a = MNil | a `MCons` MList m a
type MList m a = m (MList' m a)
newtype ListT m a = ListT { run
Yitzchak,
Hmm, I thought it was the old one...
No, definitely the new one. The old one is:
newtype ListT m a = ListT { runListT :: m [a] }
which treats the entire list as one uninterleavable lump.
The new one is:
data MList' m a = MNil | a `MCons` MList m a
type MList m a = m (MList' m a)
I wrote:
You have written a great explanation of how
ListT works by writing out its definitions in an
interesting way!
Dan Piponi wrote:
I put quite a bit of time into understanding why the old ListT isn't a
monad [1]. But I thought I didn't yet understand the new one. Now I
see that I did, I
On 1/23/07, Yitzchak Gale <[EMAIL PROTECTED]> wrote:
You have written a great explanation of how
ListT works by writing out its definitions in an
interesting way!
I put quite a bit of time into understanding why the old ListT isn't a
monad [1]. But I thought I didn't yet understand the new one.
Magnus Therning wrote:
I assume you aren't talking about the standard ListT, the one that
forces unnecessary strictness, right? But rather how ListT ought to be
implemented.
Ha! There it is again! :)
Regards,
Yitz
___
Haskell-Cafe mailing list
Haske
On Tue, Jan 23, 2007 at 11:59:58 +0200, Yitzchak Gale wrote:
>Hi Dan,
>
>You have written a great explanation of how ListT works by writing out
>its definitions in an interesting way!
I assume you aren't talking about the standard ListT, the one that
forces unnecessary strictness, right? But rath
Hi Dan,
You have written a great explanation of how
ListT works by writing out its definitions in an
interesting way!
Dan Piponi wrote:
A slightly different approach that doesn't use anything unsafe:
A list of type [Char] is essentially a
solution to the equation
X = Maybe (Char,X)
Yes. In fa
Magnus Therning asked:
but how do I go about creating a finite list, e.g. a list that ends as
soon as 'q' is pressed?
A slightly different approach that doesn't use anything unsafe:
What you want is to return something like an IO [Char] but it needs to
be able to interleave IO. A list of type
Hi,
Am Freitag, den 19.01.2007, 11:19 +0100 schrieb Ferenc Wagner:
> Magnus Therning <[EMAIL PROTECTED]> writes:
>
> > Thanks for all the excellent answers to my original question. Somehow
> > it feels like I advanced and got one level closer to a black belt in
> > Haskell due to this; I've now
On Fri, Jan 19, 2007 at 11:19:16 +0100, Ferenc Wagner wrote:
>Magnus Therning <[EMAIL PROTECTED]> writes:
>
>> Thanks for all the excellent answers to my original question. Somehow
>> it feels like I advanced and got one level closer to a black belt in
>> Haskell due to this; I've now legitimately
13 matches
Mail list logo
