Phrase origin: Why do we "call" functions?

Somewhat less frequently, I also hear "invoke" or "execute", which is more verbose but also more generic.

Incidentally, I find strange misuses of "call" ("calling a command", "calling a button") one of the more grating phrases used by ESL CS students.

> strange misuses of "call"

My favourite (least favourite?) is using “call” with “return”. On more than one occasion I’ve heard:

“When we call the return keyword, the function ends.”

I actually see the converse often with novices often, referring to statements (or even entire function decls) as "commands".

C# seems to like to use "Invoke" for things like delegates or reflected methods. Then it proceeds to use "Call Stack" in the debugger view.

Invoke comes from Latin invocō, invocāre, meaning “to call upon”. I wouldn’t view it as a misuse, but rather a shortening.

"Command" is a better term for what we call "statements" in imperative programming languages. "Statement" in this context is an unfortunate historical term; except in Prolog, these "statements" don't have a truth-value, just an effect. (And in Prolog we call them "clauses" instead.)

I remember someone in university talking about the if function (which ostensibly takes one boolean argument).

> Invoke comes from Latin invocō, invocāre, meaning “to call upon”.

(In the way you'd call upon a skill, not in the way you'd call upon a neighbor.)

There are languages in which `if` is a function.

In in Tcl, `if` is called a "command".

I've heard that too --- the voice in my head automatically read it in the customary thick Indian accent.

Sounds like something Prof. John Ousterhout would say:-; The place where this was literally accurate would be Tcl.

I don't know enough Smalltalk to be sure but I think to remember it has a similar approach of everything is an object and I wouldn't be surprised if they'd coerced control flow somehow into this framework.

Also Forth comes to mind, but that would probably be a stretch.

Eh, "return" is just a very restricted continuation with special syntax… it's a stretch to say you "call" it, but not unjustified.

Try implementing that in most languages and you'll run into problems.

In an imperative programming language with eager evaluation, i.e. where arguments are evaluated before applying the function, implementing `if` as a function will evaluate both the "then" and "else" alternatives, which will have undesirable behavior if the alternatives can have side effects.

In a pure but still eager functional language this can work better, if it's not possible for the alternatives to have side effects. But it's still inefficient, because you're evaluating expressions whose result will be discarded, which is just wasted computation.

In a lazy functional language, you can have a viable `if` function, because it will only evaluate the argument that's needed. But even in the lazy functional language Haskell, `if` is implemented as built-in syntax, for usability reasons - if the compiler understands what `if` means as opposed to treating it as an ordinary function, it can optimize better, produce better messages, etc.

In a language with the right kind of macros, you can define `if` as a macro. Typically in that case, its arguments might be wrapped in lambdas, by the macro, to allow them to be evaluated only as needed. But Scheme and Lisp, which have the right kind of macros, don't define `if` as a macro for similar reasons to Haskell.

One language in which `if` is a function is the pure lambda calculus, but no-one writes real code in that.

The only "major" language I can think of in which `if` is actually a function (well, a couple of methods) is Smalltalk, and in that case it works because the arguments to it are code blocks, i.e. essentially lambdas.

tl;dr: `if` as a function isn't practical in most languages.

In Excel formulas everything is a function. IF, AND, OR, NOT are all functions. It is awkward and goes against what software devs are familiar with, but there are probably more people familiar with the Excel IF function than any other forms. Here is an example taken from the docs... =IF(AND(A3>B2,A3<C2),TRUE,FALSE)

Excel cell formulas are the most widely used functional programming language in the world.

Also in Smalltalk and sclang (Supercollider language)

Which fits nicely for calling a function - you use its skill, you don't call for a chat.

But vocare (the voco in invoco) is how you'd call a neighbor

I don't think Haskell needs 'if' to be a construct for compiler optimization reasons; it could be implemented easily enough with pattern matching:

if' :: Bool -> a -> a -> a

if' True x _ = x

if' False _ y = y

The compiler could substitute this if it knew the first argument was a constant.

Maybe it was needed in early versions. Or maybe they just didn't know they wouldn't need it yet. The early versions of Haskell had pretty terrible I/O, too.

I would include the cond function from lisp, or the generalization from lambda calculus

   λexpr1.λexpr2.λc.((c expr1) expr2)

If takes two or three arguments, but never one. The condition is the one made syntactically obvious in most languages, the consequent is another required argument, and the alternative is optional.

Microsoft devs get paid by the character, I'm not sure that counts.

Or anything Lispy

A short search lead to this SE post [1], which doesn't answer the "why" but says "if" is just syntactic sugar that turns into `ifThenElse`...

[1]: https://softwareengineering.stackexchange.com/questions/1957...

The post claims that this is done in such a basic way that if you have managed to rebind `ifThenElse`, your rebound function gets called. I didn't confirm this, but I believed it.

Now that it's commonly "tap or click the button" I might be down with the next gen using "call". Anything, as long as they don't go with "broh, the button".

Huh? if (true) {} takes precisely one argument.

That's an application of `if` with one of the arguments empty.

The semantics of `if` requrie at least, `if(cond, clause)`, though more generally, `if(cond, clause, else-clause)`

You and Zambyte are both doing the same thing the top level comment is complaining about.

e.g. in C:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf

    (6.8.5.1) selection-statement:
      if ( expression ) secondary-block
      if ( expression ) secondary-block else secondary-block

in C++:

https://eel.is/c++draft/gram.stmt

    selection-statement:
      if constexpropt ( init-statementopt condition ) statement
      if constexpropt ( init-statementopt condition ) statement else statement
      if !opt consteval compound-statement
      if !opt consteval compound-statement else statement

where

    condition:
      expression
      attribute-specifier-seqopt decl-specifier-seq declarator brace-or-equal-initializer
      structured-binding-declaration initializer 

More examples:

https://docs.python.org/3/reference/grammar.html

https://doc.rust-lang.org/reference/expressions/if-expr.html...

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

expression != argument

True.

In many early computer programming documents the term "order" was used instead of "statement", where "order" was meant as a synonym for "command" and not as referring to the ordering of a sequence.

On an old Nokia you follow links by pressing the call button.

They aren't talking about C and its descendants in particular, but more generally. For example in Haskell and Scheme there is only an if function and no if statement. And you're welcome to create an if function in any language you like and use it instead of the native syntax. I like to use an if function in PostgreSQL because it's less cumbersome than a case expression.

So in the abstract, if is a ternary function. I think the original comment was reflecting on how "if (true) ... " looks like a function call of one argument but that's obviously wrong.

Arguments are expressions in Haskell. In abstract, it uses expressions.

Occasionally, but much more often (as in Mauchly's cited paper) an "order" was a machine instruction, not a high-level language "statement".

>Incidentally, I find strange misuses of "call" ("calling a command", "calling a button") one of the more grating phrases used by ESL CS students.

From my own experience, native speakers (who are beginners at programming) also do this. They also describe all kinds of things as "commands" that aren't.

> I don't know enough Smalltalk to be sure but I think to remember it has a similar approach of everything is an object and I wouldn't be surprised if they'd coerced control flow somehow into this framework.

It does. It's been discussed on HN before, even: https://news.ycombinator.com/item?id=13857174

this is not quite right. haskell and scheme have if expressions, not if statements. that's not the same as if being a function. if is not, and cannot be, a function in scheme, as it does not have scheme function semantics. specifically, it is not strict, as it does not evaluate all its subexpressions before executing. since haskell is non-strict, if can be implemented as a function, and iirc it is

Some people use parentheses for the return value, to make it look like a function call:

    return(value);

> since haskell is non-strict, if can be implemented as a function, and iirc it is

"If" can be implemented as a function in Haskell, but it's not a function. You can't pass it as a higher-order function and it uses the "then" and "else" keywords, too. But you could implement it as a function if you wanted:

  if' :: Bool -> a -> a
  if' True x _ = x
  if' False _ y = y

Then instead of writing something like this:

  max x y = if x > y then x else y

You'd write this:

  max x y = if' (x > y) x y

But the "then" and "else" remove the need for parentheses around the expressions.

Yes, but that is mostly because in the first few years (including by the time of Mauchly), there were no "high-level" programming languages, so the "orders" composing the text of a program corresponded to instructions directly executable by the machine.

I believe that the term "statement" has been imposed by the IBM publications about FORTRAN, starting in 1956.

Before the first public documents about IBM FORTRAN, the first internal document about FORTRAN, from 1954, had used the terms "formula" for anything that later would be called "executable statement", i.e. for many things that would not have been called formulas either before or after that, like IF-formulas, DO-formulas, GOTO-formulas and so on, and the document had used "sentence" for what later would be called "non-executable statements" (i.e. definitions or declarations).

Before FORTRAN (1951 to 1953), for his high-level programming language Heinz Rutishauser had used the term "Befehl", which means "command". (For what we name today "program", he had used the term "Rechenplan", which means "computation plan".)

It's calling a person like by saying their name loudly.