[RFC] Unsigned modes

[Jose E. Marchesi]

> Hej All,
>
> Well, it's not bad news at all, there is a way forward as stated using
> SIZETY.
>
> If this is the route to take, then the question is "Will there be a
> non-sizety uint mode as well?"
>
> In other words, would we have "uint", "long long uint", etc. etc...
> with all the algol68 lengthening aspects as well?
> This would be nice so that everything does not look "too C-like", and
> it would keep the nice symmetries of algol68.

Yes, SIZETY covers LENGSETY, SHORSETY and FIXETY.

>
> /James
>
>
>
>
>
> On Fri, Sep 25, 2026 at 6:39 PM Jose E. Marchesi <jemarch@gnu.org> wrote:
>>
>>
>>
>> I just realized that the bits modes have standard relational operators
>> in the standard prelude, but with different semantics than integral
>> comparison.
>>
>> This is a bummer.  I don't like at all the idea of having a mode bits
>> with unsigned modular arithmetic operators, and at the same time
>> relational operators not implementing the total ordering of unsigned
>> integers.
>>
>> Only for that reason, IMO introducing a SIZETY uint mode would be
>> better.
>>
>>
>> > Hi Chris.
>> >
>> > Thanks for the comments.
>> >
>> >> Good morning everyone,
>> >>
>> >> On Fri, Sep 25, 2026, 07:25 Jose E. Marchesi <jemarch@gnu.org> wrote:
>> >>
>> >>>
>> >>> Hello people!
>> >>>
>> >>> In standard Algol 68 integral modes are always signed.
>> >>>
>> >>> Having unsigned integral modes would help with:
>> >>>
>> >>> 1. While doing FFI or transput, in which unsigned quantities should have
>> >>>    some particular precision.
>> >>>
>> >>> 2. When unsigned arithmetic is desired, i.e. wrapping logic on overflow.
>> >>>
>> >>> To this effect I propose the following.
>> >>>
>> >>> There is no need to introduce new standard modes in order to achieve
>> >>> unsigned modes.  The standard `bits' mode is naturally implemented as
>> >>> unsigned magnitudes with the same size than the corresponding signed
>> >>> ints.  That is the case of ga68.  So it would be enough to define
>> >>> unsigned arithmetic operators in the expanded standard preclude that
>> >>> operate on bits, +, -, %, *, etc.  And implement these as compiler
>> >>> built-ins. This does NOT require any language extension.  With this, one
>> >>> would just use `bits', `long bits', etc, for operating with unsigned
>> >>> integral values, rather than `int', `long int', etc.  Note we support
>> >>> decimal radix 10r in bits denotations, as a GNU extension.
>> >>>
>> >>> We could improve ergonomics by going a little bit further:
>> >>>
>> >>> OPTIONALLY, we could have the compiler understand `uint' as a synonym of
>> >>> `bits'.  A language extension would be necessary for this so one could
>> >>> write `SIZETY uint' declarers.
>> >>>
>> >>> Opinions?
>> >>>
>> >>
>> >> I like the idea of broadening the utility of language with operators per
>> >> your first option.
>> >>
>> >> Not being a "deeply grounded in C" person I also prefer thinking of bits
>> >> for shifting and logical operations, rather than integers.
>> >
>> > Yes I do the same.
>> >
>> >> I don't mind slipping back and forth between int and bits to mix logical
>> >> and arithmetic operations. It can feel clumsy but it also makes clear what
>> >> is going on. However, the business of overflowing from positive to negative
>> >> requires extra effort to detect and I would definitely prefer to have < >
>> >> etc available for bits.
>> >>
>> >> So in general more operators but no new fundamental modes would be my
>> >> preference.
>> >
>> > Ok we are on the same page then :)
>> >
>> >>
>> >>>