3 ms·

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

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.

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.