This looks homeomorphic to the Maybe monad.
homeo implies continuity
Struggling to imagine it? Don't worry. John H Conway has done it for you.
2025, we can all just use integers and carry one less variable type in our sack.
Next we replace integers with floats and we’re done. 3 birds, 1 stone.
I highly doubt that. Let's call a boolean that is represented as one bit "true boolean type" Since no instruction set (that i'm aware of) has boolean operators, a "true boolean" would require every operation on it to evaluate to multiple bit-wise operations, which take up registers and cycles. Flags in registers are "true boolean", but they're usually operated on explicitly like int with bit-wise operators.
There is also the issue of bit alignment, atomic access, and stack and heap allocations being byte based; further restricting how a language that had "true booleans" would be able to actually be able to work with them.
I know that there are some languages that allow boolean arrays to be packed tightly as "true boolean", but that is a rare exception. Even char and byte types has this issue sometimes, but are more commonly "properly packed".
> we can all just use integers
So it's all integers already. The most common implementation of boolean around is probably #define true 1
But we really should use enums more instead of boolean. "fail, success, bad_param, error_404" is equally efficient to return as a bool.
> Next we replace integers with floats.
No. (well python and JavaScript kinda does already, but no) https://en.wikipedia.org/wiki/Pentium_FDIV_bug
true = 1
false = 0
perhaps = 0.5> Let me know if you’ve seen anything more similar.
If you take static typing off the table, then Icon's goal-directed execution is very much an inspiration in this area.
[1]: https://journal.stuffwithstuff.com/2023/01/03/type-checking-...
We ideally want an infix function that can reduce the "truthiness" of two values.
Let us imagine this language is a Haskell-type-thing, and we can define pseudo-operators with pattern matching
infixr 3 &&
(&&) :: Optional -> Optional -> Optional
Empty && _ = Empty
_ && Empty = Empty
Some A && Some B = Some A
_ && _ = Empty
infixr 2 ||
Some || _ = Some
None || Some = Some
None || None = None
_ || _ = None
a = b && c
d = e || f
https://en.m.wikipedia.org/wiki/Elvis_operator
?:-)
The first one has some arbitrariness (do you take the left or right value if both are Just). But, thankfully the Applicative typeclass gives both <* and *>, which lets you choose which value you want:
Just A <* Just B = Just A
Just A *> Just B = Just B
` if (node.last_child(s) is Ok(last_child))`
Is the part between the () not ultimately the same as a boolean expression? Like he wrote his own implementation of if/else syntax?
Also in the beginning he says: "An if with an else can produce a value", but isn't this just 'syntactic sugar'? I think the code that actually runs is the same as if you'd write if (value x = some_value) {value = something} else {value = something_else} ?
There would be no branching if there were no "if". It's basic assembly. Not jumps. No loops.
It isn't going to matter that it's technically a "JSON::false" or whatever... you're still going to get people calling that a wart forever. ("But a JSON::false would be a None" - no, you need that for either "null" or "missing". A JSON library has to have an exposed "false" value to distinguish it from null and missing, both for input and output.)
I'm not saying that doesn't mean to try this out, but as more of a heads up and something to talk about explicitly in the eventual tutorial.
Personally, I find myself fairly satisfied with if statements rigidly requiring a boolean and refusing to have a concept of "truthiness", which I consider a mistake, and I'm not sure this is solving real problems I've had. A user can always write the Option vs. None themselves in an if statement with mandatory else if they want. This introduces a wrapper level of Option that may not always play nice in real code (I mean, a lot of sum type types essentially already have it built in with things like "type Color = Red | Blue | Green | Unspecified" where adjoining a None is often unnecessary) and may really tempt you towards a concept of truthiness that may be a bigger wart than when you're trying to fix. It's pretty hard for a computer programming language to essentially evict the concept of a "bit" from the language. I'm not sure it can be done in practice, but it's fun to think about it and I encourage the pondering.
Aardwolf•2h ago