The idea would be to revive MLton-based support for compiling code into a library format. See MLton LibrarySupport.
This would be a significantly different use-case for MaPLe. It would allow for calling out to MaPLe to execute a parallel subroutine within a larger application. This is what Futhark does, and it does it very well. (The Futhark library interface is really nice; doing something similar in MaPLe might work well.)
A starting point would be just to allow for one subroutine to execute within MaPLe at a time, with the expectation that this subroutine is internally parallel.
More generally, a longer-term goal would be to take advantage of disentanglement to share the same scheduler and run-time system across many independent jobs simultaneously.
The idea would be to revive MLton-based support for compiling code into a library format. See MLton LibrarySupport.
This would be a significantly different use-case for MaPLe. It would allow for calling out to MaPLe to execute a parallel subroutine within a larger application. This is what Futhark does, and it does it very well. (The Futhark library interface is really nice; doing something similar in MaPLe might work well.)
A starting point would be just to allow for one subroutine to execute within MaPLe at a time, with the expectation that this subroutine is internally parallel.
More generally, a longer-term goal would be to take advantage of disentanglement to share the same scheduler and run-time system across many independent jobs simultaneously.