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

Reply via email to