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

[chris hermansen]

Good evening!

On Fri, Jan 9, 2026 at 3:03 PM Jose E. Marchesi <jemarch@gnu.org> wrote:

>
> > Thanks, Jose, sorry to be coming late to the sad bytes party!
> >
> > On Fri, Jan 9, 2026 at 2:40 PM Jose E. Marchesi <jemarch@gnu.org> wrote:
> >
> >>
> >> > 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..
> >>
> >
> > This idea of using MODE bits rather than bytes seems like a good one.
> >
> > If you decide to proceed, I think you will also need a few more bits
> > operators to convert between bits and real, bits and char etc.
>
> Hmm, if we have:
>
>   mode Byte = short short int;
>   Byte b;
>
> then
>
>   `BIN b' yields is a `short short int' with a value between 0 and 255.
>

Really?  I thought short short int would be -128..127; is it not signed?

>
> You can then widen to short short real, do REPR to shar, and so on.
>

In the RR real x; BIN x - that BIN operator is not defined.  I (am pretty
sure I) would love to see BIN x just put the bit pattern in the bits value,
because it's more complicated than just sign / exponent / mantissa, there's
all that unnormalized stuff, infinities, NaNs etc.  To me it would be nice
to handle that all according to the IEEE standard in Algol 68 code, but for
lack of a BIN that delivers the goods.

>
> > Or alternatively rely on minor modifications to the two hidden
> > procedures defined by RR §10.3.6. Binary transput:
> >
> > a) proc {non-pub} to bin = (ref file f, simplout x) [ ] char:
> >     ¢ a value of mode 'row of character' whose lower bound is one
> >     and whose upper bound depends on the value of 'book off'
> >     and on the mode and the value of 'x'; furthermore,
> >     x = from bin (f, x, to bin (f, x)) ¢;
> > b) proc {non-pub} from bin = (ref file f, slmplout y, [ ] char c)
> simplout:
> >     ¢ a value, if one exists, of the mode of the value yielded by 'y',
> >     such that c = to bin (f, from bin (f, y, c)) ¢;
> >
> > Seems to me that to correctly support binary transput the [ ] char c will
> > need to be replaced with [ ] bits or maybe [ ] Bytes.
>
> Yes I concur. These would have to be []Byte I think.
>

I haven't really thought it through, but in my mind, we want to

- have real x = ...; BIN x deliver a 32 bit bits value
- have long real y = ...; BIN y deliver a 64 bit bits value
- have long long real z = ... BIN y deliver a ??? 80 bit bits value (or
maybe we want to emulate a 128 bit long long real, I don't know).

and I guess ABS going in the reverse direction

Then we could use Byte on a 8 bit by 8 bit basis to put the bytes in
canonical form into the binary file (I am pretty sure this is what Java
does, for instance).  So there is no little / big endian stuff to deal with
in the binary files.  All that being wrapped in to_bin and from_bin.


-- 
Chris Hermansen · clhermansen "at" gmail "dot" com

C'est ma façon de parler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/algol68/attachments/20260109/ed0a2adf/attachment-0001.htm>