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

Tue May 12 20:23:21 GMT 2026

Reading Lindsey and van der Meulen Informal Introduction to Algol 68
(IIA68), §7.6.3 "The formatted transput procedures" states the following:

--
Associated with each File is a Format value and a Format pointer (which
keeps track of which picture is to be used next)... If a new Format is
provided before the old one has been exhausted, the old one is lost (note,
however, that if the new Format is provided to a copy of a File obtained by
assignation, the original File still retains the old Format)... If part of
a Format still remains unused when the end of the data list is reached, it
remains associated with the File and will be used for the next data list to
be transput via that File.
--

He then constructs an example to drive home this point:

(E14) p. 282
--
printf($ p 6( 8( 6(+d.6de+d 2x) 1) 2l) $);
proc real_compute = { computes some result };
to some_large_number
do printf(compute) od

This will print the results of the computation, 6 numbers to a line, 48
lines to the page, with 2 extra blank lines inserted after every 8 lines.
After printing the results of 288 computations the Format will be
exhausted.  Then the format_end event will be invoked.  In this case the
user has provided no event routine, and so the default action is taken, vs
the same Format is started again (and printing is continued on a fresh
page).
--

So, it seems that my idea of separating the elaboration of the format-text
from the File itself is not allowed by design...

On Tue, May 12, 2026 at 12:31 PM chris hermansen <clhermansen@gmail.com>
wrote:

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

-- 
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/3fe5f60a/attachment-0001.htm>