RFC van Vliet saves format info in the File struct, but I think that's bad

[Jose E. Marchesi]

> Good morning everyone, thanks for the reply Jose
>
> On Tue, May 12, 2026 at 4:16 AM Jose E. Marchesi <jemarch@gnu.org> wrote:
>
>>
>> > Hello everyone,
>> >
>> > In van Vliet's transput code, the public procedures
>> >
>> > getf(ref File f, [] union(In_Type, Format x) and
>> > putf(ref File f, [] union(Out_Type, Format x)
>> >
>> > are defined.  In both cases, any arguments of mode Format that are
>> provided
>> > are encoded into a linked list of mode ref ref Format_List called "piece"
>> > that is a field of the File mode structure.
>>
>> When yu say "are encoded" what do you mean?  Wouldn't that require some
>> sort of introspection on the format value?  Or the Format_List just
>> keeps a copy of the provided format?
>>
>
>  Sorry, I suppose "encoded" wasn't the best term...
>
> The procedure I mention below, associate_format(ref File f, Format
> format), is one of those where the body of the procedure is expressed
> as comments and "pseudo"s, but its intent is to restructure the
> elements of the Format into the linked list Format_List.
>
> No introspection necessary.
>
> I find it weird that van Vliet left associate_format(ref File f,
> Format format) uncoded, as both the source Format mode and the target
> Format_List mode are fully declared.  Maybe he wrote the commented
> version and then forgot about it?

What is the comment for associate_format?

>
>
>> > I have been feeling for awhile that this is a bad design decision:
>> >
>> > - It is contrary to two "good coding" principles defined in the General
>> > Responsibility Assignment Software Patterns (GRASP), namely "low
>> coupling"
>> > (don't tie types together that aren't intimately related) and "high
>> > cohesion" (incorporate data and behaviour elements in types that are
>> > strongly related).  Some of you will be saying "but Algol 68 isn't
>> > object-oriented"; I contend that these principles apply equally well to
>> > modes and especially modules in Algol 68, or for that matter, any
>> > programming language.
>>
>> Yeah 100% agreement of that.  I can't think on any computation model in
>> which high coupling and low cohesion would be a win.
>>
>
> Me neither!
>
>>
>> > - It won't facilitate using Algol 68 Format by other types of transput
>> > because in those cases we probably won't want to use the File mode (nor
>> its
>> > relatives Channel and Book) at all.  For example, POSIX transput
>> procedures
>> > (both file-based and socket-based) refer to file descriptors.
>>
>> I am confused.  Does the format itself has a reference to the File in
>> which it gets installed?
>>
>
> No, neither Format nor Format_List refer to the File, but the File refers
> to the
> Format_List and thence to the components of each Format element.


I would have expected for associate_format to just make a copy of Format
and put it in the File.  If what vanVliet is suggesting is to actually
store a reference of some internal data structure of the format struct
into File, then I agree it perhaps might not the best idea.

>>
>> > I feel it's achievable to remove the "piece" field from mode File and to
>> > have it stand on its own.
>> >
>> > Both getf() and putf() call four procedures to manage the "piece" linked
>> > list.  All four are private to the transput module and therefore their
>> > parameter pack can be modified without external damage.
>> >
>> > These private procedures are:
>> > - associate_format(ref File f, Format format)
>> > - get_next_picture(ref File f, ref Picture picture)
>> > - do_fpict(ref File f, F_Pict fpict)
>> > - update_cp(ref File f, bool perform_insertions, Status reading)
>> >
>> > I propose to rewrite these procedures so that:
>> > - add a parameter that points to the head of the Format_List piece
>> > - remove the File f parameter where possible
>> >
>> > If any of these procedures both change the Format_List piece and the File
>> > f, I propose to split them into two parts, one for each task.
>> >
>> > I also propose to revise the code for getf() and putf() to make sure they
>> > aren't directly manipulating the Format_List piece, as a first step to
>> > making Format separable from the Book / Channel / File trio, thinking
>> that
>> > we could (somewhere in the future) make Algol 68 procedures like the C
>> > "printf" and "scanf" procedures that use an Algol 68 Format instead of
>> the
>> > string with % keywords.
>> >
>> > I would appreciate any and all comments, ideas, etc, whether
>> complimentary
>> > or not!
>>