modes Book and Channel and binary vs character transput: a proposal

[Jose E. Marchesi]

> Sorry to keep responding to myself as I find out more things... If someone
> prefers that I do this a different way please let me know.
>
> I have learned some more about MODE bytes vs MODE char which I will append
> to the below.
>
> On Thu, Jan 8, 2026 at 12:06 PM chris hermansen <clhermansen@gmail.com>
> wrote:
>
>> Hello everyone,
>>
>> I've been reading RR, Lindsey AB42.4.4, Sian Mountbatten's PAME,
>> McGettrick and also bouncing around in C stdio and java.io.* and I have a
>> collection of modest proposals for GNU Algol 68
>>
>> Given that MODE Book is not exposed to the programmer,
>>
>> ===> I propose that MODE Book deal with byte streams.
>>
>> Furthermore, given that MODE Channel is exposed to the programmer (as an
>> opaque type) and by the RR contains a hidden procedure "standconv" that is
>> responsible for converting "characters to and from the values as stored in
>> "internal" form and as stored in "external" form in a book (RR §10.3.1.2
>> Channels p. 142) and that this hidden procedure is publicized to the
>> programmer via
>>
>> PROC standconv = (Channel chan) PROC (REF BOOK) Conv: standconv OF chan
>>
>> ===> I propose that standconv OF chan is responsible for converting bytes
>> to characters and vice versa (in whatever character encoding may be
>> selected).
>>
>> Given that I have proposed above that MODE Book deal with byte streams, it
>> seems reasonable a reasonable corollary that PROC (REF Book) BOOL bin would
>> therefore always return true.
>>
>> As far as I am able to tell, the various put and get procedures all set
>> either char mood or bin mood without worrying about their current values:
>>
>>    - In RR §10.3.1.4 Opening and closing files, both PROC establish (p.
>>    149) and PROC open (p. 150) attach standconv OF chan to the instance of
>>    MODE File created during the open process, thereby enabling instances of
>>    MODE File to carry out the byte <-> character conversion.
>>    - In RR §10.3.3.1 Formatless output, PROC put (p. 166) calls set char
>>    mood(f) thereby establishing that the PROC standconv attached to File f
>>    should be used to convert characters to bytes on the way out.
>>    - In RR §10.3.5.1 Formatted output, PROC putf (p. 195) calls set char
>>    mood(f) thereby establishing that the PROC standconv attached to File f
>>    should be used to convert characters to bytes on the way out.
>>    - In RR §10.3.6.1 Binary output, PROC put bin (p. 206) calls set bin
>>    mood(f) thereby establishing that no character conversion should be used on
>>    the data on the way out.
>>    - In RR §10.3.3.2 Formatless input, PROC get (p. 169) calls set char
>>    mood(f)  thereby establishing that the PROC standconv attached to File f
>>    should be used to convert bytes to characters on the way in.
>>    - In RR §10.3.5.2 Formatted input, PROC getf (p. 201) calls set char
>>    mood(f)  thereby establishing that the PROC standconv attached to File f
>>    should be used to convert bytes to characters on the way in.
>>    - In RR §10.3.6.2 Binary input, PROC get bin (p. 206) calls set bin
>>    mood(f) thereby establishing that no character conversion should be used on
>>    the data on the way in.
>>
>> Also in RR §10.3.1.4 Opening and closing files, both PROC establish (p.
>> 149) and PROC open (p. 150) initially call the PROC set char mood if the
>> PROC bin possible returns false.  However, given that I have proposed above
>> that MODE Book deal with byte streams, it seems reasonable a reasonable
>> corollary that PROC (REF Book) BOOL bin associated with MODE Channel would
>> therefore always return true, and so neither PROC establish nor PROC open
>> would ever initialize set char mood on the file.
>>
>> ===> I propose that the way open, establish, put, putf, put bin, get, getf
>> and get bin are specified by the RR, there is no concern with regard to
>> MODE Book dealing only with byte streams.
>>
>> RR §10.3.6 Binary transput p.206 defines two hidden procedures, to bin and
>> from bin.  I've noticed in reviewing java.io.DataInputStream and
>> java.io.DataOutputStream that care is taken to ensure that a consistent
>> byte ordering is used no matter whether the machine hardware is little- or
>> big-endian.
>>
>> ===> I propose that PROC ℵ₀ to bin and PROC ℵ₀ from bin take a similar
>> approach to machine-independent byte ordering for transput.
>>
>> I think I'll stop now!
>>
>
>>
>
> RR §6.5. Widening states:
>
> Widening transforms integers to real numbers, real numbers to complex
> numbers (in both cases, with the same size), a value of mode 'BITS' to an
> unpacked vector of truth values, or a value of mode 'BYTES' to an unpacked
> vector of characters.
>
> That sounds kind of parallel to transforming one or more UTF-8 characters
> to Unicode or vice versa.  But it also makes MODE bytes sound like it only
> exists to compactly represent MODE char.  Especially when we see just after
> that in §6.5.1:
>
> BYTES : : structured with row of character field SITHETY letter aleph mode.
>
>
> and sure enough in §10.2.2:
>
> mode L bytes= struct (LI : L bytes width J char L F); (See 10.2.1.m)
>
>
> and in §10.2.3.9. Bytes and associated operations
>
> a) op R = (L bytes a, b) bool: string (a) R string (b);
>> b) op { elem, [] } = (int a, L bytes b) char: (L F of b)[a];
>> c) proc L bytes pack = (string a) L bytes :
>>      if int n = upb a [@ 1 ] ;
>>        n 5.L bytes width
>>      then L bytes c;
>>        for i to L bytes width
>>        do (L F of c)[i] := (i ≤ n | a [@1][i] | null character) od;
>>        c
>>      fi;
>> d) op leng = (L bytes a) long L bytes: long L bytes pack (a);
>> e) op shorten = (long L bytes a) L bytes: L bytes pack (string(a)[: L
>> bytes width]) ;
>
>
> Ie there appears to be no imagined use of bytes as one or more unsigned 8
> bit integers.
>
> So maybe my proposal to have MODE Book associated with streams of bytes in
> order to handle both character and binary transput is not so great after
> all :-(

It was clear to me since the start that BYTES was doomed.

In fact that mode is the only feature of the Algol 68 core language (not
including prelude and transput) that, IMO, is totally obsolete and
pretty useless.  And that is probably why that mode and associated
standard operators are the last piece of the core language that still
need to be implemented, along with parallel clauses :)

For us a BYTES value can only pack one CHAR.


We are considering adding a Byte mode to the extended standard prelude
as a convenient synonym for `short short bits' which, in GNU Algol68 is
always guaranteed to be 8 bit wide.  So a Book could still be a sequence
of `Byte's, not to be confused with BYTES..