Standard prelude version Hans van Vliet

[chris hermansen]

Jose and list,

On Sun, Dec 28, 2025 at 3:30 AM Jose E. Marchesi <jemarch@gnu.org> wrote:

>
> For modernizing the transput I also recommend to take a look at:
>
>   AB42.4.4 C.H. Lindsey
>            ALGOL 68 and your Friendly Neighbourhood Operating System
>

This is a very worthwhile read, thanks for mentioning it.  Of particular
value for me are the indications as to the degree of congruence between
various actual operating systems (at the time of writing) and the Algol 68
transput model.

Of the systems mentioned, personally I am only directly and hands-on
familiar with MTS, which was the mainframe operating system in place at the
University of BC when I was an undergrad there and using Algol 68s (among
other languages of the 70s and earlier).  However I also have direct and
hands-on experience with IBM OS/VS1 (from the 1980s) and VAX-VMS (also from
the 1980s) along with System V (also from the 1980s), SunOS, Solaris,
Linux, DOS and Windows.

I can see the appeal of mode Book in systems like IBM OS/VS1, where system
files were generally record-based (often 80 column EBCDIC card images or
132 column EBCDIC line printer page images).

However, I continue to struggle with finding relevance for mode Book
today.  Here are some challenges I have stumbled upon or otherwise
identified:

   1. Lindsey makes the following comment: "Page boundaries are primarily
   of interest in connection with line printers which have facilities for
   rapid paper movement to the head of the next form".
      1. Thinking of this in present day terms where - I imagine - few if
      any of us have access to a line printer, I can still see the need for
      writing output where page boundaries are indicated so that
subsequent page
      layout utilities can convert my output to Postscript, HTML, sheets in a
      spreadsheet, pages in a word processor document etc etc.
      2. What I fail to see is how the page structure can be easily
      communicated to these page layout utilities so that they can make use of
      them, except by including specific marks in my output that will be
      interpreted as page breaks (CONTROL-L for example); especially given that
      at least some of these utilities are extant, well-established and take no
      note of mode Book.
      3. I believe that this difficulty in communicating page boundaries
      applies equally to line boundaries - the only general purpose
mechanism to
      indicate the end of a line is a specific mark indicating that the end of
      the line has  been reached.
      4. Where system files have been created by other non Algol 68
      utilities, it seems we can only develop a Pos instance for a particular
      character on a particular line in a particular page once we have read to
      that character position, recording the number of page breaks, line breaks
      on the current page and characters on the current line read to
this point.
      By induction, the only way we can develop a Pos instance for the end of a
      Book instance is by reading or writing to the end.
      5. Where we are creating a Book instance by writing it, of course we
      can track the number of page breaks, line breaks on the current page and
      characters on the current line written to this point.  We can report the
      end of a Book instance as a Pos instance.
   2. Given the points discussed above, I find it hard to imagine how one
   could implement the standard prelude proc set (which takes a ref file and
   page number, line number on the page and character number on the line in
   order to update the current file location) without reading sequentially to
   the desired location.
   3. Moreover, if we allow the use of proc set to navigate to the offset
   of a character from the beginning of the system file, perhaps with a call
   like set(f, 1, 1, char offset), or maybe set(f, int(skip), int(skip), char
   offset), we will probably not be satisfied with the position elements -
   especially char offset - being declared as int and therefore restricting us
   to 2Gb files.
   4. While Lindsey more or less throws up his hands at binary transput, it
   seems to me to correspond better to mode Book than free-form streams of
   characters.  For example, I could imagine that, in the case where one is
   writing or reading a file of structures of the same mode, that each line
   corresponds to an instance of the structure.  In this case, a Pos instance
   of (1, instance offset, 1) would point to the beginning of an instance of
   the straightened instance of the structure.  Still, here, page doesn't seem
   to have a great deal of utility.
   5. The other thing that one runs across in many Posix and similar
   utilities is the concept of a field, which is a delimited group of
   characters on a line.  awk for instance automatically splits each input
   line on the value of the variable SUBSEP (this may in fact be a regular
   expression).  Sort and cut function similarly.  Spreadsheets can read and
   write "comma-separated value" format files, where commas (or some other
   delimiter) separates fields on a line.  mode Book completely misses out on
   this very useful concept.
   6. In a previous email, Jose mentioned that files as simple streams of
   characters often have some kind of structuring in them, identified by
   marks, and can often be thought of as pages; for example, HTML.  I agree
   with this perspective, but I'm not sure that mode Book as envisioned in the
   revised report can be adapted to accommodate such structured text.

Marcel van der Veer has given this all some deep thinking and Algol 68
Genie veers away from mode Book in its entirety; and, in my experience,
successfully.

I wonder if we can take a similar approach; or, if not getting rid of mode
Book entirely, at least reimagining it as something more like a stream of
bytes at the bottom that could be interpreted as a steam of characters or
raw bytes or lines according to the abilities of the channel used to
process it.

A channel in this context could look more like the various  types of Java
Readers and Writers (I know I'm always bringing up Java - but a lot of good
design thought has gone into its components and they may offer ideas as to
how, or how not, to accomplish things).

Since I'm throwing out provocative (I hope!!!) ideas at this point, I found
myself wondering if the idf property of a Book could possibly be a URL or
URI.  Thinking that way might encourage us to deal with network streams
with the same structure.

That's all for now.  I'm working on McGettrick's lucid text about the
functioning and utility of the various components of transput.

Link here
https://archive.computerhistory.org/resources/text/algol/algol_bulletin/A42/P44.HTM
-- 
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/20251228/36bd7644/attachment-0001.htm>