I am a horse in the land of booleans • Hacker News Board

Re: I am a horse in the land of booleans

#81

Post by a_lieb » Sun, Aug 11, 2019, 5:50 PM UTC

SEMW wrote: post #5

asplake wrote: post #3

I’m used to 0 and [] being falsy. Upsides and downsides to Clojure’s choice here?

The trouble is that `if(value)` or `value && ..` ends up getting used as an idiomatic shorthand for "if value is present" even in languages (such as javascript and python) where 0 is falsey. Because most of the time it works, so people do it. And then inevitably get bugs when the value happens to be 0. This can get increasingly hard to reason about the more datatypes you add which interpret 0-ish values as falsey --…

Due to exactly this issue, an increasing number of languages have an operator just for "if exists and not null": the null coalescing operator[0].

What "exists" means depends on the language; it can be as loose as checking if the variable has ever been set (PHP), but generally has nothing to do with truthiness/falsiness status.

[0] https://en.wikipedia.org/wiki/Null_coalescing_operator

Re: I am a horse in the land of booleans

#82

Post by uryga » Sun, Aug 11, 2019, 9:10 PM UTC

uryga wrote: post #52

Sharlin wrote: post #38

Earlier quoted context omitted.

That’s true enough, but in programming languages it’s usually zero=false and any non-zero=true, at least in argument position. That’s more difficult to justify mathematically.

i haven't checked it thoroughly, but it looks like all the desired properties of boolean arithmetic are preserved when false = 0 true = [1] (i.e. the equivalence class of all n > 0) && = + || = * spelling it out: || / + (or): 0+0 = 0 0+[1] = [1]+0 = [1] [1]+[1] = [1] && / * (and): 0*0 = 0 0*[1] = [1]*0 = 0 [1]*[1] = [1] where [1] stands for "any nonzero number". (please let me know if i missed anything!) so natural n…

btw i came a across a definition of `||` which wouldn't have the `5 + -5` problem, and thus would make it all work with integers:

  x || y = x + y - xy

Re: I am a horse in the land of booleans

#83

Post by bb88 » Mon, Aug 12, 2019, 12:24 AM UTC

taeric wrote: post #37

bb88 wrote: post #29

Earlier quoted context omitted.

So here's an example where it matters in python: def f_to_c(deg_f=None): if deg_f: return (deg_f - 32) * 5 / 9 else: raise TypeError('Invalid value passed in') The problem is that it works for all numbers, except 0, because 0 is falsy, and will return a TypeError exception. There are lots of different solutions to this issue, but I wouldn't write the pedantic if statements. I would just do this: def f_to_c(deg_f): re…

Yeah, I don't get it. Your solution is better in near every way. The if statement should be doing a type check, not a value check. And it is redundant since the math will do it. Right?

Right, because the minus operator will look for the __sub__ attribute.

Re: I am a horse in the land of booleans

#84

Post by Smithalicious » Mon, Aug 12, 2019, 2:57 AM UTC

kazinator wrote: post #75

Smithalicious wrote: post #44

Earlier quoted context omitted.

"p" makes sense if you know that it stands for "predicate". It's not nearly as arcane as car and cdr. Also can we finally settle on a name for these things now? If car and cdr are too arcane we can do away with them (though I like being able to do caddadadr) but why do we need "first" and "rest" rather than the already established "head" and "tail"? I particularly dislike "rest" since it's a relative term, i.e. in no…

We should strive to name predicate functions using adjectives or verb participles. Then they do not require a suffix. (if (closed handle) ...) (when (static widget) ...) The p or -p or ? should only be used in situations when we can't avoid naming the predicate after a noun, like stringp for "is it a string".

I don't like this since I prefer using adjective for conversions/casts, i.e. I'd like (int x) to mean "x considered as integer". If you mix the two conventions (like you seem to suggest with your last paragraph) then it just becomes ambiguous.

Re: I am a horse in the land of booleans

#85

Post by kazinator » Mon, Aug 12, 2019, 5:37 AM UTC

Smithalicious wrote: post #84

kazinator wrote: post #75

Earlier quoted context omitted.

We should strive to name predicate functions using adjectives or verb participles. Then they do not require a suffix. (if (closed handle) ...) (when (static widget) ...) The p or -p or ? should only be used in situations when we can't avoid naming the predicate after a noun, like stringp for "is it a string".

I don't like this since I prefer using adjective for conversions/casts, i.e. I'd like (int x) to mean "x considered as integer". If you mix the two conventions (like you seem to suggest with your last paragraph) then it just becomes ambiguous.

int is an adjective?

Re: I am a horse in the land of booleans

#86

Post by delinka » Mon, Aug 12, 2019, 3:07 PM UTC

jefftk wrote: post #79

delinka wrote: post #71

Earlier quoted context omitted.

It's called 'ternary operator' because it's `?` and `:` and takes three operands.

I don't like calling it the ternary operator because there are other ternary operators, like "x BETWEEN a AND b" in SQL. Sometimes it's called the "conditional operator" but my experience has been that "question mark operator" is what the most people will understand.

If you're going to reference other languages, `?` is an operator on its own in Swift. Calling `?:` by the name 'question mark operator' is only naming half of the thing.

Re: I am a horse in the land of booleans

#87

Post by fiddlerwoaroof » Mon, Aug 12, 2019, 4:25 PM UTC

taeric wrote: post #37

bb88 wrote: post #29

Earlier quoted context omitted.

So here's an example where it matters in python: def f_to_c(deg_f=None): if deg_f: return (deg_f - 32) * 5 / 9 else: raise TypeError('Invalid value passed in') The problem is that it works for all numbers, except 0, because 0 is falsy, and will return a TypeError exception. There are lots of different solutions to this issue, but I wouldn't write the pedantic if statements. I would just do this: def f_to_c(deg_f): re…

Yeah, I don't get it. Your solution is better in near every way. The if statement should be doing a type check, not a value check. And it is redundant since the math will do it. Right?

A better example would be something like:

    def my_calc(x, scale = None):
        if not scale:
          scale = 1
        return (x + 4) * scale

where the (x + 4) bit stands for some interesting calculation whose result is being scaled: this code makes it unclear whether or not scale == 0 is intentionally conflated with scale == None or whether this is a programming error. It would be better to do this, if this is intentional:

    def my_calc(x, scale = None):
        if scale == 0 or scale is None:
          scale = 1
        return (x + 4) * scale

Or, if it's unintentional, one should have written:

    def my_calc(x, scale = None):
        if scale is None:
          scale = 1
        return (x + 4) * scale

Re: I am a horse in the land of booleans

#88

Post by taeric » Mon, Aug 12, 2019, 10:49 PM UTC

fiddlerwoaroof wrote: post #87

taeric wrote: post #37

Earlier quoted context omitted.

Yeah, I don't get it. Your solution is better in near every way. The if statement should be doing a type check, not a value check. And it is redundant since the math will do it. Right?

A better example would be something like: def my_calc(x, scale = None): if not scale: scale = 1 return (x + 4) * scale where the (x + 4) bit stands for some interesting calculation whose result is being scaled: this code makes it unclear whether or not scale == 0 is intentionally conflated with scale == None or whether this is a programming error. It would be better to do this, if this is intentional: def my_calc(x,…

Why not just default scale to 1?

I get that you might want to know if it was supplied or if it is the default, and common lisp has a way to do that. It is very niche to need, thought.

That all said, I think this is just suffering the fate if anything with examples. I accept there are places where zero as false can be annoying.

Re: I am a horse in the land of booleans

#89

Post by bb88 » Tue, Aug 13, 2019, 3:53 AM UTC

taeric wrote: post #88

fiddlerwoaroof wrote: post #87

Earlier quoted context omitted.

A better example would be something like: def my_calc(x, scale = None): if not scale: scale = 1 return (x + 4) * scale where the (x + 4) bit stands for some interesting calculation whose result is being scaled: this code makes it unclear whether or not scale == 0 is intentionally conflated with scale == None or whether this is a programming error. It would be better to do this, if this is intentional: def my_calc(x,…

Why not just default scale to 1? I get that you might want to know if it was supplied or if it is the default, and common lisp has a way to do that. It is very niche to need, thought. That all said, I think this is just suffering the fate if anything with examples. I accept there are places where zero as false can be annoying.

Yes. Or set scale to 0 or something.

Generally speaking we're creating contrived examples because in all fairness, I've only seen this once I can remember in the last 5 years of writing business logic in python. Usually language purists would prefer us to be explicit in our languages. And type safety is the best thing since sliced bread.

But effectively that's why python has taken off. Types do matter, but for most things they don't Lots of good software has been written using python.