Functional Muti-threading

[Daniel Keep]

janderson wrote:
> [snip]
> 
> What do you think?

"I think all the right thinking people in this country are sick and 
tired of being sick and tired of being sick and tired.  I know I'm not, 
and I'm sick and tired of being told that I am!"

Or something to that effect...

*ahem*

This is one of the things I've thought about quite a bit over the years. 
  What you call "threadable" I call "pure", as in a pure function. 
Basically, a pure function is one which has *no* side effects.  If a 
function has no side effects, then it doesn't matter when it gets 
executed.  The nice thing is that "pure function" is more well-defined 
than "threadable" :3

The idea comes from functional programming languages like LISP.  If 
you're writing pure LISP, then all of your functions are pure, which 
leaves LISP free to thread your program however it likes.

I thought about suggesting that the compiler add a purity check in the 
same vein as inlining: any function found (or marked) as pure could be 
threaded off by the compiler without any adverse side-effects.

Of course, I never did since this would be a huge amount of work.  Which 
got me thinking about other kinds of multithreading.  Which is why I 
wrote my "future" implementation (not to be confused with "futurism" :P).

To be honest, I think we are more likely to see array operations *first* 
(ie: a[] = b[] + c[] as an element-wise addition) than this stuff.  The 
nice thing is that array operations can also be parrallelised (using 
things like SIMD, or even multi-threaded SIMD on multi-core systems) but 
much more easily.

So yeah, anything that makes multithreading easier is a good thing in my 
books.

</2¢>

	-- Daniel