Me:
>> Yes, it makes a lot of sense. The parallel or above is a classical example
>> of a function for which there exists no semantically correct sequential
>> evaluation order of its arguments (i.e., an evaluation order where an
>> argument is evaluated in full before the evaluation of the next argument
>> starts). Therefore, it has usually been discarded as infeasible to implement
>> since the in the worst-case scenario its evaluation may require that you
>> spawn off an exponential number of concurrent threads (imagine a function
>> calling the parallel or recursively on both sides).
Adrian Hey:
>This is the biggest problem I think.
>Implementation would be very difficult. It requires a compiler smart
>enough to only start separate threads if it's going to make some
>difference to the termination properties, and a very efficient
>implementation capable of supporting an arbitary number of threads.
>I don't see the potential problem with infinite nos. of threads as
>a reason not to do this though. Haskell as it stands provides plenty of
>opportunity to screw up with infinite things :-)
This is not to discourage you (I think your idea is quite interesting), but
the parallel or actually provided a big headache to early researchers in
semantics. It pops up in the standard functional domains used for
denotational semantics and its non-sequential nature was seen as kind of
unnatural. (For instance, it cannot be encoded in the lambda calculus.)
Great efforts were spent do define function domains where non-sequential
functions like the parallel or did not exist. I don't think these efforts
really ever succeeded.
I have always felt that these efforts were somewhat misguided.
(Theoreticians out there, please don't kill me!) There is nothing strange
with parallel threads, or a function that requires parallel threads for its
faithful implementation. But there might be a serious problem with
efficiency. There have been attempts in this direction: Early
implementations of the language Oz, for instance, used a parallel strategy
where a thread was spawned off for each call. I think it was done this way
just because it was simple to implement (Oz is concurrent, so they needed to
support parallel threads anyway.) In later version of Oz this strategy has
been abandonded, though., for efficiency reasons I think.
Bj�rn Lisper
