Standard prelude version Hans van Vliet

[Jose E. Marchesi]

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.

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.