Question - internal representation of char in Algol 68

[Jose E. Marchesi]

> 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;


> 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.
>>