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
programming language and IDE my former colleagues and I developed for
doing realtime particle effects on videogame consoles. This language
contained special constructs to avoid space/time leaks, like a dedicated
"feedback loop". 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 got back from where I started :-) Of course that will not
be the case, I'm really learning a lot. Even if it turns out Haskell is
not really suitable for games, I will have learned a lot. However it is
very important for my goal that the code looks very concise and clean,
and having to chase hidden space/time leaks would ruin the elegance.
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 *internally) that show two arrows for an
incoming/outgoing pair, so I would say the outer box of &&& would also
have two inputs and two outputs.
Best regards,
Peter Verswyvelen
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
