Parallel Execution

[trans]

Just wanted to suggest this idea. It would useful in reducing the need for swapping and local variables.

define avg (List<Int64>):
   [ \sum \size ] || div

Here I used || to mean parallel execution, meaning sum and size are applied to the list on top of the stack independently, and thus could be executed in parallel.

[trans]

Hmm... I guess the syntax would be more like:

[ { sum } { size } ] pex

In this case I used pex (parallel execution) instead of ||.

[evincarofautumn]

I was considering something like this a few years ago as part of the story for parallel & concurrent programming, as e.g. \f \g par, and I’d be happy to include it in some form. It’s not yet clear what the semantics ought to be, though, so it should probably be split into a few different forms with different behaviour. For instance:

• What is the type of par? There’s no way of expressing its general type in Kitten’s type system at the moment. It would be something like <A…, B…, C…, D…> (A…, (A… → B…, C…), (A… → B…, D…) → A…, C…, D…), but that’s not allowed because you can’t “concatenate” stack-kinded type variables like that, where B…, C… implies “some number of values, followed by some number of values”. So it would need to be restricted to a non–stack-polymorphic type like <A, B, C> (A, (A → B), (A → C) → B, C), or require a change to Kitten’s type system that I think makes it undecidable.

• Are the arguments forked in OS threads or green threads? Green threads require a nontrivial runtime with a scheduler and I/O manager, which runs counter to Kitten’s design goals unless it can be provided as a library without extra overhead, for example a Kitten wrapper around libuv.

• Should par await the results of both computations, immediately return thunks/futures that allow you to explicitly await results, take a continuation that combines the results, return just one of the results like Haskell’s par :: a -> b -> b…? All of these options have hard tradeoffs.

My general plan is not to be too opinionated about concurrency strategies, but to include a wide variety of concurrency & parallelism features, like GHC does, so programmers can select the features that are best suited to the problem at hand. I’ll write up some more detailed thoughts in another issue.

[trans]

immediately return thunks/futures

This, I think. Watched a video the other day of Ryan Dahl, creator of Node.js, and he regrets not using promises. And it seems to me to fit best with concatinative programming.