7 ms·
> Is there a reason why you would make fn(1) and fn 1 equivalent? If your standard function call convention is just `f x`, but you also support precedence oper
by tazjin 4y ago
> Is there a reason why you would make fn(1) and fn 1 equivalent?
If your standard function call convention is just `f x`, but you also support precedence operators, then `f (x)` automatically becomes possible.
It reminds me of an old Lisp joke, though:
f x -- too mathematical!
(f x) -- too many parenthesis!
f(x) -- just right!
- gpderetta 4y ago> f x -- too mathematical! :) yet we are very happy to use the same syntax in shell scripts or the shell itself.
- layer8 4y agoI guess the difference is that nesting calls (commands) is much less common in the shell, and (closely related) commands don’t really have a return value.
- DougBTX 4y agoOn the shell, it is all the other way around, so to use command substitution it is like this: f $(g x) To pass the output of g x to f.
- gpderetta 4y agois it? In practice I find that my shell one liners are orders of magnitude more complex than what I would dare to write in any other 'proper' language: grep "hello ($(cat patterns.txt| tr '\n' '|'|grep ')$^)" <(ssh other.host "cat ~/file.txt") |tee >(grep 'a' >As.txt) >(grep 'b' > Bs.txt) [yes, gratuitous use of cat, sue me]
- lyxsus 4y agoWe’re not, but your point is still valid.
- georgyo 4y agoI've heard this argument before, but this isn't true. In shell, f x y z, x y z are all augments to f. Doesn't matter if f takes one argument, all are passed to the function. With many functional languages this gets very confusing. IE what ie what does `f f x` do? In shell I know for sure. In the example f f x, it might be easy to parse. But in f x y z, any of x y z might be functions.
- nemaar 4y agoMost functional languages parse a b c d e f as a(b, c, d, e, f), it does not matter what b, c, d, e, f are. Do you know any language where this is different?
- georgyo 4y agoI thought more languages did this but at least nix and ocaml do not actually behave like I thought. In Ruby however it is a bit more ugly def f x x + 1 end puts f f 1 > 3
- the_af 4y agoI don't understand your objection, what output would you like to see instead?
- lgessler 4y agoGP's point is that while yes, we know since `f` has arity 1 there's no ambiguity, in general you might not have the arity of any given function fresh in your head, and therefore can't tell (in Ruby) just from looking at `f f 1` whether it means a single invocation of an arity 2 function, or two invocations of an arity 1 function
- the_af 4y agoAh! Right. It helps to have all functions be of arity 1 to disambiguate, yes.
- mellavora 4y agoAs an old lisp fan, I never got this. (f x) and f(x) have the same number of parenthesis. and the nice thing about (f x) is that the parenthesis group f with x; so you have the whole call inside the (). Consistent and simple to understand. vs i.e. print(f"a string"), where it isn't even clear that the "f" is a function call.
- junon 4y agoThat's the joke. The number of terms doesn't change, and the last two have the same number of parens. The statements relate quantities of those things as though they're a problem, when in reality the "just right one" only changes the order slightly. Hence the joke. It's one of those jokes that earns a loud sigh from me, rather than a chuckle.
- YetAnotherNick 4y ago> (f x) and f(x) have the same number of parenthesis. That's the joke
- quickthrower2 4y agoI have heard that if you count { and ( as parens, a Java program for example has just as many parens as. lisp one. A lisp paren can do both jobs: expression and scopes.
- layer8 4y ago> A lisp paren can do both jobs: expression and scopes. Using different symbols for different purposes makes sense, it helps humans to parse correctly faster.
- gorjusborg 4y agoSure, why care about splitting algorithms into functions and naming them appropriately when you can just write it all in a 3k line function.
- 4y ago
- arethuza 4y agoPity it doesn't include a line for: x f