[MLton] Ongoing parallel runtime work

[Matthew Fluet]

On Tue, 22 Jan 2008, Eric McCorkle wrote:
> On Jan 22, 2008, at 11:55 AM, Matthew Fluet wrote:
>> These sound like fairly extensive changes to both the runtime and the 
>> compiler proper.  Is all of this implemented and working, or just 
>> work-in-progress changes?
>
> I'm envisioning some sort of -parallel flag, which will compile for the 
> parallel runtime.  There shouldn't be too many actual compiler changes, truth 
> be known, just some changes in the handling of pointers, the formatting of 
> objects, and allocating memory.

Those are some rather fundamental assumptions of the compiler.  (Not to 
mention that you suggested changing contiguous stacks to heap allocated 
stack frames, which make changes to call/return and raise conventions.) 
While it is true that the front-end and middle-end would be mostly 
agnostic, you'll likely need to touch much of the back-end.

> In fact, the threading will become much simpler, as the thread code is 
> all external.

Under the current runtime, much of the thread code is implemented in SML. 
What does it mean that 'the thread code is all external'?

> The scheduler is finished and withstands some rather harsh random testing.

Testing with MLton-compiled SML programs or testing with a scheduler 
specific harness?

I know that your project has been a "standalone runtime for concurrent 
functional languages", with the hope that it could serve as an alternate 
runtime for MLton.  I'm simply curious about the extent to which it has 
actually been integrated with MLton (or MLton integrated with it).