Standard prelude version Hans van Vliet

[chris hermansen]

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.
>


-- 
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/20251227/8ab43666/attachment.htm>