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

Tue May 12 19:31:51 GMT 2026

Good afternoon,

On Tue, May 12, 2026 at 9:15 AM Jose E. Marchesi <jemarch@gnu.org> wrote:

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

Here is mode File:

{MODE^FILE = {STRUCT(
  {REF^COVER #?# cover,
  {REF^REF^FORMATLIST #?# piece,
  {CHARBAG #?# term,
  {PROC ({REF^FILE, {CHAR) {VOID #?# write char,
  {PROC ({REF^FILE, {BINCHAR) {VOID #?# write bin char,
  {PROC ({REF^FILE, {REF^CHAR) {BOOL #?# read char,
  {PROC ({REF^FILE, {REF^BINCHAR) {VOID #?# read bin char,
  {PROC ({REF^FILE) {BOOL #?# logical file mended, #?# physical file mended,
       #?# page mended, #?# line mended, #?# format mended,
       #?# value error mended,
  {PROC ({REF^FILE, {REF^CHAR) {BOOL #?# char error mended);

Here is mode Format, Collection, Coll_Item and Format_List:

{MODE^FORMAT = {STRUCT({REF [] {COLLECTION #?# c);

{MODE #?# {COLLECTION = {UNION({PICTURE, {COLLITEM);

{MODE #?# {COLLITEM =
  {STRUCT({INSERTION i1,
         {PROC^INT rep, # replicator #
         {REF [] {COLLECTION p,
         {INSERTION i2);

{MODE #?# {FORMATLIST =
  {STRUCT({INT count,  # number of times current piece is to be
                       repeated #
             cp,     # pointer to current collection #
         {REF [] {COLLECTION p,  # current collection list #
         {REF^FORMATLIST next   # pointer to next piece #
        );

Here is proc associate_format:

{PROC #?# associate format = ({REF^FILE f, {FORMAT format) {VOID:
  piece {OF f:= {REF^REF^FORMATLIST(pseudo62) # a newly created name
                 which is made to refer to the yield of an actual-
                 reference-to-formatlist-declarer and whose scope is
                 equal to the scope of 'f' #
            := {REF^FORMATLIST(pseudo63) # a newly created name
                 which is made to refer to the yield of an actual-
                 formatlist-declarer and whose scope is equal to the
                 scope of 'f' #
            := (1, 1, c {OF format, {NIL);

So that display at the bottom of associate_format - you can see that it
doesn't
quite agree with the declaration of Format_List and is in any case a local
but
should be on the heap.  Plus there is the pseudo62 and pseudo63 business.
Nor am I sure where the value for field "count" is determined except maybe
somehow from the field "rep" in Coll_Item instances.

I need to read up on format-text...

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

-- 
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/20260512/51d7ffaf/attachment.htm>