61–70 of 111 posts
Earlier quoted context omitted.
Or redefine the language provided 'if' statement, in the case that one wanted to do so.
You can't really redefine if because everything is a constant, but you can define if in your own context yes.
Earlier quoted context omitted.
I agree. In any somewhat functional language (I.e. all the mainstream ones) you can wrap "if" in a function if you please. E.g. function funif (b, f) { return (b && f()) } If you want to do clever stuff. I never feel the need as I would rather abstract over bigger things.
You can do it, but that is not how the (default) control structures work in those languages. There is usually also some syntax cost.
This is interesting, but I'm not convinced it's better than the python it's being compared to. Memorizing and understanding the behavior of functions that perform control flow seems no easier than memorizing and understanding hardcoded syntax/keywords. The additional flexibility of making everything a first-class citizen allows people to write code that is too clever for its own good. I could be wrong but I think the…
I agree. In any somewhat functional language (I.e. all the mainstream ones) you can wrap "if" in a function if you please. E.g. function funif (b, f) { return (b && f()) } If you want to do clever stuff. I never feel the need as I would rather abstract over bigger things.
state = "inactive"
if_func(condition) {
state = "active"
activate_button.disabled = true
deactivate_button.disabled = false
}
let state = ["inactive"];
if_func(condition, ({state, activate_button, deactivate_button}) => {
state[0] = "active";
activate_button.disabled = true;
deactivate_button.disabled = false;
}, {state, activate_button, deactivate_button});On the other hand, I would like to explore "when arithmetics is just a function". I think Elm does this well: operators are just functions with two arguments that can be written as "1 + 2", the familiar way, or "(+) 1 2". Then you can compose it like "map ((+) 2)" (currying) so you get a function that adds 2 to every item of a list, and so on.
Interesting that this article makes no mention of eager vs lazy evaluation - isn’t a big reason that if, for etc has to be special forms in an eagerly evaluated language that their arguments need to be lazily evaluated, which of course, deviates from the rule? Also, lazy evaluation is achieved in an eagerly evaluated language as simply wrapping a block of code in a function, which makes lazy evaluation isomorphic wit…
For lambda calculus, the motto is "when everything is a function". The boolean true is the function λx.λy.x, while false is λx.λy.y. If b then x else y then simply becomes b x y. In a functional language like Haskell that is basically a typed lambda calculus with lots of syntactic sugar, we can replicate this with: type MyBool a = a -> a -> a myTrue :: MyBool a myTrue = \x y -> x myFalse :: MyBool a myFalse = \x y ->…
yourIf == myIdInteresting that this article makes no mention of eager vs lazy evaluation - isn’t a big reason that if, for etc has to be special forms in an eagerly evaluated language that their arguments need to be lazily evaluated, which of course, deviates from the rule? Also, lazy evaluation is achieved in an eagerly evaluated language as simply wrapping a block of code in a function, which makes lazy evaluation isomorphic wit…
> You might wonder: “Won’t the block execute immediately when passed as an argument?” Here’s the key insight: in Rye, code blocks { ... } are values. They don’t evaluate until you explicitly tell them to.