At 5:22 PM -0800 1/2/08, Dave Whipp wrote:
I was reading Synopsis 4 with regards to multi core programming. It
seems to be infused with a bias towards non-parallel models of
computation. Concurrently appears to be an add-on feature -- whereas
we should have a mindset that explicit sequential constraints are
the add-on feature.
I agree with this idea in principle.
Most of the time when people are working with lists, the tasks being
done aren't conceptually dependent on being executed in a certain
order, even if for some (sequences/arrays) it is important to
reassemble results in corresponding order to the inputs. Needing
things to seemingly execute in a certain order only really matters
when I/O with extra-process entities like the user is involved, I
think. Or if the output of one iteration is an input for another,
which is rare I think. Realistically, the user will want to be lazy
and will tend to default to shorter versions of things, so making all
possible list handling tasks non-sequential by default is good
huffman coding.
As an aside, one design decision I made in my Muldis D language (for
relational DBMSs, whose spec is on CPAN) was to have a clear
separation of concerns. The language has both functional and
procedural aspects, and each routine you define in the language is
just one or the other. A function is pure functional and has no
side-effects (no monads even), and sees no globals, has no variables.
Most code one would write would be functional, and so most code gets
implicit autoparallelization. Since there are no side effects here,
it is implicitly safe. A procedure is pure-ish procedural, and each
statement in it executes (conceptually) in sequence following the
previous one, it sees globals and has side effects. Bridging the 2
is a multi-update operator; it is like an assignment statement
targeting N procedure vars; procedures only invoke functions by way
of update operators, as functions are the arguments of the latter,
functions don't invoke non-functions.
Now, I realize that for Perl 6 to adopt such an approach as this may
be undesirable to the majority, since afaik Perl 6 wants every kind
of routine to be able to have side-effects, as per Perl 5 and many
other languages, so to maximize the TIMTOADY factor.
But if it *were* possible in Perl 6 to mark routines, or have routine
kinds, that are forbidden from side-effects, which extends to
anything they invoke, then this is also a huffman-efficient and easy
to use way to auto-parallelize.
Maybe either have a new routine declaration keyword, or maybe a :pure
trait? Or conversely have that be the default and have an :impure
trait on the others. Where those things aren't just implied by other
things. Note that supporting this wouldn't change the language much
per se, but essentially be a flag to the compiler to be more strict
about some things within the scope of the routine declaration, and
therefore be more confident that it is safe to use some optimizations.
-- Darren Duncan
