Book as a binary interface to the operating system - comments please!

[chris hermansen]

Good morning everyone,

On Thu, Jan 15, 2026 at 8:27 AM Jose E. Marchesi <jemarch@gnu.org> wrote:

>
> Hi Chris.
>
> > Good afternoon everyone,
> >
> > Awhile back, I proposed that GNU Algol 68 implement Book as a binary
> stream
> > interface to operating system files, which is opposite to the strong
> hints
> > in the Revised Report.
> >
> > Jose commented that such a binary interface should best be implemented by
> > using short short bits rather than byte, given that the RR lays out byte
> > and its associated operators as a way of packing characters, which could
> > possibly be used to stream char through a byte interface, would be of no
> > use whatsoever in streaming binary.
> >
> > (Jose please jump in here and correct me if I'm wrong or even just being
> > too glib).
> >
> > Thinking further about the idea of Book implementing a binary stream, it
> > seems to me it would handle the putting and getting of bytes by calling
> > POSIX routines meant to handle this task.
> >
> > Does this seem reasonable?
> >
> > If that is to be the case, then the POSIX interface in Algol 68 would
> need
> > to be enhanced to provide these binary putting and getting functions.
> >
> > Is that something that the developers would contemplate in the near
> > future?  And if so, would it be possible to determine (before
> implementing
> > it) the declarations of the needed procedures?
> >
> > Thanks in advance!
>
> Yes the idea always was to implement the Transput on top of the
> lower-level POSIX prelude.
>
> There are a lot of things to add to the POSIX prelude.  Stuff that I am
> already needing in my own programs: gettimeofday, sleep, installing
> signal handlers, etc.
>
> So please ask what you need :)
>

Ok, here it comes... also please if you see something that looks weird or
wrong, advice on how to improve it would be appreciated!

According to https://gcc.gnu.org/onlinedocs/ga68/POSIX-files.html we
already have open, various flag bits to control the open, close, get a
string and put a string:

 proc fopen = (string pathname, bits flags) int;

bits file_o_default = { some bits value }; { Flag for fopen indicating that
the file shall be opened with whatever capabilities allowed by its
permissions. }
bits file_o_rdwr = { some bits value }; { Flag for fopen indicating that
the file shall be opened for both reading and writing. }
bits file_o_rdonly = { some bits value }; { Flag for fopen indicating that
the file shall be opened for reading only. }
bits file_o_wronly = { some bits value }; { Flag for fopen indicating that
the file shall be opened for write only. }
bits file_o_trunc = { some bits value }; { Flag for fopen indicating that
the opened file shall be truncated upon opening it. }

proc fclose = (int fd) int;

proc fgets = (int fd, int n) ref string;
proc fputs = (int fd, string str) int;

Correct?

I propose that we add one more flag bit:

bits file_o_binary = { some bits value }; { Flag for fopen indicating that
the file shall be opened for binary reading and writing, primarily for
non-Linux compatibility }

two more modes

mode Byte = short short bits;
mode Byterow = []Byte;

and two more procedures

proc fgetb = (int fd, int n) ref Byterow;
proc fputb = (int fd, Byterow br) int;

In my mind,

Byterow buffer = fgetb(infd,42)

would correspond to the C code

read(infd,buffer,42);

and

Byterow br = { some sequence of Byte values };
int bw = fputb(outfd,br)

would correspond to the C code

int bw = write(outfd,br);

Is this making sense?

-- 
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/20260115/b9b0613e/attachment.htm>