[MLton-user] curried function definition and pattern destructuring

[Andreas Rossberg]

Stephen Weeks wrote:
>>Mh, how would the difference be externally observable under the
>>dynamic semantics as specified in the Definition? I believe it
>>isn't.
> 
> I agree (assuming T is the only variant in its datatype).

Indeed, the pattern has to be exhaustive.

>>>  fun f (T {x, ...}) y = e
>>>  fun f (T {x, ...}) = fn y => e
> 
> I agree (under the same proviso).  As to whether one is allowed to
> transform the latter into the former, it depends on how concerned you
> are about space safety.  In MLton, we are paranoid about space safety,
> and want to give the programmer as much a chance as possible to reason
> about the space usage of his program.  So, I'd still say that the two
> are not equivalent -- MLton is allowed to asymptotically improve space
> usage, but not to make it asymptotically worse.

I understand, except for the last part. Just out of interest, could this 
transformation ever worsen space behaviour? The only example I can think 
of is deconstructing a large value into many subvalues, such that the 
closure environment becomes large. But as far as I can see, it can never 
take more space than the original value (mh, except for redundant 
as-patterns, which should be easy to get rid of), so that we keep a 
constant factor even if the original does not become garbage.

- Andreas

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