Svein Ove Aas wrote:
Certain people (*cough*quicksilver*cough*) thought it'd be nice of me to inform you of what I've been up to the last few days re: reactive bug-fixing, so here's an update.
- I've rewritten unamb, fixing all the issues I've managed to find (relating to nested unamb invocations, mostly) and having it throw a BothBottom exception if both values are a finite bottom.
Why not choose one of the two existing bottoms and throw that? It'd be like the semantics of Haskell's imprecise exceptions anyway...
I'm now trying to fix the joinE/>>=/mappend problems, but that might take a while. Meanwhile, more eyes on the rewritten code is better, so I've attached it; there hasn't been an official release yet.
okay I read it! I just have some questions / suggestions to comment things better in the code, currently
unamb = ... where retry act = act `catch`
the definition of retry here makes almost no sense to me... but as I understand it, it's completely an RTS hack. First I'd put a comment saying so, and then explain exactly what problem it avoids and how it does that, with more comments. in "race": How does your current version kill descendent threads any better than "Simple version"? Oh I see it puts the `finally` kill-the-threads in, around the read-the-mvar ("descentent" just means the two threads that "race" spawns, not the threads spawned by those two threads?). But I'm not sure what the *extra* complication is for, that's beyond "Simple version"'s complexity? Is it just in order to be able to throw BothBottom at the right time (a worthy goal)? I also don't understand why putCatch wants to prevent certain kinds of exceptions from escaping the thread? (Would they emit into the calling-thread that `race` runs in? or what is the difference? How did you choose the three or four things to catch; and what is wrong with NonTermination?) thanks! -Isaac