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

[Jose E. Marchesi]

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.

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

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.

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

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

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'm still rather confused though :)

> Now it's time to go and bake some potatoes!

Enjoy the new year festivities! :)

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