Question - internal representation of char in Algol 68

[Jose E. Marchesi]

> Thanks for the clarification, Jose.
>
> On Fri, Jan 9, 2026 at 2:17 PM Jose E. Marchesi <jemarch@gnu.org> wrote:
>
>>
>>
>> > Ok, I found this:
>> >
>> > https://gcc.gnu.org/onlinedocs/ga68/POSIX-string-transput.html
>> >
>> > where it states:
>> >
>> > The following procedures read or write characters and strings from and to
>> >> open files. The external encoding of the files is assumed to be UTF-8.
>> >> Since Algol 68 chars are UCS-4, this means that reading or writing a
>> >> character may involve reading or writing more than one byte, depending
>> on
>> >> the particular Unicode code points involved.
>> >
>> >
>> > There appears to be some difference between UTF-32 and UCS-4; see this
>> > article
>> >
>> >
>> https://stackoverflow.com/questions/30186631/what-is-the-difference-between-utf-32-and-ucs-4
>> >
>> > in which comments indicate:
>> >
>> > UCS-4 and UTF-32 are now identical except that the UTF-32 standard has
>> > additional Unicode semantics
>> >
>> > and
>> >
>> > "Additional Unicode semantics" means the extra properties Unicode adds
>> >> above and beyond the code points, such as bidirectionality, collation
>> >> rules, normalization of forms, etc. Some features of Unicode have been
>> >> implemented in software that technically only supports UCS, but those
>> are
>> >> extensions that partly implement Unicode.
>> >
>> >
>> > So I guess I should ask, is Algol 68 char really UCS-4 or is it rather
>> > UTF-32 and includes those extra semantics?
>>
>> For `char' We are effectively using an unsigned 32-bit value, and then
>> using code from GNU libunistring that interprets that value as:
>>
>>  -- Type: ucs4_t
>>      This type represents a single Unicode character, outside of an
>>      UTF-32 string.
>>
>>
>> Knowing the author of libunistring, who I am adding in CC, I am sure
>> that formulation is very precise and not casual.  Looks like once youg
>> et an UTF-32 encoded element from its string, it becomes UCS-4.  Seems
>> to me that an UCS4 becomes UTF-32 only in relation to other
>> "neightbourghing" characters..
>>
>> > Not knowing the depth of collation rules, I can imagine there would be
>> > circumstances where we might want to apply collation rules for comparing
>> > two strings and other circumstances where we don't.  I further suppose
>> that
>> > would require two different operators, maybe EQ and COLLATESTO?
>>
>> We have no choice hen it comes to string equality with =.  The semantics
>> are based on comparing the ABS values of each 'char' as you can see in
>> the code in the section 10.2.3.10 of the RR:
>>
>>
>>   op < = (string a,b) bool:
>>   begin int m = UPB a[@1], n = UPB b[@1]; int c := 0;
>>         for i to (m<n|m|n)
>>         while (c:=ABS a[@1][i] - ABS b[@1][i]) = 0
>>         do skip od;
>>         (c=0|m<n AND n>0|c<0)
>>   end
>>
>>   op <= = (string a,b) bool: ~(b<a);
>>
>>   op = = (string a,b) bool: a<=b AND b<=a;
>>
>
> I did not think to look this up, thanks for doing so and my apologies for
> being sloppy.

Note that ga68 implements comparing strings by calling the libunistring
function u32_cmp because that function implements equivalent semantics
than the RR version, i.e. it compares each 32-bit code one by one,
implementing lexicographical ordering.

> I guess we know that ABS c is going to deliver the Unicode codepoint value
> of C.

In GCC, yes.

> But I understand that Unicode collation provides quite a bit more
> flexibility than ABS x - ABS y; for instance it can apparently handle
> digraphs.
>
> So a separate operator COLLATESTO could be quite useful to the programmer
> in certain circumstances.

We need a good Unicode library for Algol 68, which could be to wrap GNU
libunistring :)

>
> I don't really get the comment as to how UCS-4 and UTF-32 are the same
> except that UTF-32 has some additional Unicode semantics...
>
>>
>>
>> > On Fri, Jan 9, 2026 at 1:12 PM chris hermansen <clhermansen@gmail.com>
>> > wrote:
>> >
>> >> I notice in the online docs here:
>> >>
>> >> https://gcc.gnu.org/onlinedocs/ga68/Standard-modes.html
>> >>
>> >> this information:
>> >>
>> >> Mode: char
>> >>
>> >> Mode for character values. The character values are mapped one-to-one to
>> >> code points in the 21-bit space of Unicode.
>> >>
>> >> To me this implies that char is implemented as UTF-32.  And for some
>> >> reason I think I have read that elsewhere, but I can't put my finger on
>> it.
>> >>
>> >> Please confirm (or not) that mode char is UTF-32!
>> >> --
>> >> Chris Hermansen · clhermansen "at" gmail "dot" com
>> >>
>> >> C'est ma façon de parler.
>> >>
>>