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

[chris hermansen]

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.

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.

- 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 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!
-- 
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/20260511/49205f9c/attachment.htm>