AffLin and curried arguments

[davidweichiang]

The tests added in commit fbebfeb07b718d74f38e0c8ae999c814505177d0 fail because of the optimization

L[\x. \y. t] = <\x. \y. L[t], ()>

rather than

L[\x. \y. t] = <\x. <\y. L[t], ()>, ()>

However, this doesn't allow the lambda to be partially applied and then discarded.

Currently, the code doesn't know that the inner lambda isn't wrapped inside a tuple, and attempts to un-tuple it.

I think the right solution is just to undo this optimization. However, it will be slower. Is it difficult to statically determine when a lambda might be affinely used?

[ccshan]

Is it difficult to statically determine when a lambda might be affinely used?

It's probably a fix point computation in the boolean semiring :-P

But even without, what if we tell programmers to tuple their arguments?

[davidweichiang]

I think that sounds inconvenient but I guess I don't really know how useful affine lambdas are.

[davidweichiang]

By #96 I don't mean to close off discussion of

• Not automatically wrapping lambdas and additive tuples inside additive tuples and making it manual instead
• Changing the syntax and/or documentation to discourage currying or partial application

I just figure it's better to remove bugs before thinking about changes.