Hacker News Reader

Comment by PeCaN | Hacker News Reader

I hate function call syntax with parens. It makes code much more difficult to read and, if it supports calling functions, calling functions with args is harder than it should be.

View on HN

While I agree the parent could have elaborated more, would you like to as well?

I've never worked in a language without parents for function calls so I share their confusion reading Haskell or Ruby code at a glance.

I don't think a language needs to bend for non-users but being intelligible without knowing the language canI be nice.

As an outsider, the examples:

A(B(C)) A(B,C) A(B)(C)

Could all be valid Python but still communicate a little bit about A B and C. Without parents they'd all look like "A B C". I'm sure it's more obvious if you know those languages.

The interesting thing is that in Haskell, the equivalents of Python's `A(B,C)` and `A(B)(C)` are identical: `a b c`. This is because of currying: you're allowed to supply one argument to a function at a time, and you get back a function that takes one fewer argument. So if `add(x,y) = x + y`, then `add(5)` is a function (let's call it add5) so that `add5(y) = 5 + y`, or in Haskelly notation, if `add x y = x + y` then `(add 5) y = 5 + y`. If you write `add (x,y)` in Haskell, then it means a function that takes a single tuple `(x,y)` as an argument.

A(B(C)) would be `a (b c)` or `a $ b c` or `(a . b) c`. The first is the most vanilla way, the second is convenience (basically "evaluate everything after $ first, then plug it in") and the third uses the function composition operator `.`.

Nice summary. I would just like to add that `$` and `.` in Haskell aren't part of the language syntax, they're just normal functions/operators, which some people like to use.

We can define `$` ("apply a function to an argument") as:

    f $ x = f x

We can define `.` ("compose two functions") as (where `\x -> ...` is an anonymous function):

    f . g = \x -> f (g x)

Equivalents in, say, Javascript would be:

    function dollar(f, x) { return f(x); }

    function dot(f, g) { return function(x) { return f(g(x)); }

People mostly use `$` because of its precedence rules, which cause everything to its left to be treated as its first argument, and everything to the right as its second, i.e. we can use it to remove grouping parentheses like:

    (any complicated thing) (another complicated thing)

with:

    any complicated thing $ another complicated thing

It's also useful for partially applying, e.g. `map ($ x) fs` will apply each function in the list `fs` to the argument `x`.

> Without parents they'd all look like "A B C"

No, that would just be a(b,c). You would use parentheses to express the others. a(b(c)) would be a (b c). a(b)(c) would be (a b) c. IMO it's still perfectly readable, you just have to know it and get used to it (which, granted, can be difficult if you're only used to paren-ized languages, but not an impossible ask, certainly not, imo, a deal-breaker).

There's an added complication that `a(b, c)` could mean "call `a` with two arguments `b` and `c`" or it could mean "call `,` with two arguments `b` and `c` to form the pair `(b,c)`, then call `a` with that one argument".

The latter would be written `a([b, c])` in other languages. These are all isomorphic (we're calling `a` and giving access to `b` and `c`), but can confuse people who are new to the syntax.

> I hate function call syntax with parens. It makes code much more difficult to read and, if it supports calling functions, calling functions with args is harder than it should be.

the parent has a point you have no point.

foo

is this a function call or a function value?

    foo()

now it's explicit.

Your sarcasm just does not work.

> calling functions with args is harder than it should be

care to explain? because it is not harder.

It’s a ”function value”, since you haven’t applied it to another expression.

Whether that is a partially or fully applied function doesn’t matter in the first syntax, but in the second syntax you have to add ugly parens to disambiguate the partially applied function from the function call.

As soon as you get serious about type-level functions, the first syntax beats the shit outta the second.

> It’s a ”function value”, since you haven’t applied it to another expression.

    foo bar

is it calling bar then foo or passing bar as a value for foo?

> As soon as you get serious about type-level functions, the first syntax beats the shit outta the second.

Obviously it is not. Since you still need parenthesis for disambiguation and edge cases.

    foo(bar)

There is no ambiguity here. Simple rules are the best ones: parentheses for all function call.

Not taking sides here, but just wanted to point out that in Haskell/Agda/Coq/Idris/etc. your `foo` would denote a function, just like writing `foo` in e.g. Javascript. Your `foo()` would call the `foo` function with the argument `()`, which is a unit value (AKA null, void, etc.).

Interestingly a function which takes a unit value as argument (AKA a "thunk") is isomorphic to its return value, i.e. wrapping the body in a function doesn't change its meaning. Yet it can be useful to prevent side-effects from triggering, even if the effect is as benign as "heat up the CPU by performing lots of calculations".

Now I will take sides and point out that if we have currying, all of the following are the same:

    f(a, b, c, d)
    f(a, b, c)(d)
    f(a, b)(c, d)
    f(a, b)(c)(d)
    f(a)(b, c, d)
    f(a)(b)(c, d)
    f(a)(b)(c)(d)
    f(a)(b, c)(d)

Not only does this proliferation of forms over-complicate a language, but it's also completely redundant as a no-parens language would write it as `f a b c d`.

> Not only does this proliferation of forms over-complicate a language, but it's also completely redundant as a no-parens language would write it as `f a b c d`.

and I don't see how it makes anything more readable. It doesn't.

I wasn't talking about "readability", since that's subjective and can change based on background, familiarity, what someone's used most recently, etc.

I was giving an objective, measurable example where the `f(a, ...)` syntax is "harder": namely that it causes a proliferation of (curried) function application forms, all of which are equivalent, compared to just one in the `f a ...` form. As it stands, such parenthesised function calls don't even have a normal form! We could add one, by adding a new rule to the language, but even then there's ambiguity about what that rule might be: should we rewrite expressions of the form `f(a)(b)` into `f(a, b)`, thus making `f(a, b, c, d)` the normal form; or should we rewrite expressions of the form `f(a, b)` into `f(a)(b)`, thus making `f(a)(b)(c)(d)` the normal form?

Issues like this would plague anyone trying to manipulate programs programatically, e.g. writing interpreters, compilers, formatters, linters, documentation generators, HTML/LaTeX renderers, static analysers, (structured) macro expanders, minifiers, obfuscaters, deobfuscaters, (structured) diff/patch/VCS/etc., auto-completers, template/skeleton code generators, etc.

I liked how LiveScript had ! instead of (), it made the whole source look like stuff would be done! xD

I mean, why not give invocation its own one character operator, it's used all over the place.

I hate parens call syntax with or without functions. It makes code much more difficult to read, and if it supports functions calling first, arguing with functions and passing is harder than it should be.

Reply on news.ycombinator.com