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? 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)". 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. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
