The reason for the suggestion is that the arrow should take multiple left arguments.
If BitC tuples are always unboxed, then it may not make any difference, but the tuple constructor could be curried, whereas arrow left arguments cannot. Haskell does allow curried constructor application. Keean. On 16 Feb 2015 15:46, "Jonathan S. Shapiro" <[email protected]> wrote: > 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 > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
