Daniel C. Wang
Fri, 26 Mar 2004 16:42:47 -0500
Stephen Weeks wrote:
>>It be nicer to have
>>val MLton.Thread.make_atomic : ('a -> 'b) -> 'a -> 'b
>>fun atomically f = MLton.Thread.make_atomic f ()
> It is certainly a matter of taste, since each is expressible in terms
> of the other.
Yes, of course, but as your encoding shows defining atomically in terms of
make_atomic is much simpler than the reverse.
Also, imagine I have some large library of functions I want to make atomic.
I'd rather write
val atomic_f = make_atomic f
The value restriction might require me to eta_expand it to
fun atomic_f x = make_atomic f x
fun atomic_f x = atomicly (fn () => f x)
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, but if we implement it as a runtime primitive the thunk
based approach seems to do more consing.
If you don't like the currying.. I'm just as happy with forceing me to
eta-expand things and write
fun atomic_f x = make_atomic(f,x)
anyway.. that's my take what you proposed is fine, I just think the
make_atomic approach is more natural.