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

[chris hermansen]

Jose and list,

Another comparison exercise came to mind tonight.  I debated starting a
fresh thread but decided for now to leave it here, at the end below.

On Thu, Jan 1, 2026 at 5:00 PM chris hermansen <clhermansen@gmail.com>
wrote:

> 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!
>
>>
>>
>>
There are also the java.nio packages. I don't use java.nio much (being a
dinosaur and all), but I like this comment in the Java 8 documentation for
java.nio:

---- from
https://docs.oracle.com/javase/8/docs/api/java/nio/package-summary.html
Defines buffers, which are containers for data, and provides an overview of
the other NIO packages.

The central abstractions of the NIO APIs are:

Buffers, which are containers for data;

Charsets and their associated decoders and encoders,
which translate between bytes and Unicode characters;

Channels of various types, which represent connections
to entities capable of performing I/O operations; and

Selectors and selection keys, which together with
selectable channels define a multiplexed, non-blocking
I/O facility.
---- end of quote

This is an interesting structure.  The "channel" abstraction in particular
caught my eye.  There is a sample "grep" utility program using nio where
the approach is:

1. get a new instance of File from a String;
2. create a new instance of FileInputStream from the File instance;
3. get the FileChannel instance associated with the FileInputStream
instance;
4. use the FileChannel instance map() method to map the file contents into
a MappedByteBuffer instance in memory;
5. decode the MappedByteBuffer instance into a CharBuffer instance
6. search the CharBuffer instance for the pattern

This "feels" kind of like the Algol 68 transput channel concept.  There are
21 different java.nio.Channel classes (or interfaces) defined which take
care of scatter / gather, seeking, asynchronous operations, network,
multicast, file, datagram, pipe, socket etc etc channels.

There are several other sample programs using java.nio - checksumming, time
server query (non-blocking as well), IP sockets, Unix sockets, chmod, file
copying, disk usage...

Just coming back to why I think this kind of comparison might be useful -
it's a way of thinking of the kinds of problems we might want to solve with
Algol 68 transput, both from the point of view of breaking out of the file,
tape, console framing in the RR and from the point of view of thinking of
what kind of unanticipated limitations we might inadvertently build in.

-- 
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/461cedb5/attachment-0001.htm>