4 ms·

> 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 harde

> 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.

joel_ms 8y ago
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.
- nostalgeek 8y ago
  > 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.
chriswarbo 8y ago
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`.
- nostalgeek 8y ago
  > 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.
  - chriswarbo 8y ago
    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.

joel_ms 8y ago

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.

nostalgeek 8y ago
> 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.

chriswarbo 8y ago

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`.

nostalgeek 8y ago
> 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.
- chriswarbo 8y ago
  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.