The lecture excercises can be downloaded from following homepage. The
lecture notes are not available, but the difference between the
written word in the notes and the spoken word in the lecture is
minimal.
http://www-i2.informatik.rwth-aachen.de/lufgi2/fp05/
The last two lectures will be
We're being clever and returning from IO not a Char, but a MyMonad Char
(mimp). Then, we run that, which either produces the answer we wanted,
or throws an error in MyMonad.
Thanks. That did the trick! :-)
Regards
However, it's still rather cumbersome, so here's a function similar to
On 23 July 2005 03:38, Duncan Coutts wrote:
The problem then as John noted is that the main loop of these toolkits
block and so the other Haskell threads would not get a chance to
schedule. So the challenge is to give the Haskell threads a chance to
schedule.
[ good description of the
John Goerzen wrote:
There was a brief discussion on #haskell today about the Haskell
standard. I'd like to get opinions from more people, and ask if there
is any effort being done in this direction presently.
I think an updated standard is overdue. I find it difficult anymore to
write any
Hello
What is the correct way to express liveness dependencies for
ForeignPtrs? I am wrapping a C library and need a way to keep
ForeignPtrs alive until the finalizer for an another ForeignPtr
has been executed.
Basically I have two types, ForeignPtr A and ForeignPtr B and a function
On 2005-07-25, Simon Marlow [EMAIL PROTECTED] wrote:
On 23 July 2005 03:38, Duncan Coutts wrote:
Thanks for describing the problem in detail, I understand it better now.
I think it comes down to this conflict:
- you want to take advantage of the fact that GHC has lightweight
green
On 2005-07-21, Bulat Ziganshin [EMAIL PROTECTED] wrote:
JG It has been awhile since I wrote a Haskell program that can compile in
JG pure Haskell 98 mode. I think it would benefit everyone if a more
JG up-to-date standard were made available.
imho, there is an unofficial standard made by
On Mon, 2005-07-25 at 13:47 +, John Goerzen wrote:
On 2005-07-25, Simon Marlow [EMAIL PROTECTED] wrote:
On 23 July 2005 03:38, Duncan Coutts wrote:
Thanks for describing the problem in detail, I understand it better now.
I think it comes down to this conflict:
- you want to take
On Mon, Jul 25, 2005 at 04:05:15PM +0100, Duncan Coutts wrote:
On Mon, 2005-07-25 at 13:47 +, John Goerzen wrote:
- our bound threads design does not require the implementation
to support lightweight threads, and hence doesn't let the
programmer take advantage of them.
In
On Mon, 2005-07-25 at 10:08 -0500, John Goerzen wrote:
On Mon, Jul 25, 2005 at 04:05:15PM +0100, Duncan Coutts wrote:
On Mon, 2005-07-25 at 13:47 +, John Goerzen wrote:
- our bound threads design does not require the implementation
to support lightweight threads, and hence
On 7/25/05, Simon Marlow [EMAIL PROTECTED] wrote:
On 23 July 2005 03:38, Duncan Coutts wrote:
The problem then as John noted is that the main loop of these toolkits
block and so the other Haskell threads would not get a chance to
schedule. So the challenge is to give the Haskell threads a
On Thu, Jul 07, 2005 at 07:08:23PM +0200, Tomasz Zielonka wrote:
Hello!
Some time ago I wanted to return the escape continuation out of the
callCC block, like this:
getCC = callCC (\c - return c)
But of course this wouldn't compile.
I thought that it would be useful to be able to
Hello Andrew,
On 7/25/05, Andrew Pimlott [EMAIL PROTECTED] wrote:
getCC :: Cont r (Cont r a)
getCC = ccc (\(c :: Cont r a - (forall b. Cont r b)) -
let x :: forall b. Cont r b = c x in x)
gives
[Error]
ghc-6.2 accepts this:
getCC :: Cont r (Cont r a)
getCC =
On Thu, Jul 07, 2005 at 07:08:23PM +0200, Tomasz Zielonka wrote:
Some time ago I wanted to return the escape continuation out of the
callCC block, like this:
getCC = callCC (\c - return c)
It seems using shift/reset is better not only in principle but in
practice as well.
module Foo
14 matches
Mail list logo
