Jost Berthold wrote:



execution unit to do something more useful.


Yes: the compiler could do a strictness analysis and hopefully (safe analysis)
tell wether "neededList" is needed by "mungeForResult". In the case of
algebraic data structures (like lists), things get a bit more complex
(different degrees of strictness);
Special data-parallel language concepts weave an automatism into the
data structures they aim at.
But apparently, the programmer should know very well if this is the case,
and she may explicitly opt for speculative evaluation, or not. Explicit or
"implemented" (which means in a way automatic): Garbage collection in a
parallel system is able to detect unneeded results and will stop the
computation in this case.


I wait for the day the compiler does it all for us... One of the reasons for adopting
Haskell is the way functional languages parallel hardware implementations
(in VHDL recursion = registers ... and parameters = wires). With an imperative
language all the side effects get in the way (side-effects = memory access over
a bus).


It seems to me the compiler should sort out all the possible parallelisations, and
static dependancies, the RTS should deal with dynamic-dependancies and
speculative execution...


It would be nice if the compiler would also calculate a cost metric for funtions, so
that the RTS could make intelligent architecture dependant decisions on whether
to run a dependancy sequentially on the current CPU, or in parallel on another.


But of course to me the beauty is that not one like of source code should need
to be modified...


   Keean.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Reply via email to