[plt-dev] Parallel Futures Release

On Dec  7, Matthew Flatt wrote:
> At Mon, 7 Dec 2009 16:42:36 -0500, Eli Barzilay wrote:
> > perhaps it's also good to make `future' create a plain thread if
> > there is no future support?
> 
> I don't think that's the right idea.
> 
> To me, that's like suggesting that on platforms where the FFI is
> unsupported, the relevant functions should manufacture procedures
> that randomly corrupt memory. Its true that the FFI offers the
> capability to randomly corrupt memory, and that feature is
> inescapable given the FFI's job. But it's not really the point.
> 
> Similarly, by way of offering potentially reduced run times, it
> happens that futures offer some visible concurrency (and, yes, the
> docs need to be clearer about it). That's not really the point,
> though.

If reduced run-time is the only feature that matters then having
`future' raise an error makes more sense to me.  Yes, you could
pretend that you have one core and run everything sequentially, but
that won't even run into race conditions that will happen when they're
enabled.  I could naively decide that some split to futures makes
perfect sense -- but the fact that I can run it without futures
enabled doesn't help me in debugging races.

So maybe the right question is: is there any reason for allowing
non-future-enabled builds to use `future'/`touch'?

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!