←back to thread

183 points todsacerdoti | 2 comments | | HN request time: 0.398s | source
Show context
userbinator ◴[] No.44506358[source]
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.

replies(7): >>44506396 #>>44506421 #>>44506500 #>>44506580 #>>44510160 #>>44510878 #>>44511635 #
pansa2 ◴[] No.44506396[source]
> 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.”

replies(4): >>44506779 #>>44506910 #>>44506977 #>>44511912 #
jamesfinlayson ◴[] No.44506779[source]
I remember someone in university talking about the if function (which ostensibly takes one boolean argument).
replies(5): >>44506886 #>>44506915 #>>44507329 #>>44508128 #>>44509940 #
antonvs ◴[] No.44507329[source]
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.

replies(1): >>44509661 #
immibis ◴[] No.44509661[source]
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.

replies(2): >>44510086 #>>44512726 #
1. fn-mote ◴[] No.44510086[source]
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.

replies(1): >>44512176 #
2. ◴[] No.44512176[source]