Hacker News Reader

Comment by userbinator | Hacker News Reader

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.

View on HN

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

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

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

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

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

> 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 remember someone in university talking about the if function (which ostensibly takes one boolean argument).

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.

Yes I stand corrected - we were using C so definitely not a function there.

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.

> 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

Except

https://news.ycombinator.com/item?id=44513639

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

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

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

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

Yes I stand corrected - we were using C so definitely not a function there.

Also in Smalltalk and sclang (Supercollider language)

Or anything Lispy

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.

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

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.

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

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

if in Scheme can be, and in some cases is, implemented as a macro though. Which has arguments and can be called like a function.

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

Depends on the language! If "if" wasn't a keyword, in Ruby that would be calling a method that takes one positional argument and one block argument, such as `def if(cond, &body) = cond && body.call`. In PureScript that could be a call to a function with signature `if :: Boolean -> Record () -> _`.

But I assume the comment you were replying to was not referring to the conditional syntax from C-like languages, instead referring to a concept of an if "function", like the `ifelse` function in Julia [1] or the `if` form in Lisps (which shares the syntax of a function/macro call but is actually a special form) [2], neither of which would make sense as one argument function.

[1] https://docs.julialang.org/en/v1/base/base/#Base.ifelse

[2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Co...

I count two: true and void. This becomes obvious in languages that have consistent application syntax like Lisp, which would write this as

    (if true '())

Or if you wanted to capture the exact same semantics (rather than returning a null value to the continuation of the if)

    (if true (values))

Now it's obvious that if takes two (or three) arguments :)

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.

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.

With a function version of `if`, in general the compiler needs to wrap the alternative in closures ("thunks"), as it does with all function arguments unless optimizations make it unnecessary. That's never needed in the syntactic version. That's one significant optimization.

In GHC, `if` desugars to a case statement, and many optimizations flow from that. It's pretty central to the compiler's operation.

> Maybe it was needed in early versions. Or maybe they just didn't know they wouldn't need it yet.

Neither of these are true. My comment above was attempting to explain why `if` isn't implemented as a function. Haskell is a prime example of where it could have been done that way, the authors are fully aware of that, but they didn't because the arguments against doing it are strong. (Unless you're implementing a scripting-language type system where you don't care about optimization.)

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.

Isn't practical in Smalltalk either, so the compiler does something special:

    ifFalse: alternativeBlock
        "Answer the value of alternativeBlock. Execution does not actually
         reach here because the expression is compiled in-line."

        ^alternativeBlock value

Oh thanks, I didn't know that. I thought it just relied on the explicit code blocks.

But yeah, this is a pretty critical point for optimizations - any realistic language is likely to optimize this sooner or later.

I frequently see people treating if as if it was "taking a comparison", so: if (variable == true) ...

if should be a function, though sadly many languages aren't good enough to express it and have to make it a builtin.

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

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

    return(value);

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

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.

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

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

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

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.

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

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

I suppose if your only tool is a formula translator, everything looks like a formula?

"Plan" is really a much better term than "program". My next compiler will be called "plantran" for "plan translator". "pt" for short.

I have named the experimental languages I am toying with "Plan <x>" (for Programming LANguage, but also because it is a good term as you pointed out). Originally I was using numbers (probably would skip "Plan 9" like Microsoft skipped Windows 9) but the experiments went in different directions and implying an order was misleading. So I switched to star names: Plan Sirius, Plan Rigel, Plan Vega...

Are you writing up your results anywhere?

Not yet, and if I publish any of the languages I will probably use a different name (like "Oak" -> "Java"). Though I did call the unfinished language I published "BLA" (Baby 8 LAnguage - an attempt to see if I could fit an interpreter and editor in 1KB) so I might stick with the stupid names after all.

https://github.com/jeceljr/baby8/tree/main/examples/bla

Hmm, you might want to rename that: https://strlen.com/bla-language/

An interpreter and editor in 1K sounds very challenging! Do you mean 1K of Squeak bytecode? Including vectors of literals and selectors?

Thanks for the link - at the time I did a quick search and didn't find that or any other language with that name.

The 1KB target was for Baby 8 (the associated processor) binary code. That processor had a few quirks (like only indirect addressing outside the "zero page") and the language design partly reflected that. Seeing other people fit Lisp into less than 512 bytes made me think I had sacrificed too much functionality for size.

The incomplete Squeak code was just a quick test to see if the language made sense at all before wasting time doing the assembly version.

It looks inspiring! Does Bla have any kind of indexing or aggregate data structures? IIRC Tiny Basic had one array that was the leftover part of memory, which is enough to do a lot.

You have to manually carve up the heap into arrays if you want to have more than one. If variable F points to the start of an array then F,I@ will read F[I] while 42!(F,I) is an assignment F[I] := 42. The comma operator is just to convert a word index to a byte index, so F+(2*I)@ and 42!(F+(2*I)) also work but are uglier.

The sieve example uses a single 8Kword array https://github.com/jeceljr/baby8/blob/main/examples/bla/siev...

Oh, nice!

Is it? "Statement", defined by the dictionary as "the expression of an idea or opinion through something other than words.", seems quite apt. Symbols may end up resembling words, which perhaps is your contention, but technically they are only symbols.

Best I can tell, all usable definitions surrounding "Command" seem to suggest an associated action, which isn't true of all statements in imperative programming.

> Best I can tell, all usable definitions surrounding "Command" seem to suggest an associated action, which isn't true of all statements in imperative programming.

The defining characteristic of a programming "statement" is that it can perform some action (even if not all of them do), whereas statements in the usual everyday sense are inert. So it's not a good term.

> The defining characteristic of a programming "statement" is that it can perform some action

Given a declaration "statement" such as:

     int x;

What is the expected action? Memory allocation... I guess? Does any compiler implementation actually do that? I believe, in the age of type systems being all the rage, one would simply see that as a type constraint, not as a command to act upon.

Expressing an idea (the values used henceforth should be integers) seems more applicable, no?

> Given a declaration "statement" such as:

> int x;

> What is the expected action?

In a language that requires you to declare variables before you use them, it clearly does something - you couldn't do "x = 5;" before, and now you can. If you're trying to understand the program operationally (and if you're not then why are you thinking about statements?) it means something like "create a variable called x", even if the implementation of that is a no-op at the machine code level.

> I believe, in the age of type systems being all the rage, one would simply see that as a type constraint, not as a command to act upon.

But in that case by definition one would not be seeing it as a statement! Honestly to me it doesn't really matter whether "int x;" is an expression, a statement, or some mysterious third thing (in the same way that e.g. forward declaring a function isn't a statement or an expression). When we're talking about the distinction between statements and expressions we're talking primarily about statements like "x = x + 1;", which really can't be understood as a statement in the everyday English sense.

> Memory allocation... I guess? Does any compiler implementation actually do that?

Toy/research or embedded compilers do yes.

That looks like C. In C, declarations aren't statements: https://en.cppreference.com/w/c/language/statements.html

It's Hnlang, where declarations are statements. But perhaps the earlier comment was about C specifically? I admittedly missed it, if so.

In most programming languages, declarations aren't statements, because they don't have any effect at runtime. Maybe you can find some exceptions. Like in BASIC the DIM statement is sort of a declaration, but it does have a runtime effect; it changes the dimensions of an array. (Though some would say that in BASIC no statement is bright.)

> Maybe you can find some exceptions.

Including Ken Thompson's very own[1]. Fair enough that in the olden days there was a clearer distinction made, but even the man who (co-)created C changed his mind on that later because that is how the term has evolved. Now, in normal conversation, if you call `int x;` a statement, nobody is going to struggle to understand what you mean. Are you still living in the 1970s? If so, I admittedly missed that. My assumption was that this discussion is taking place in 2025 with the words of its time.

[1] https://go.dev/ref/spec#Statements

Your example isn't syntactically valid in Golang. Declarations are statements in Rust too, but not Python, TypeScript, or ECMAScript (which to my surprise does have a "Declaration" nonterminal in its grammar). C++, Java, and C# are half-and-half; in their grammars, some kinds of declarations (in particular, like `int x;`) can be statements, but others cannot.

The distinction hasn't gotten any less clear, but it was already easy to find people in the 01970s who didn't know the difference. You're one of today's lucky ten thousand!

I do frequently encounter people who are failing to solve their problems because they don't know things that were already known in the 01970s, so I think it's worthwhile to study 01970s informatics. Mostly, though, I think it's worth studying the zeitgeist of the 01970s in informatics: some people were making rapid progress on solving fundamental problems, partly because they didn't have certain self-defeating attitudes that are popular in informatics today, such as not caring whether what they say is true or false.

> Your example isn't syntactically valid in Golang.

Well, of course not. Hnlang is clearly not the same language as Go. The different name tips you off to that. However, the same intent can be expressed as a Go statement:

   var x int

For what it is worth, the silly pedantry you offer is as funny as you had hoped it would be, so kudos. But it is telling that you had to reach for being funny to mask your cluelessness. Better than being one of those idiots that doubles down on their idiocy once they realize that they have no idea what is going on, I suppose!

It sounds like using HN is exacerbating your mental health troubles. You should probably take a break from HN for a week or two.

The earlier comment was funny. These meme is, unfortunately, quite tired. Commenters on Reddit have been playing on variants of this idea for years. Jokes only work for so long, I'm afraid.

The irony of this coming from someone who unironically writes dates as 01970.

The requirement for a truth value is just from how math/logic uses the term.

Well, and linguistics. A "statement" in the grammatical sense is a sentence that is declarative in form (as opposed to, in English, interrogative, imperative, or exclamatory) and which thus ostensibly has a truth-value.

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

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

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

Reply on news.ycombinator.com