You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One big advantage of doing it this way is that we can stay "compatible" with MLton, in the sense that we can sync the MLton library with mainline MLton. In MPL, we would just explicitly deprecate certain functionality (e.g. MLton.GC.pack would raise a "not supported" exception)
The text was updated successfully, but these errors were encountered:
Something I've been considering is making a MPL-specific structure with, for example:
MPL.Parallel
with fork/join primitivesMPL.Concurrency
with atomics, synchronization prims, etc.MPL.Unsafe
with e.g. array allocationMPL.GC
for GC statistics and other controlsThis would help address the issues #106 and #77.
One big advantage of doing it this way is that we can stay "compatible" with MLton, in the sense that we can sync the MLton library with mainline MLton. In MPL, we would just explicitly deprecate certain functionality (e.g.
MLton.GC.pack
would raise a "not supported" exception)The text was updated successfully, but these errors were encountered: