Re: [stack] Parallel evaluation

Ruurd <[email protected]> wrote:
> Joy is tree-structured.

When you consider list and function literals, I admit there's a
syntactic tree structure (and for Joy, function literals are essential
to writing programs). But concatenative languages in general are not
intrinsically tree-structured; applicative languages are, since every
function call forms the root of a subtree. It's possible to define a
library that allows one to write entirely flat programs in any
concatenative language. (My current efforts on this front show that it
is ugly and inconvenient when one attempts to be 100% "flat"; as with
most things in programming, being satisfied with 99% purity is much
better than going for 100%.)

> Also, the only thing that is usually needed to change a sequential program into a parallel evaluated program is to change map into pmap.

Unless I missed something, that wasn't what was being discussed; we
were talking about implicit compiler support for parallelism, the sort
of thing that allows compilers to generate decent code for modern
(superscalar) architectures.

Also... In general, "changing map into pmap" is insufficient (there
are MANY other places for parallelism, and an explicit map is too
rare) and often incorrect (map consumes and generates an ordered list,
so computing in parallel simply means that the runtime will have to
assemble the result list in the sequential order).

> When I thought about parallel evaluation, because computations can be done while the program is waiting for I/O to finish, I was advised not to use parallel evaluation for that purpose. It would be simpler to use non-blocking I/O functions.

Exactly -- one needs profound support for parallel computation, not
merely a few quick changes.

> When thinking about a parallel language out of the many languages that claim to be parallel the only language that makes any sense is Erlang. Now that desktop processors are multicore, there is a lot of interest in a good parallel language with a nice and familiar syntax that is acceptable for mainstream programmers.

I largely agree. Except that I'm not sure about Erlang being the only
thing that "makes any sense"; there are many other options that do
much the same thing. Erlang is simply very well tested and supported.
I'd like to see what might happen with a parallel version of k4 (a
proprietary language from kx.com, a remote derivative of APL); more
appropriately for this group, the concatenative languages Enchilada
and Ripple, both of which are intrinsically parallel (although
Enchilada is probably TOO parallel to be practical).

-Wm