New Year's eve and weird transput ideas - request for comment or at least laughter

[chris hermansen]

Thanks as always Jose for the thoughtful responses.

On Wed, Dec 31, 2025 at 7:56 PM Jose E. Marchesi <jemarch@gnu.org> wrote:

>
> Hi Chris.
> Happy GNU year! :)
>
> > I'm writing a document about Algol 68 transput, mostly for myself but
> > of course I'm happy to share because I fear more not getting feedback
> > than being insulted for my poorly thought-out ideas.
>
> I am also writing my own proposal for a modernized transput model, and I
> am also doing it mostly for myself, at least at this stage, to clarify
> ideas and see where we stand.
>
> I am basing on three transput models:
>
> - The RR transput.
>
> - The van Vliet transput.
>
> - Sian Mountbatten's QAD transput, which was implemented and used in the
>   ctrans compiler port for POSIX systems, and which was itself derived
>   from van Vliet and the OCCL Algol 68 compiler.
>

I had a look at her  Programming Algol 68 Made Easy (online in PDF format)
recently to see what she had to say about transput.  There are some
interesting comments and I particularly enjoyed seeing her mode declaration
for Simplin, the union ending with STRAIGHT Simplin.

Also her comments about QAD and proc establish:

The p, l and c in establish determine the maximum number of pages, lines
and characters in the book which is being created.  Values of 0 for all
three integers mean that the file should be established with zero length.
However they are ignored by the stand out channel in the QAD standard
prelude provided with the a68toc compiler.

and

In the QAD standard prelude, only the mem channel (see section 5) takes
notice of p, l and c and both p and l must be 1.  For other channels p, l
and c are ignored  other than the socket channels (see section 6).

As well, her comment about QAD and proc current pos:

The standard Algol 68 procedure yields a triple giving the page, line and
character number. However, the QAD standard prelude does not use pages,
lines and characters, so this procedure yields the current character
position within the book for the next transput operation.

That raises the question about what to do about files > 2Gb (assuming 32
bit integers).

Aside from the above standard prelude / transput stuff I find this book to
be quite well-written and to provide interesting and thoughtful code
examples.


> Once I get something in clear I will share the document in this mailing
> list, and we should definitely get both proposals/documents/notes and
> distill from them the transput system we want for GNU Algol 68 (much
> like the sub-committee on support used to work, using the Algol Bulletin
> as distribution and discussion media.  We have this list).


Happy to toss mine over the fence when done.

>


> As you have seen in the patches traffic, the placeholder and
> infrastructure is already there in the compiler (transput.a68 in
> libga68) waiting for the implementation, once we know what we want to
> implement.
>
> > Anyway, I've come to the point in the document where I'm comparing
> > the Java "transput" model to the Algol 68 transput model. I feel
> > this is a fair comparison since Java harks back to C and C harks back
> > to Algol 68.
>
> That's an interesting approach.
>
> > I believe there is a fair correspondence between Algol 68 Book and
> > java.io.File (though the concept of directories, network connections
> > etc etc were perhaps glossed over in Algol 68 or perhaps
> > unanticipated / unknown. At bottom, Book is all about expressing
> > backfile metadata in Algol 68; java.io.File is all about expressing
> > operating system file data in Java. So there's that.
>
> Seems like similar concepts.
>
> As for concepts of directories etc, I think that kind of "identification
> data" was actually more elaborated back then, with file version
> information, more complex permissions/capabilities systems, etc.  They
> just assumed anything may be encoded in the book's idf.  See Lindsey's
> notes and examples with JCL in the friendly neighboor OS article.
>

What I find interesting about the idf field and the general indications
that it could be used to handle all kinds of things - as you say, Lindsey's
Friendly Neighbourhood OS article offering specific examples -  is that it
seemed to be accepted as a way to shoehorn anything file-related and overly
system-specific into the Book, which largely delegates to Channel and File
and procs like open and establish used to bind the threesome together.

Also, delegating these kinds of complexities to JCL kind of implies a read
data / write data model, but there are other things one might want to do
with a file, especially if it's a directory.

It's hard for me to see how a programmer could walk a directory tree
structure with Book, Channel and File.  I don't believe a programmer can
rename or delete a file unless they can first open it.  I'm not sure what
establish should do if the idf is the name of a directory rather than a
file - what does a directory's Book look like?  I don't think we want to
have people writing arbitrary text to a directory.  And probably other
stuff that I haven't thought of.

Whereas the Java approach is to expose a range of useful things one can do
with respect to system files (is the file readable, writeable, executable;
move around the file system; renaming and deleting) directly in the
java.io.File class, without needing to first open it.

>
> > I also believe there is a fair correspondence between Algol 68
> > Channel and java.io.FileDescriptor (and I think we can thank - or
> > blame - Stephen Bourne for this).
> >
> > But when I come to Algol 68 File... wow, here there is a profusion of
> > Java conceptual frameworks... but wait does a picture emerge from
> > this profusion? I think so.
>
> I find it suprising the Channel corresponds to something called
> FileDescriptor.  If anything, I would have expected the FileDescriptor
> to correspond to the Algol 68 File.
>
> I see this in the Java documentation:
>
>   Instances of the file descriptor class serve as an opaque handle to
>   the underlying machine-specific structure representing an open file,
>   an open socket, or another source or sink of bytes. The main practical
>   use for a file descriptor is to create a FileInputStream or
>   FileOutputStream to contain it.  Applications should not create their
>   own file descriptors.
>
> That sounds more like a File to me.  Not unlike C's FILE *.
>

You could be correct!  I think the obvious first guess for "what is a
Channel in Unix / Linux" is that it's /dev/somethingorother.  But any Unix
/ Linux (and other systems that I can think of) generally restrict the use
of devices that have mounted filesystems on them.  So the Channel is a
device theory only really works for sockets, tape drives and the like (as
far as I can see anyway).

I feel like the correspondence is more like:

Book <-> java.io.File
Channel <-> java.io.FileDescriptor
File <-> java.io.BufferedReader wrapping java.io.FileReader or
java.io.BufferedWriter wrapping java.io.FileWriter (obviously there are
other combos for things like sockets, pipes, binary vs character)

>
> > Algol 68 File covers both input and output and both binary and
> > character. Java splits this all up; for example java.io.FileReader
> > and java.io.FileWriter take on the file-related issues that Book
> > doesn't delegate to File (ie. actual reading and writing of
> > characters). java.io.BufferedReader and java.io.BufferedWriter deal
> > with line-oriented streams of characters. And so on.
> >
> > So... I feel I am at a bit of a point where I could go one way or
> > another. In one direction, I could futz around to fit "modern"
> > character and binary I/O into the Algol 68 model; in the other, I
> > could futz around to fit Algol 68 format stuff onto "modern"
> > character I/O and look at binary I/O separately.
> >
> > I'm not asking for feedback - or maybe I am? But I have real doubts
> > about the overall utility of Book, as a hidden meta-model of backing
> > files on systems that interest few or none at this point in time
> > (c.f. Marcel's comments in the Genie documentation), vs the residual
> > utility - which seems to me actually kind of significant - of Algol
> > 68 format on top of a more current "streams of characters" approach
> > to life.
>
> I am still trying to come to terms with all this myself, but the more I
> think about it and review the literature, the more I feel that the whole
> point of the file/channel/book configuration has been somehow
> misunderstood, and even perhaps poorly judged, sometimes based precisely
> on what I suspect is the least relevant and most anecdotic part of it,
> which is the three-dimensional model of pages, lines, chars of the
> backfile contents implied by Book.
>

I could well be guilty of this and I would love to be corrected!


>
> Personally, I am basically putting aside (for now) the page,line,char
> cube modelled by the Book as a model of the data stored in the backfile,
> and focusing instead on the interaction between books (as an explicit
> representation of the backfile, but only accessible via files attache to
> them), files (as file descriptors, which can be attached to different
> books at different times) and channels (as the representation of
> different modes of accessing backfiles in different devices).
>

I have two thoughts about this.

The first is "if we're willing to reject page / line / char, where do we
stop?"

The second is, I can live with just the character count, but it has to be
long int at least and beyond that I'm truly befuddled as to how we program
a traversal of a directory structure with anything like the book model.

>
> I'm still rather confused though :)
>
> > Now it's time to go and bake some potatoes!
>
> Enjoy the new year festivities! :)
>

Best of 2026 to all!

>
> >
> > --
> > Chris Hermansen · clhermansen "at" gmail "dot" com
> >
> > C'est ma façon de parler.
> >
> >
> >
> > I'm writing a document about Algol 68 transput, mostly for myself but
> > of course I'm happy to share because I fear more not getting feedback
> > than being insulted for my poorly thought-out ideas.
> >
> > Anyway, I've come to the point in the document where I'm comparing
> > the Java "transput" model to the Algol 68 transput model.  I feel
> > this is a fair comparison since Java harks back to C and C harks back
> > to Algol 68.
> >
> > I believe there is a fair correspondence between Algol 68 Book and
> > java.io.File (though the concept of directories, network connections
> > etc etc were perhaps glossed over in Algol 68 or perhaps
> > unanticipated / unknown.  At bottom, Book is all about expressing
> > backfile metadata in Algol 68; java.io.File is all about expressing
> > operating system file data in Java.  So there's that.
> >
> > I also believe there is a fair correspondence between Algol 68
> > Channel and java.io.FileDescriptor (and I think we can thank - or
> > blame - Stephen Bourne for this).
> >
> > But when I come to Algol 68 File... wow, here there is a profusion of
> > Java conceptual frameworks... but wait does a picture emerge from
> > this profusion?  I think so.
> >
> > Algol 68 File covers both input and output and both binary and
> > character.  Java splits this all up; for example java.io.FileReader
> > and java.io.FileWriter take on the file-related issues that Book
> > doesn't delegate to File (ie. actual reading and writing of
> > characters).  java.io.BufferedReader and java.io.BufferedWriter deal
> > with line-oriented streams of characters.  And so on.
> >
> > So... I feel I am at a bit of a point where I could go one way or
> > another.  In one direction, I could futz around to fit "modern"
> > character and binary I/O into the Algol 68 model; in the other, I
> > could futz around to fit Algol 68 format stuff onto "modern"
> > character I/O and look at binary I/O separately.
> >
> > I'm not asking for feedback - or maybe I am?  But I have real doubts
> > about the overall utility of Book, as a hidden meta-model of backing
> > files on systems that interest few or none at this point in time
> > (c.f. Marcel's comments in the Genie documentation), vs the residual
> > utility - which seems to me actually kind of significant - of Algol
> > 68 format on top of a more current "streams of characters" approach
> > to life.
> >
> > Now it's time to go and bake some potatoes!
> >
> > --
> > Chris Hermansen · clhermansen "at" gmail "dot" com
> >
> > C'est ma façon de parler.
> >
> >
> >
> > Good evening and happy new year.
> >
> > I'm writing a document about Algol 68 transput, mostly for myself but of
> > course I'm happy to share because I fear more not getting feedback than
> > being insulted for my poorly thought-out ideas.
> >
> > Anyway, I've come to the point in the document where I'm comparing the
> Java
> > "transput" model to the Algol 68 transput model.  I feel this is a fair
> > comparison since Java harks back to C and C harks back to Algol 68.
> >
> > I believe there is a fair correspondence between Algol 68 Book and
> > java.io.File (though the concept of directories, network connections etc
> > etc were perhaps glossed over in Algol 68 or perhaps unanticipated /
> > unknown.  At bottom, Book is all about expressing backfile metadata in
> > Algol 68; java.io.File is all about expressing operating system file data
> > in Java.  So there's that.
> >
> > I also believe there is a fair correspondence between Algol 68 Channel
> and
> > java.io.FileDescriptor (and I think we can thank - or blame - Stephen
> > Bourne for this).
> >
> > But when I come to Algol 68 File... wow, here there is a profusion of
> Java
> > conceptual frameworks... but wait does a picture emerge from this
> > profusion?  I think so.
> >
> > Algol 68 File covers both input and output and both binary and character.
> > Java splits this all up; for example java.io.FileReader and
> > java.io.FileWriter take on the file-related issues that Book doesn't
> > delegate to File (ie. actual reading and writing of characters).
> > java.io.BufferedReader and java.io.BufferedWriter deal with line-oriented
> > streams of characters.  And so on.
> >
> > So... I feel I am at a bit of a point where I could go one way or
> another.
> > In one direction, I could futz around to fit "modern" character and
> binary
> > I/O into the Algol 68 model; in the other, I could futz around to fit
> Algol
> > 68 format stuff onto "modern" character I/O and look at binary I/O
> > separately.
> >
> > I'm not asking for feedback - or maybe I am?  But I have real doubts
> about
> > the overall utility of Book, as a hidden meta-model of backing files on
> > systems that interest few or none at this point in time (c.f. Marcel's
> > comments in the Genie documentation), vs the residual utility - which
> seems
> > to me actually kind of significant - of Algol 68 format on top of a more
> > current "streams of characters" approach to life.
> >
> > Now it's time to go and bake some potatoes!
>


-- 
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/20260101/f3d86224/attachment-0001.htm>