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
Paul L wrote: 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