Paul L wrote:
We recently wrote a paper about the leak problem. The draft is at
http://www.cs.yale.edu/~hl293/download/leak.pdf. Comments are welcome!
Interesting. Now that I know the basic Haskell stuff these arrows make
much more sense. However, they look *very* similar to a visual
On Wed, 26 Sep 2007, Peter Verswyvelen wrote:
I hope I won't come to the conclusion that after one year learning the
cool lazy functional programming language Haskell (which I want to use
for making simple videogames in a clean way for teaching),
I haven't tested it, but know of the
That looks nice, but HGL does not work on Windows anymore does it?
Thanks,
Peter
-Original Message-
From: Henning Thielemann [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 11:44 AM
To: Peter Verswyvelen
Cc: Haskell-Cafe
Subject: Re: [Haskell-cafe] Troubles understanding
Peter Verswyvelen wrote:
Paul L wrote:
A minor detail in your paper: on page 7, you represent *(d) sf1 sf2 *as
a big box taking one input and producing two outputs. The input is
internally split using a Y. This does not seem consistent with the other
boxes (e.g. *first *or *loop
Henning Thielemann wrote:
On Wed, 26 Sep 2007, Peter Verswyvelen wrote:
I hope I won't come to the conclusion that after one year learning
the cool lazy functional programming language Haskell (which I want
to use for making simple videogames in a clean way for teaching),
I haven't tested it,
] Troubles understanding memoization in SOE
Peter Verswyvelen wrote:
Paul L wrote:
A minor detail in your paper: on page 7, you represent *(d) sf1 sf2
*as
a big box taking one input and producing two outputs. The input is
internally split using a Y. This does not seem consistent with the other
that was the cause of my videogame
addiction :)
Cheers,
Peter
-Original Message-
From: Paul Hudak [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 2:39 PM
To: Peter Verswyvelen
Cc: Henning Thielemann; Haskell-Cafe; [EMAIL PROTECTED]
Subject: Re: [Haskell-cafe] Troubles understanding
paul.hudak:
Henning Thielemann wrote:
On Wed, 26 Sep 2007, Peter Verswyvelen wrote:
I hope I won't come to the conclusion that after one year learning
the cool lazy functional programming language Haskell (which I want
to use for making simple videogames in a clean way for teaching),
I
On Wed, 26 Sep 2007, Don Stewart wrote:
And don't forget these three games that got mentioned during the week.
Octane Mech:
http://berlinbrowndev.blogspot.com/2007/09/octane-mech-opengl-haskell-based-mech.html
OpenGL Tetris:
Paul L wrote:
We recently wrote a paper about the leak problem. The draft is at
http://www.cs.yale.edu/~hl293/download/leak.pdf. Comments are welcome!
I'm trying to understand the following in this paper:
(A) repeat x = x : repeat x
or, in lambdas:
(B) repeat = λx → x : repeat x
This
Peter Verswyvelen wrote:
Let me see if I understand this correctly. Since I'm an imperative
programmer, I'll try a bit of C++ here.
struct Cell : Value
{
Value* head;
Value* tail;
};
So in (A) and (B), a Cell c1 is allocated, and c1-head would be a
pointer to x, and c1-tail would be a
Thanks Paul Paul for the answers. I'll certainly read the paper Paul Liu
reported.
I just deleted 100 lines of text which explained my problem in more detail, and
while I was explaining it, I answered it myself. Typical. I thought the lambda
function that memo1 returns would be called over
Peter Verswyvelen wrote:
I thought the lambda function that memo1 returns would be called over and over
again, and instead of reevaluating the stream from the beginning, it would just
return the stream since it is in the cache, but actually it just gets called
twice in recursive situations:
-Original Message-
From: Paul Hudak [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 25, 2007 2:45 PM
To: Peter Verswyvelen
Cc: Haskell-Cafe; Paul Liu; [EMAIL PROTECTED]
Subject: Re: [Haskell-cafe] Troubles understanding memoization in SOE
Peter Verswyvelen wrote:
I thought the lambda function
On Sat, 22 Sep 2007, Peter Verswyvelen wrote:
Hi,
in SOE, the following memoization function is implemented:
memo1 :: (a-b) - (a-b)
memo1 f = unsafePerformIO $ do
cache - newIORef []
return $ \x - unsafePerformIO $ do
vals - readIORef cache
case x `inCache` vals of
-
From: Henning Thielemann [mailto:[EMAIL PROTECTED]
Sent: Monday, September 24, 2007 1:44 PM
To: Peter Verswyvelen
Cc: Haskell-Cafe
Subject: Re: [Haskell-cafe] Troubles understanding memoization in SOE
On Sat, 22 Sep 2007, Peter Verswyvelen wrote:
Hi,
in SOE, the following memoization function
puzzle :)
Peter
-Original Message-
From: Henning Thielemann [mailto:[EMAIL PROTECTED]
Sent: Monday, September 24, 2007 1:44 PM
To: Peter Verswyvelen
Cc: Haskell-Cafe
Subject: Re: [Haskell-cafe] Troubles understanding memoization in SOE
On Sat, 22 Sep 2007, Peter Verswyvelen
Hi Peter. Paul Liu replied well to your later email, but I just wanted
to point out that memoization is not being used here to make the
recursion work -- lazy evaluation does just fine. Rather, the
memoization is being used for what it's normally good for, namely, to
avoid repeated
Hi,
in SOE, the following memoization function is implemented:
memo1 :: (a-b) - (a-b)
memo1 f = unsafePerformIO $ do
cache - newIORef []
return $ \x - unsafePerformIO $ do
vals - readIORef cache
case x `inCache` vals of
Nothing - do let y = f x
19 matches
Mail list logo
