programming language design
in your programmery opinion, which function call syntax do you prefer:
- f(x, y)
- f x y
and how might your preference change in the presence of, say, partial function application (e.g. 'f x' returns a function that still expects a parameter y)?
programming language design
after hearing all your wonderful comments and suggestions about this matter, i have decided to give up
re: programming language design
@typhlosion I very much prefer `f x y` if you have partial application (and functions curried by default)
And I also prefer my functions curried and my languages to support partial application. :P
OTOH, I'm a filth ML heathen (OK, I use many other languages too, but still)
programming language design
@typhlosion FWIW, I would not want to see "f x y" legal in the second case unless f took exactly two arguments. Otherwise the cases where f takes one arg and returns a function that takes one arg is indistinguishable from the case where f takes one arg, which is the result of applying function x to y. Depending on precedence rules to disambiguate is a recipe for confusion.
programming language design
@typhlosion I’m most experienced with C-family languages, so I like the former - even though I’ve been using obj-C lately, which sort of mixes the two. Obj-C does get it right in that a function call doesn’t particularly resemble a different kind of mathematical expression; it’s useful to be able to see when arbitrary code is executing somewhere else.
I think a syntax for currying a function should not strongly resemble the syntax for calling a function. It has to because it’s going to include the function name and a mix of args and placeholders, but the less easily it can be mistaken for an immediate call the better.
Really I just want something easy to follow, and that means that constructs that behave fundamentally differently from each other should avoid resembling each other too closely. Lots of languages get this wrong in various ways.
re: programming language design
@typhlosion for me #1 makes it easier to read new code by others because it quickly delineates functions
programming language design
@typhlosion study how the C++ Standard Template Library handles currying via std::bind, look at some code that uses it, and then realize that whatever you invent cannot possibly be worse than what people already use every goddamn day in this stupid industry
programming language design
@kistaro i was gonna say "you lost me at 'study c++'" and then i read the rest of the post
programming language design
@typhlosion I prefer (f x y)
programming language design
i guess i should explain exactly what my bad programming language is going for
i want to make a language supporting both FP-style (side-effect-free) functions and imperative-style (side-effectful)... uh... let's call them procedures
i would love to have currying and partial application and other such nice things, but there's some other stuff i would like too, so i gotta be careful about syntax so it can actually express stuff nicely