Stop adding booleans to programming langugaes

[low bramble]

https://goldenstack.net/blog/stop_adding_booleans

wrote a blog post, heavily based on what i've discussed here

[zealous osprey]

how does having 1 bit integers/2 inhabitant integers in a language solve the problem of truthiness?

to me it seems like you'd just be moving the problem from a designated type to another one

ie a programmer that's lazy enough to use a boolean instead of an enum would possibly be equally lazy without booleans and just use u1

[low bramble]

it's to solve the overloading of the boolean type

i think moving it around here is fine because it moves some uses of boolean into something more readable, and moves the other uses of boolean into something that already exists (and represents the issue more accurately imo)

[edgy zinc]

Me when I int

[austere aspen]

i went into this post expecting to disagree with it, but i find myself convinced by many of the points

i do think a point could be made for a boolean type that is restricted to use in if statements

so u couldnt store it in a variable or anything

but u could avoid the clunkiness of is is

tho ig u could just replace is with == as syntax and thatd work fine

ok i retract my point

[low bramble]

fire

[low bramble]

yeah true, i mainly provided a list of examples for if just to show there's a solution

so there are a bunch of things i didn't write in there

(also, i added the part about if statements 4 hours ago, so if anyone doesn't remember that part from reading it, that's why)

[cloud raven]

some interesting points, but you seem to have completely glossed over the need for short-circuiting operators. short-circuiting or and and make no sense for numeric types, and bitwise | and &, which do make sense for u1, don't short-circuit, which is sometimes very important

[wanton wyvern]

what type would you use as the result of more complex comparisons? your example doesnt cover any typical use cases of booleans (only "use in if")

also did you know that in Python a bool is an int?

[wanton wyvern]

could you give me an example on how you would express this expression here?

pub fn @"suspend"(thread: *Thread) void {
        if (!thread.flags.started or thread.flags.finished or thread.flags.suspended)
            return;
    ...  // impl here
}

or a more general question: how would you handle typical boolean questions like isReached(), isCancelled(), ... in a way they are composable

[low bramble]

kinda true, but i don't know why you couldn't add short circuiting bitwise operators

[low bramble]

well to be fair i think it actually covers quite a lot of the typical use cases of booleans
also i was gonna say that bools arent integers, they can just be converted to them implicitly, but i think this would lead to a lot of semantic arguments so im not gonna argue that

[low bramble]

i feel like in this specific case you could rework it to be a multi-case switch over something like thread.state, but that doesnt handle the general case either way

i mean there are definitely ways to do it for each case, its just that im used to booleans being important in programming so im not entirely used to figuring out how to do stuff without them

actually if you port it directly i guess you could do AND via like
if ((a, b, c) is (.x, .y, .z)) (using (a, b) as the tuple constructor)

[wanton wyvern]

because the only work semantically for booleans/u1

[wanton wyvern]

this would force a lot of de'morgan into your language, and would still require highly complex constructs like pattern matching to do something like a or !(x < low or x > high)

[wanton wyvern]

# class int(object): ...
# class bool(int): ...

assert isinstance(True, bool)
assert isinstance(True, int)

assert not isinstance(1, bool)
assert isinstance(1, int)

assert True == 1

is valid for python

which is a really weird way of doing it

[wanton wyvern]

threads can have several independent states and modelling those 3 bits as booleans was simpler than modellinh as enums or a single enum, as finished does not imply start nor suspended.

a thread could be suspended and finished, but not started (and starting it would be an error)

[low bramble]

not necessarily, and idk why that would be an issue anyway

[low bramble]

oh i just meant it for the and case

[low bramble]

well i feel like this is two different things
if we didn't have booleans it wouldnt be simpler to use them
and for the suspended & finished thing, that just means you'd have to represent it differently idk

right now you have 3 bits but at least 1 invalid yet representable state

[teal skiff]

Inside the function call, too, operations like depth OR false will now emit a compile error, as they no longer make any sense...

Well, it doesn't make sense in the first place. A OR 0 = A

Oh, unless you mean an expression that evaluates to 0.

In that case, I'm not sure why it'd be better to get a compile error instead of a short circuit.

[wanton wyvern]

de'morgen transforms or into and, so it would still be applicable, just with more nots 😄

[wanton wyvern]

which is?

[wanton wyvern]

short-circuit only works when an operation has boolan semantics tho, as it works on logic operators

[low bramble]

it doesnt make sense, it's just an example of operations that are meaningless in context

[low bramble]

yeah ik, there are prob other ways to figure out or though

[low bramble]

suspended finished and started, like u said

[low bramble]

short circuiting is just a special case of knowing the result of the expression without fully evaluating it, and you can just generalize it to cases like this

[cloud raven]

absolutely not

[low bramble]

absolutely not what

[cloud raven]

fooThatTheCompilerKnowsButIDont +| sideEffectsICareAbout()

[low bramble]

i don't mean aggressively short circuiting btw and especially not without it being obvious in the operator

like im not saying that +| should, im just giving an example of where the result is known

[cloud raven]

i mean, if you're not saying to actually do short circuiting, i don't really understand your point

you really can't generalize short-circuiting to other operators in a sane way, it's a very boolean-specific thing

[low bramble]

im saying don't introduce it into things that did not previously short circuit

[cloud raven]

i thought u were saying it generalizes to ints, therefore it's fine to have it on ints so we don't need bools?

[low bramble]

oh to clarify, don't introduce it into operators that didn't do it previously

so u can just add some new character in the operator if you really need short circuiting

[cloud raven]

so what are you suggesting?

[low bramble]

although if you think about it's kind of weird for some operators to short circuit and some to not in a non-obvious way, in mainstream programming you kind of have to just know that boolean operators short circuit

[low bramble]

oh i realized we got pretty off topic

[cloud raven]

this is why zig makes and and or keywords instead of operators

[low bramble]

if you really do need short circuiting it can be an alternative operator type on ints, a function on std.bool (or another operator if your language supports operator overloading), or both

but from my experience it has not been critical to have

since there are like a million ways to get the same behaviour anyway

[cloud raven]

the real solution is to just get rid of side effects too :3

but in all seriousness, i really don't think getting rid of booleans is the answer. making enums easy to use basically solves the only actual problem your blog post talks about, which is that bools in function args are very opaque (which i 100% agree with)

the comparison to null really doesn't make any sense to me tbh. null is a problem because of the pointer thing, not because it only has one value

[low bramble]

fwiw in any real language i would add booleans just because (1) the arguments for removing them could be stronger and (2) people are so used to them
the only reason i'm not going to have them in mine is because i'm being experimental anyway

[cloud raven]

there are a lot of types with one value (or even no values) that are very useful and important

[cloud raven]

yeah that's fair, being experimental and trying things out is as good a reason as any :)

[low bramble]

the issue isn't that it has one value, i was just drawing a comparison the issue is twofold: (1) it's added accidentally and (2) this addition has no meaning to the actual type

if the null pointer were instead replaced with an actual default value i think it would be much less catastrophic

so like, booleans are abstract in a similar way, but obviously without what is by far the main downside of null

[cloud raven]

i mean, integers are also abstract ¯_(ツ)_/¯

i don't think bools are meaningfully more abstract than integers

[low bramble]

yeah so we may as well merge booleans into integers :D fewer unique categories of stuff

[cloud raven]

they're just a bit more weird because they don't come up very often in every day life

[cloud raven]

well, no, because booleans don't behave like integers

they have their own algebra that follows different rules

[low bramble]

i was considering removing integers and instead having @Set(123) or something

and integers are a std lib addition that work on top of that

[cloud raven]

damn

[low bramble]

the issue: (1) what would be the parameter type of @Set and (2) literally all the other issues you can think of off the top of your head

[cloud raven]

this is beginning to sound like that lisp concept i thought up where the entire compiler is implemented in-language using macros

[low bramble]

lmfao

my languages tend to get like that

my previous one started out like this

[cloud raven]

i feel like u'd like lambda calculus

[low bramble]

and ended up being basically walmart lisp

[low bramble]

it's kinda goated, unfortunately i kind of like types

[cloud raven]

it's ur lucky day https://en.wikipedia.org/wiki/Typed_lambda_calculus

[low bramble]

lambda cube moment

i was talking w friends about how if you have lambda calculus as an additional compile target, your programs are like 1000x more portable always

but using it for actual programming is a little cooked

[cloud raven]

we love blc

[low bramble]

yess

half-byte cat knower?

anway, i think removing booleans are about as far as i'm willing to go

removing integers i will think about once the language actually works

[cloud raven]

i actually never even thought about the fact that id is cat

i wonder how hard it'd be to make a zig blc backend

probably very annoying given you'd have to simulate memory :(

[low bramble]

Universe -> Universe moment 🧌

[low bramble]

how hard is it to do this

[cloud raven]

well. https://github.com/woodrush/lambda-8cc

that's... insane

given it can compile to blc too, there's the zig backend 🙃

just use cbe and pipe it into that

[low bramble]

fire

i hope it can compile c to blc like

with actual code not with super slow lc

[low bramble]

maybe once my language actually compiles (rn it only interprets) and i've written a bunch of code i'll do a retrospective

on not having booleans

[reef ridge]

didn't read the whole thread, but I didn't see anywhere in the article comparison operators or boolean operators were handled.

also:

Does deep OR other_boolean have any actual meaning? I don’t think so.

sure it does. there's plenty of times where you have logic conditional on two things. just because they aren't true/false doesn't mean boolean algebra doesn't work on them, or make any sense.

it's the equivalent of:
traversal_mode == brief OR other_condition == whatever_truthy_variant_for_this_case

if you want that to be spelled out, that's fine with me.

only question I have is: what is the result type of the equality operator there?

[low bramble]

I didnt mean in the general case

I mean there are just a lot of cases where booleans are used for their cardinality instead of their operations

which includes this case

[reef ridge]

Ah yeah, definitely agree with the rough idea of the post. Just trying to ask in a challenging way to present the criticism

And I'm not sure what the result type should be of comparisons, if I didn't have bool. u1 would work but it would feel kinda clunky to me.

And I often store the result of a comparison in a local variable, so I can remember an earlier result while doing a related mutation or action, then have a different side effect afterwards.

[severe sparrow]

@low bramble loved the read. very interesting idea to keep in mind ✍️

[bold oxide]

that one should use enums - or different methods - to select behavior in function params and avoid bool doesn’t alone mean bool isn’t useful nor needed.

[low bramble]

yeah, but i argued that you can move a lot of usages of boolean to integers

and a lot of other uses to custom enums

since bool is kinda overloaded

[bold oxide]

I disagree strongly. A set of flags (think config vars for instance) is booleans

and for instance that C ints decay into bools is actually a source of bugs

[crimson lotus]

Ummm just use C ☝️ 🤓

[edgy zinc]

C has booleans

[crimson lotus]

In the stdlib

Not in the language well until c 23 or 22 idk but anything after c 10 is basicaly not c

[edgy zinc]

No, only in C89 did booleans not exist. C99 added them with the spelling _Bool and a header stdbool.h to give you a macro for bool. C23 just added the spelling bool as a keyword

[austere aspen]

i haven't read this, but i just came across this article and it reminded me of this https://justinpombrio.net/2025/09/22/imagining-a-language-without-booleans.html

[low bramble]

lol yeah i read that too

[pine halo]

i feel like distinct types could solve a lot of these issues

[low bramble]

exactly

[pine halo]

i dont mean enum

[low bramble]

wdym then?

[pine halo]

like distinct types in odin

[low bramble]

ohh

ic

hmm