On Fri, Feb 13, 2015 at 3:11 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Thu, Feb 12, 2015 at 9:07 PM, Matt Oliveri <[email protected]> wrote: >> >> The only possible problem with modeling multi-arg functions as >> functions taking a tuple is that the tuple might be boxed, in which >> case it's not the efficient calling convention you want.... > > In BitC, tuples are unboxed. So if a boxed tuple argument pattern is > presented, it will show up in the pattern as something like "ref (a, b, c)". > Following the previously sketched arity inference rules, the inferred arity > for that pattern is 1, because the top level argument pattern is not a tuple > pattern.
Great. I didn't say it was a big problem. >> Similar story for modeling functions with named args as a function >> taking an unboxed record. > > I think we should try to avoid discussing boxed patterns in the discussion > of arity. It will confuse things, and the resolution is very simple; a > parameter of boxed type is always passed as a single word pointer. Yeah, I like that... But I said _unboxed_ record. Anyway, I don't care much about named parameters; I was just responding to Keean, who brought it up. >> My recommendation to use >> Lispy call syntax... > > Matt, you may remember that early BitC had a LISP-like surface syntax? It > was *such* a relief when we finally transitioned away from that. > > That said, I truly admire the enthusiasm of your parenthesis fetish, and > keeping in mind that it's important to be gentle when you disagree with > someone in email, I want to make sure that I express my view on LISP-like > syntax in the kind of non-excessive, moderate, appropriate, and respectful > tone that this particular proposal truly warrants. So: > > Not if you put a gun to my head, shoved a red-hot poker up my posterior, > flayed the skin from my body by inches, ripped out my eyeballs, and broke my > fingers slowly, one bone at a time. > > > Hmm. I guess I haven't quite got the hang of the passive-aggressive "never > say anything that might be construed as contradiction" style that seems to > be preferred here in the Pacific NorthWest. > > And mind you, I'm actually a *fan* of LISP and Scheme... Not so fast, Shap. Using Lisp syntax for function calls is a far cry from using Lisp syntax, period. I don't like Lisp syntax either. But you have to admit, for function calls, it basically looks the same as ML, just that the semantics are that it's not curried. I shouldn't have said "Lisp"; it threw you off. Another way to summarize my syntax recommendation is: It looks curried, but it isn't, unless you use explicit parens. You can still legitimately object to that syntax, but not because it'll turn BitC code into parenthesis soup. It won't. One reason you might object--seeing another email of yours--is that now we have three ways to effectively pass multiple arguments: - separate by spaces (primitive multi-arg) - pass unboxed tuple - curry And the first two would actually get you the same code (I figure). But it sounded like you said F# has this accidental distinction between the first two as well. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
