[MLton] MLton.Thread.atomically

[Stephen Weeks]

> Yes, of course, but as your encoding shows defining atomically in terms of 
> make_atomic is much simpler than the reverse.

?? Let's put them side by side.

  fun atomically f = make_atomic f ()
  fun make_atomic f x = atomically (fn () => f x)

Neither is "much simpler".  They are both trivial.

> Also, imagine I have some large library of functions I want to make
> atomic.
> 
> I'd rather write
...
> fun atomic_f x = make_atomic f x
> 
> rather than
> 
> fun atomic_f x = atomicly (fn () => f x)

Makes sense.

> The atomically approach is creating an extra closure, which I guess is no 
> big deal in the MLTon case as long as MLton.Thread.make_atomic is not a 
> runtime primitive

Right.  MLton will see through all of this syntactic noise.

> but if we implement it as a runtime primitive the thunk 
> based approach seems to do more consing.

Interesting.  We never pass functions to runtime primitives in MLton
so this didn't occur to me.

> anyway.. that's my take what you proposed is fine, I just think the 
> make_atomic approach is more natural.

I don't disagree that make_atomic is useful.  I even don't disagree
that it might be more common.  I simply find that the type

	('a -> 'b) * 'a

is less clear than

	unit -> 'a

because, without careful thought, it's not clear that the only thing
that can be done is to apply the first component to the second.
Whereas with the thunk it is clear that the only thing that can be
done is thaw it.  To me, the type says more, and I rate that very
highly in interface design.