Standard prelude version Hans van Vliet

[Jose E. Marchesi]

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

> Thanks for the info below, Jose.  This also reminded me to review the
> transput chapter in McGettrick's /Algol 68: a first and second course/ for
> some more informal counsel on this topic.
>
> I've thought about this on and off over the last week and I think the best
> way to move it down the road a bit further is to split it up.  So I'm going
> to copy / paste parts of it into separate emails.
>
> On Sat, Dec 20, 2025 at 4:29 AM Jose E. Marchesi <jemarch@gnu.org> wrote:
>
>>
>> Hi Chris.
>>
>> > Belatedly, thanks for sending this link
>> >
>> > https://www.dickgrune.com/CS/Algol68/TransputHansVanVliet
>> >
>> > I feel like I could start plugging away at it.  Almost...
>> >
>> > The various "PseudoNN" modes need some thought; or at least, the first
>> > dozen or so that I've examined.  As I understand it, van Vliet's idea
>> here
>> > is to leave flexibility to the implementor in the definition of e.g. mode
>> > BOOK that suits her/his operating system target.
>> >
>> > Is that the general idea?
>>
>> Yes I think so.  The PseudoNN specify operations that would be too
>> compiler or system specific for his compiler and system independent
>> specification.  In our case, I expect these to be implemented in terms
>> of our POSIX prelude I/O, which acts as our OS interface.
>
>
>> > I find the concept of "mode BOOK" to be a bit fuzzy within the framework
>> > established by Unix / Linux / (even) Windows.  As I understand it, a BOOK
>> > refers to the semantic structure of data contained within a FILE.  This
>> > kind of reminds me of IBM mainframe days (daze?) when we used to put data
>> > structures (or at least 80 column records, blocked) into files and read
>> > them back out, thus FILE corresponding to a stream of bytes and BOOK
>> > corresponding to the data (or record, at least) structure itself.
>> >
>> > Am I fully lost here?
>>
>> Following van Vliet's history of algol 68 transput, in the original
>> report you had:
>>
>>   - "channels" which would correspond to the physical devices providing
>>     the data.  All files opened via a channel share some common
>>     properties, like, "can the file be written to".  These are
>>     properties of the channel.  The number/nature of channels is fixed
>>     and each device is identified by a number.
>>
>>   - "backfiles" which would correspond to the actual file in a
>>     filesystem, and is managed by the Operating System.  As part of the
>>     backfile, there is these three integers called the "book", termed
>>     page, line and char respectively.  The maximum number of pages,
>>     lines and chars are fixed (determined by the channel/device) and
>>     every page has the same fixed number lines, and every line has the
>>     same fixed number of chars. (TEXT = ref[][][]char)
>>
>>   - "files" which would correspond to modern "file descriptors".  They
>>     hold a current position, and also conversion information (character
>>     conversion).
>>
>> In the revised transput:
>>
>>   - The term "book" replaces "backfile" to refer to the actual file
>>     stored in a filesystem and managed by the OS.
>>
>>   - The term "text" replaces "book" to refer to the page/line/char
>>     structure of the contents of each book.
>>
>>   - Book pages can contain a variable number of lines, and lines can
>>     contain a variable number of chars. (FLEXTEXT = ref
>>     flex[]flex[]flex[]char).  When a book is declared a
>>     "non-compressible", the previous behaviour is achieved using
>>     whitspaces to fill extra space.
>>
>> As for modernization of the transput, these are some of my thoughts:
>>
>> For character transput, structuring the files being edited in
>> pages/lines/char is something that currently every application wishing
>> to edit text structured data have to do by themseves, on top of the
>> simplistic stream-of-bytes I/O systems: you should handle newline, you
>> should keep count of the number of lines you are reading or writing,
>> which column I am right now, etc.
>>
>> IMO it is cool for the transput system to implement the complexity of
>> dealing with structured text.  Like so many other things, I/O systems
>> got simplified way too much.
>>
>> One may argue about pages.  With some few exceptions (like the GNU
>> custom of using ^L characters to group related information) almost
>> nobody bothers to structure their text files into pages.  So we may want
>> to simplify the book to be a collection of lines/chars, rather than
>> pages/lines/chars.
>>
>> However, nowadays paging made a comeback by being used extensively in
>> contents provided by web servers, where the result of a query is very
>> often paged, to be fetched page by page.  So we may want to keep the
>> page/line/char after all.
>>
>>
>> Given the above, I could see us implementing Book as per the RR
>> definition, or as per something we define that looks more like what *ix
>> Windows OSX etc users think of streams of characters with newlines.
>>
>> Is it your thought that anyone writing an Algol 68 program that reads
>> lines of characters from or writes lines of characters to a file would do
>> so via mode Book and its related machinery?
>>
>> As for transput conversion routines, once again the "old" becomes and
>> improves on the "modern".  Back then they had a plethora of incompatible
>> character encoding systems to deal with, so they envisaged a transput
>> file (today's file descriptor) being a collection of characters, somehow
>> corresponding to a collection of small integers in a transput book
>> (today file stored in a file system).  The correspondence between
>> characters and integers is the conversion routine.  Today we have only a
>> few character code spaces, one of them with a plethora of encodings
>> (Unicode), so the situation is still the same and the conversion
>> routines is even more pertinent now.
>>
>> Of course, GNU Algol 68 will always provide plain simplistic, stream of
>> bytes and stream of chars, POSIX like I/O, on top (or on the bottom) of
>> the character and binary transput.
>>
>> > Also I get completely nervous every time I see the whole ℵ0 thing which
>> > deeply infects transput.  I feel like the spirit of Georg Cantor is
>> looking
>> > over my shoulder.  For example, from RR § 25.3.1.1
>> >
>> > MODE ℵ0 BOOK =
>> >     STRUCT (FLEXTEXT text,
>> >         POS lpos ¢ logical end of book ¢,
>> >         STRING idf ¢ identification ¢,
>> >         BOOL putting ¢ TRUE if the book may be written to ¢,
>> >         INT users ¢ the number of times the book is opened ¢);
>> >
>> > So the RR 25.1.3 states, in Step 2:
>> >
>> > If, in some form, as possibly made in the step above, ℵ0 occurs followed
>> by
>> > an INDICATOR (a field-selector) I, then that occurrence of ℵ0 is deleted
>> > and each INDICATOR (field-selector) akin {151 .1.3.2.k} to I contained in
>> > any form is replaced by a copy of one same INDICATOR (field-selector)
>> which
>> > does not occur elsewhere in the program and Step 2 is taken again.
>> >
>> > Maybe the authors of the revised report felt Georg giving them the stink
>> > eye as well, since they replaced the ℵ0 with the dash-question-mark
>> symbol;
>> > but as far as I can tell, ultimately it's not the symbol that's giving me
>> > the heebiejeebies here, it's what do do about it.
>> >
>> > That is, I don't understand - at all - the significance of ℵ0 in the
>> > definition of the BOOK mode above.
>> >
>> > For instance, "ℵ0 occurs followed by an INDICATOR (a field-selector)" -
>> how
>> > closely is "followed"?  "FLEXTEXT text" follows ℵ0 (eventually); does
>> that
>> > count?  Or does the intervening "STRUCT" "OPEN-SYMBOL" preclude the
>> > deletion of ℵ0 in this case?
>> >
>> > Put another way, does
>> >
>> > MODE BOOK =
>> >     STRUCT (FLEXTEXT text,
>> >         POS lpos ¢ logical end of book ¢,
>> >         STRING idf ¢ identification ¢,
>> >         BOOL putting ¢ TRUE if the book may be written to ¢,
>> >         INT users ¢ the number of times the book is opened ¢);
>> >
>> > ie without the ℵ0, have the same semantic import?
>> >
>> > Moving on to a concrete question, Jose, do you see sppp dealing with
>> these
>> > ℵ0 things?  Or will we need some other pre-processor to accomplish what
>> is
>> > needed?  Or can we move to the super-language instead?
>>
>> ℵ0 is just intended to describe "secret" or inaccessible entities.  Any
>> mode indicant (INDICATOR) or field selector (field-selector) marked by
>> it is substituted by some mode indicant or field selector that only
>> occur once (in their definition) in the program.  i.e. they are
>> conceptually replaced by some unique string that is not referred
>> elsewhere in the program.
>>
>> In our case, in practice, this means that entities marked with ℵ0 should
>> not be pub-licized in the module implementing the transput, so:
>>
>>   module Transput =
>>   def
>>      [...]
>>
>>      proc book_bounds = (ref File f) Pos: skip; { marked with ℵ0 }
>>      pub proc char_number = (ref File f) int: skip; { not marked with ℵ0 }
>>   fed
>>
>> Same for modes, priorities and operators.
>>
>> As for secret field names in structs... thats something not supported by
>> Algol 68 even with the modules system: there are no secret fields and
>> the user can always refer to them should she find out the names somehow.
>> We can probably come with some extension for this if we wanted to, to
>> improve security, but when it comes to implement the transput I think it
>> is ok to just document these fields as non-public.
>>
>> > I hope the readers of this list 1) understand my questions and 2) can
>> > enlighten me as I would love to contribute to this project.
>> >
>> > Thanks in advance for patience and enlightenment.
>>