On Mon, Feb 16, 2015 at 6:55 AM, Keean Schupke <[email protected]> wrote:
> Sometimes it might be better to read my responses in reverse order :-) > I had seen that you moved to multiple left-side arguments, but it seemed in subsequent discussion that you were still playing with the idea yourself. Also, newly arriving messages in GMail don't (initially) appear in chronological position. In any case, very sorry if I wasted your time. After considering the options (including monadic ones, sorry about having > that discussion, but I don't mind starting it again elsewhere) I think > representing that the arrow actually has multiple left arguments, that are > not curried or tuples leads to a syntax like this: > > f :: a, b, c -> (b, c), a -> a -> b > OK. Though I'm not clear why avoiding tuple formation is a goal here. Tuples in BitC are unboxed, and we can infer arity and calling convention deterministically where they are used. Not from the *definition*, but from the *type*, which was the gap in your original arity inference proposal. So I think that another viable proposal here is to decide that a function definition can only specify a single pattern, and that from a type theory perspective all functions are arity-1. Such a function can return a lambda, allowing it to be progressively applied in something like curried style, but the compiler is not inserting any accumulations in this case. The unfortunate consequence of this is that we remove all partial application from the language, but we seem to be deciding that in the presence of higher arity we need to do that anyway. Thoughts? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
