Unparenthesized calls

[jdpage]

Are we interested in supporting some variety of non-parenthesized calls, a la Ruby and Lua? There are a few ways to go with this.

The first is to say no, all function calls are always parenthesized. This is okay.

The second is to say that function calls don't have to be parenthesized ever except where it would be ambiguous. In my experience, it's not always obvious to a programmer where the ambiguity would pop up, and usually involves some confluence of nested comma-bearing expressions, so I don't like this one.

The third is to say that function calls may only omit their parentheses if they have exactly one argument. This is what Lua does. It is naturally unambiguous, even in chains of functions (i.e. g f x parses as g(f(x)), though I wouldn't necessarily advocate that kind of usage in practice).

An extension of this is to say that function calls may also omit their parentheses if they have no arguments. This is problematic for a couple of reasons. The first is that, while it allows you to have really cute getters on your objects which look just like properties, it's not super obvious how much computation is going to happen on a given line. The second is that it makes taking function pointers slightly more confusing.

Ironically, I find the fact that in C, if foo is a function, &foo and foo evaluating to the same thing is a little confusing, so I'm in favour of having &foo mean "a pointer to foo", while foo means "the value of foo", which could mean either the literal bytes of the function, or the result of evaluating the function with no arguments. However, that introduces a bit of sneaky--now in order to take a pointer to the result of a function, you have to write &(foo). (The other precedence order doesn't really make sense, since it becomes impossible to write out function pointers.)

(Incidentally, taking pointers to results of functions isn't necessarily a terrible idea in gold-syntax-- unless we implement copy elision or some kind of optimization, our stackless calling convention means that the pointer will be valid until the next call to the function!)

[jdpage]

I think on-balance, my verdict is "not worth it", but I'd like to hear from @woodrowbarlow too.

[jdpage]

Oh, forgot to mention. This could be kind of cool if paired with the ability to pass do-blocks to functions, e.g. something like

fun foo(x: u8, f: &fun(u8) -> u8) -> u8
  return f(x) + f(1)
end

being able to be called like this:

let w: u8 = foo z: u8 in 7 do
  return z + 1
end

... and have w be 10, though this has all kinds of problems (now we have blocks where return doesn't actually return from the function? is in always the right punctuation there? foo looks like a statement but it's actually an expression?)