si32/ui32 vs i32/u32

[elliotwaite]

I saw this discussion on Discord, but I don't think there has been any follow-up yet, so I thought I'd repost it here since I'm also curious about this.

mji (mji#4398) 05/03/2023 10:05 AM:
i wonder why si32 and ui32 rather than i32 and u32 like in almost every other language out there

Chris Lattner (@lattner) 05/03/2023 12:26 PM:
Less ambiguity, but this isn't a closely held belief, we can change it if there is a reason to. WDYT @abduld ?

mji (mji#4398) 05/03/2023 12:54 PM:
I've just learned that i32 is a "signless" integer in MLIR, so if you're targeting compiler developers si32 is an useful distinction. However I would argue that the average Python programmer is more likely familiar with higher level languages (rust, zig, crystal, etc.) where people are already used to i32 being signed.

So it seems like the si32/ui32 syntax not only offers less ambiguity, but it also aligns with MLIR's built-in IntegerType syntax:

• si = signed integer
• ui = unsigned integer
• i = signless integer

However, I think mji makes a good point that Python programmers will probably be more familiar with the i32/u32 syntax.

Since I'm new to MLIR, I was wondering if any of the Mojo team members could share how they think about this tradeoff. For example, in which ways will being aligned with the MLIR syntax be helpful to Mojo users? Will this alignment primarily benefit users working at a lower level, closer to MLIR? Or will higher-level users also experience benefits? For instance, during debugging, could examining MLIR types be a part of that process?

Also, Mojo currently supports signed and unsigned integers, but would it ever makes sense for Mojo to also support signless integers? Or are those mostly only used internally by MLIR during the optimization/lowering process?

[lattner]

Yeah, for the core language types, our audience are general programmers and Python folks, not MLIR nerds ;-)

We want things to be clear and unambiguous, compiler folk can deal with naming mapping. Abdul is out on vacation this week but we can discuss when he returns.

would it ever makes sense for Mojo to also support signless integers?

I don't see a benefit to that. It would mean that we couldn't use the standard Python operators (which imply sign behavior, e.g. on divides). Signless integers are good for compilers because they want canonical forms, but users want operations that work on types. It's a bit of a different concern.

[elliotwaite]

We want things to be clear and unambiguous, compiler folk can deal with naming mapping. Abdul is out on vacation this week but we can discuss when he returns.

Sounds good.

I don't see a benefit to that. It would mean that we couldn't use the standard Python operators (which imply sign behavior, e.g. on divides). Signless integers are good for compilers because they want canonical forms, but users want operations that work on types. It's a bit of a different concern.

Okay, got it.