I have been thinking over the issue of curried application. There is a problem with my statement that the types
'a -> 'b -> 'c 'a 'b -> 'c are the same: it is not always true in the presence of effects. Let me try to break this down. Consider an application f a b c where f has type (fn 'a 'b 'c -'d). Obviously no problem here. Okay. Now consider when f has type (fn 'a 'b -> (fn 'c -> 'd)). We can handle that by doing type-driven parenthesization, treating the application as: (f a b) c so far so good, ignoring effects. But how about if f, having type (fn 'a 'b 'c -> 'd) is applied to a single argument, as in: f a The rewrite here requires more than introducing parenthesis. It requires that we re-write this as: ((lambda (a) (lambda (b c) (f a b c))) a) Note that the inner lambda is closed over the value of a, so an *allocation* is performed to construct a closure for that procedure. But when effects are introduced matters are less pretty: (pure fn 'a 'b -> 'c) == (pure fn 'a -> (pure fn 'b -> 'c)) (pure fn 'a 'b -> 'c) != (pure fn 'a -> (impure fn 'b -> 'c)) (pure fn 'a 'b -> 'c) != (impure fn 'a -> (pure fn 'b -> 'c)) So what this means is that effects and function arity interact because of closure construction. In hindsight this is blazingly obvious, and I'm now glad that I insisted on having multi-argument procedures! This can all be handled with single-argument procedures, but (a) only if we assume that certain optimizations are mandatory and (b) only when the procedure being applied is statically known. The minute we get procedure pointers into the picture, arity becomes significant again. So my current view is that (a) we can support the curried syntax, but (b) we nonetheless want to retain n-ary procedures. Does anybody see anything here that I am missing that would change this picture? Does anybody care to offer a completely different point of view on this? shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
