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

[chris hermansen]

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!
--
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/20260108/17b0c380/attachment.htm>