On Sat, Feb 14, 2015 at 11:46 AM, Jonathan S. Shapiro <[email protected]> wrote: > On Fri, Feb 13, 2015 at 7:45 PM, Matt Oliveri <[email protected]> wrote: >> >> Well, also to remind Keean of the syntactic ambiguity between multiple >> args and a tuple of args. But one could also take the position that an >> unboxed tuple of args _is_ multiple args. > > > I understand the rest, but I'm lost on this part. What we're really talking > about here is a function taking a single argument of tuple type. Such a > function must be applied to a tuple. In both the pattern and the actual > parameter expression, there is syntax indicating that a tuple is being > matched (resp. constructed). Where is the ambiguity here?
That case is not ambiguous in itself. For languages where multi-arg is different from passing tuples, but uses the same syntax, there is an almost ambiguity between passing two arguments and passing a pair: foo(x,y) foo((x,y)) > This fact is why I think we will see a bifurcation of library styles. One > camp will religiously prefer "add x y" while the other will religiously > prefer "add(x, y)". If "add(x,y)" means pass a pair as a single argument, then I don't think anyone would religiously prefer it. I think people from C/C++ would prefer whatever syntax corresponds most closely to native argument passing, and people from functional land would not conform to any single religion. If you think functional people will prefer currying, no matter what syntax it has, then there's no solution, other than to yell at them for it. If they will prefer "add x y" no matter what it means, then we can adopt my proposal of using that syntax for native arguments. > The reason that argument tuples solve the arity problem isn't that they are > tuples. What's really going on is that we are exploiting the fact that any > function taking a single argument (in this case a tuple) never needs to form > an intermediate closure. Separately, we are then exploiting the structural > properties of tuples to map the passing of the tuple at the implementation > level onto the native register-based calling convention. > > Viewed that way, there's no reason that we cannot write programs with > non-allocating applications in OCaml or F#. All we need to do is ensure that > all of our functions take a single pattern rather than multiple patterns. I don't know about F#. In OCaml, tuples are boxed and have an object id, which seems like it could force allocation if optimizations fail. It just occurred to that we could have a user-facing type system without native function arity, and a module interface type system with native function arity. The arities would be chosen by the compiler when compiling a module. Other modules depending on it would know the native arity when calling its functions. I guess you already knew about that, since I figure that's essentially what you get with F# over CLI. Does this help? Anyway, perhaps you're saying OCaml does something like that too to get native calls in predictable situations. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
