If `Byte` is a `Number`, then why isn't a `Bit` /`Boolean`? Iirc, `Boolean` isn't actually stored w...

# announcements

[Hullaballoonatic]

If Byte is a Number, then why isn't a Bit /`Boolean`?

Iirc, Boolean isn't actually stored with just one bit in memory, but does that actually matter?

[Ruckus]

How it's stored doesn't really matter. When it comes down to it, everything is just stored as bytes. The difference is semantics. Byte represents numeric values and can perform numeric operations. Boolean doesn't.

[Hullaballoonatic]

Sure but isn't a Boolean logically equivalent to a Bit , which is a number

[streetsofboston]

I guess the same reason a Char is not a Number

[Ruckus]

Why do you say Bit is a number? (Also, Bit isn't a type in Kotlin, so that comparison doesn't really apply here).

[Hullaballoonatic]

What do non-ascii characters return when you call Char::toInt?

[Hullaballoonatic]

For whatever reason a Byte is a number, the same can be applied to a Bit

[Hullaballoonatic]

I'm saying Bit does exist in Kotlin. it's just called Boolean

[Ruckus]

I guess that depends on how you would define Bit. If you define it to be Boolean, then it has nothing to do with Byte.

[Hullaballoonatic]

A Bit is a 0 or 1. Logical operations with bits are logically equivalent to those performed with booleans. If two things are logically identical, they are the same thing.

[Ruckus]

Then that's not a Boolean. A Boolean is true or false. Not 1 or 0. They may be represented the same in memory, but that's irrelevant.

[Hullaballoonatic]

but in bit arithmetic 1==true, 0==false. all digital computation is based on Boolean logic by way of bit arithmetic. in bit arithmetic a bit is a True/False value.

[Ruckus]

They aren't logically identical by definition. `Boolean`s are logical, and that definition of Bit is numerical. You seem to be operating off the assumption that 1 === true and 0 === false, which isn't true.
(Sorry, I started writing that before I saw your message)

[Hullaballoonatic]

Why are logical and numerical mutually exclusive?

[Ruckus]

Not mutually exclusive, just orthogonal.

[Hullaballoonatic]

I apologize if I sound combative. I'm not arguing to win, more to explore a concept

[Ruckus]

If Bit were defined, it could be done in a way that makes it logical and numerical. Boolean just isn't.

[Ruckus]

Same here 🙂 I quite enjoy these kinds of discussions. They can make you rethink some of your assumptions, which can be very useful.

[Hullaballoonatic]

I guess my point is there need not be such a distinction. It is the same point as "Why does Kotlin/Java treat the boolean && differently from the bitwise and/& ? Shouldn't true xor false compile? It doesn't because true and false are not bitwise values, but in boolean logic if two statements have identical truth tables, they are logically equivalent; bitwise and and logical && have identical truth tables. Same goes for all bitwise and boolean unary and binary functions

[Ruckus]

In some languages it is true that 1 == true and 0 == false, but in others that's not true. Even if they are represented the same internally, it often makes sense (especially in strongly typed languages) to have them be semantically separated.

[Hullaballoonatic]

I guess I also question the lack of boolean xor, nor, nand in the language, too

[Ruckus]

I'm pretty sure xor is there, but not nand or`nor`.

[Hullaballoonatic]

the only one of which that is actually felt missing however is xor.

[Hullaballoonatic]

There's a Boolean::xor?

[Hullaballoonatic]

I know there's a bitwise one

[Ruckus]

Yep: https://pl.kotl.in/sz0z11H82

[Hullaballoonatic]

oh shit

[Hullaballoonatic]

my bad. I guess I just assumed it didn't exist since and and or are exclusive to bitwise operations

[Ruckus]

Yeah, there are a few downsides to infix vs operator. Unfortunately the existence of bitwise operators (while super useful) do blur the logical vs numerical distinction, but that could be cleared up by assuming a Bit type that is both numerical and logical and handles conversion to/from number types.

[Hullaballoonatic]

🤫 That line is so blurry because it actually doesn't exist...

[Ruckus]

😆

[Ruckus]

I guess you also then have to figure out if maybe true == 1 but true !== 1...

[Hullaballoonatic]

Should they hash to the same value?

[Ruckus]

Sure but lot's of things that hash to the same value aren't equal.

[Hullaballoonatic]

I mean. 1L !== 1
We're already pretty comfortable with different number types

[Hullaballoonatic]

Boolean would just extend Number and be comparable to other `Number`s.

[Hullaballoonatic]

I actually don't know what === vs == distinction is in kotlin. I initially assumed === meant equal hashcodes or that they must be the same javaclass, and that == was using compareTo operator, but that is not the case.

[streetsofboston]

=== compares the instance reference.

[streetsofboston]

== executes the equals method

[Ruckus]

That's not exactly true for primitives (which most numbers are as well as booleans)

[Hullaballoonatic]

therefore the only way to use operator compareTo to compare equivalency between 2 instances is to do x.compareTo(y) == 0? That's pretty silly

[streetsofboston]

True… for primitives, == and === are the same

[streetsofboston]

No, == should suffice for equivalency.

[Hullaballoonatic]

Well I know the following doesn't compile:

when(myLong) {
    0 -> ... // type mismatch Int/Long
    1 -> ... // type mismatch Int/Long
    else -> ...
}

[streetsofboston]

Hmmm… I thought equals takes an Any? as input parameter….

[Hullaballoonatic]

🤷‍♂️ I tried it today

[streetsofboston]

This maybe an additional check for a when clause by the compiler…. Wonder if the Number#equals enforces the receiver and the input parameter to be of the same class.

[Ruckus]

No, this comes down to primitive being special. There is no actual equals function for primitives on the JVM.

[streetsofboston]

True, but Kotlin is not just JVM…

[Hullaballoonatic]

https://pl.kotl.in/mbEKeSORC

[streetsofboston]

Something odd going on with Numbers with regards to `equals`… You can replace myLong == 0 , which won’t compile with myLong.equals(0), which does compile, but still complains

[streetsofboston]

Going back to the JVM, this is how equals is implemented for a java.lang.Long:

public boolean equals(Object obj) {
        if (obj instanceof Long) {
            return value == ((Long)obj).longValue();
        }
        return false;
    }

[Ruckus]

There's a fair amount of rewriting going on with the Kotlin compiler

[streetsofboston]

If the input parameter is not a Long, it will return false. Since it will always be false, myLong == myInt will not compile, since it always will return false …

[Hullaballoonatic]

Oh, and @streetsofboston Char is a Number in Kotlin

[streetsofboston]

public class Char private constructor() : Comparable<Char>

[Hullaballoonatic]

Oh, actually it isn't

[Hullaballoonatic]

i got confused because all `Number`s must include toChar

[Hullaballoonatic]

thank you