Looking deeper on transput, part 1 - comments please

[chris hermansen]

Hello all,

As I mentioned in another email, I'm trying to solidify my perspective on
Algol 68 transput by working through what was described in the Revised
Report and comparing that to what might be needed by present-day systems.
I was looking at Java's I/O model but I've switched over to C / POSIX for
the time being as my basis for comparison.

Basically I'm working on a table with three columns.

The first column is what the RR provides, grouped according to
functionality and starting with "doing stuff" - opening and closing files,
reading and writing...

The second column offers suggestions as to where changes may be advisable,
given the "present day system" context, bearing in mind that a good
principle is "as few as necessary".

The third column suggests how to accomplish something similar in C.

So far, I have done open / establish / create / associate; close / lock /
scratch; get / put.

TL;DR For these procedures, mainly we need to review the events to ensure
that we have everything we need; we may also find some to eliminate.
Additionally I think it wise to replace the "position in book" concept
(page, line, character) with a long int position, which would imply a
change to the establish procedure.

In more detail, but still briefly, here is what I have learned so far.

   - we should examine the list of events to ensure we have all we need to
   handle reading, writing, closing, locking, scratching, setting and anything
   else
   - proc open seems ok as-is
   - proc establish seems better without parameters p, l, c - is there a
   situation in present-day operating systems where we want to create a
   fixed-length file? maybe... and if so, we probably just want to say how
   many bytes, or characters, or similar
   - proc create seems ok as-is
   - proc close should either
      - explicitly rely on events to communicate problems with closing, or
      - return int rather than void
   - proc lock should either
      - explicitly rely on events to communicate problems with locking, or
      - return int rather than void
      - and by the way what exactly is a lock as envisioned here?
   - proc scratch should either
      - explicitly rely on events to communicate problems with scratching,
      or
      - return int rather than void
      - as well, Lindsey's comments notwithstanding, it seems "heavy" to
      require opening a file in order to then immediately close and
delete it, in
      the same way as needing to open a file in order to rename it.
   - proc get can be left as-is but merits some discussion:
      - get will raise various events depending on the input stream
      - however in order to decide whether calling get is permitted on the
      given file we must call get possible;
      - but "get possibility" could change during the course of the
      execution of a call to get, so again get must explicitly rely on
events to
      communicate problems that occur during getting
      - get depends on mode intype which is sorely needed and extremely
      difficult to code in Algol 68
         - mode simplin can be coded in Algol 68 using sppp, but it is not
         published (aleph0)
         - op straightin cannot be coded in Algol 68 and is not published
      - proc put can be left as-is but merits some discussion:
      - put will raise various events depending on the output stream
      - however in order to decide whether calling put is permitted on the
      given file we must call put possible;
      - but "put possibility" could change during the course of the
      execution of a call to put, so again get must explicitly rely on
events to
      communicate problems that occur during putting
      - put depends on mode outtype which is sorely needed and extremely
      difficult to code in Algol 68
         - note mode simplout can be coded in Algol 68 using sppp, but it
         is not published (aleph0)
         - op straightout cannot be coded in Algol 68 and is not published

Love to have comments, complaints, etc!
-- 
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/20260105/3e595d31/attachment.htm>