[MLton-user] curried function definition and pattern destructuring

[Andreas Rossberg]

Stephen Weeks wrote:
> 
> It is arguably a design mistake that the Definition does what it does;
> but, since it does, it useful to keep in mind that these two
> definitions of 'f' are not equivalent.
> 
>   fun f (T {x, ...}) y = e
>   fun f (T {x, ...}) = fn y => e

Mh, how would the difference be externally observable under the dynamic 
semantics as specified in the Definition? I believe it isn't. 
Consequently, it would be a valid optimization to transform the former 
into the latter.

The only situation where the difference is observable is where any but 
the last curried argument contains a ref pattern, because then the time 
of dereferencing is changed by the transformation. In all other cases it 
seems to be safe.

- Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de