allowing non-sequentiality in IO

[D. Tweed]

On Sat, 16 Feb 2002, Hal Daume III wrote:

> The reason I ask is that I'm generating a FSM description file and it
> doesn't matter which order I list the transitions in.  I'm curious whether
> I could get the program to run any faster if I don't care about order.

I'm a bit confused here: assuming that by faster you mean decreased
_total_ run-time (and not becasuse, e.g., you're piping the input to
another program and want an description lines to be produced at regular
intervals), why is the IO monad ordering going to be the big factor in
what determines this? I wouldn't imagine that in a non-concurrent Haskell
program there's any `locking' of IO resources so there can't be contention
for that. I can imagine that you could dramatically decrease run-time on
machines with low memories by re-ordering some computations so that the
heap size is always small (and so you get less swapping) rather than
generating lots of heap items long before they are used, this would
presumably be going on in the standard functional parts of your program.
And here you only ever get (ignoring the results of strictness analysis)
Haskell's standard evaluation order. (I.e., you could write a monadic
wrapper which processes a list of lazily produced transition lines,
outputting each new line as it becomes available, but I can't think of any
way to write the functional part of the computation so that it constructs
the list of transitions in such a way that each line is constructed as
early as possible.)

___cheers,_dave_________________________________________________________
www.cs.bris.ac.uk/~tweed/|`...heat generated by its microprocessors will
email:tweed@cs.bris.ac.uk|slope upward exponentially, reaching the power
work tel:(0117) 954-5250 |density of a nuclear reactor before 2010'-Intel