RFC the concept of "line overflow" - can it be ignored?

[Jose E. Marchesi]

Hello Chris.

> Good day everyone,
>
> A week of an early music festival and a dog who has been to the vet
> many times lately for ear issues has slowed down my already slow pace
> at transput.  However, some light at the end of the tunnel this
> morning, so I am looking through the Revised Report and van Vliet
> volume II to learn more about the whole (page, line, character)
> business.

As you can see I am also late replying.
I'm back from a few days off.
Too few ^^

> The thing I have run into today is the concept of "line overflow".
> Once again, a concept that made sense back in the day when we often
> used fixed length records in fixed length blocks and other mainframe
> concepts in our transput.  I'm not sure it makes sense any more.
>
> The RR p.152-3 says:
>
> If c is the current character number and lb is the length of the
> current line, then at all times 1 ≤ c ≤ lb + 1. c = 1 implies that the
> next transput operation will be to the first character of the line and
> c = lb + 1 implies that the line has overflowed and that the next
> transput operation will call an event routine. If lb = 0, then the
> line is empty and is therefore always in the overflowed state.
> Corresponding restrictions apply to the current line and page numbers.
> Note that, if the page has overflowed, the current line is empty and,
> if the book has overflowed, the current page and line are both empty
> (e).
>
> van Vliet p.100 has more to say:
>
> For most transput operations, the line must be ensured. This is
> generally done by calling either 'next pos' (k) or 'check pos' (1).
> Except for the recursive call of 'check pos', the precondition of both
> these routines is: NOT line ok, i.e., the line has overflowed. Most
> often, this will correspond to a normal line overflow, where the page
> and/or file have not overflowed. If the user has not provided an event
> routine corresponding to the 'on line end' event, the default action
> will then be to call
> 'newline' in case of a call of 'next pos', while 'check pos' would return false.
>
> Well!  I am thinking that we could either:
>
> - work with fixed-length lines (and pages, for that matter), or
> - forget about fixed-length lines (and pages).
>
> No doubt we could enforce fixed-length lines and pages, but beyond
> trying to make GNU Algol 68 transput work exactly like it did on some
> mainframes in the past, I don't see any advantages, at least as far as
> writing to the filesystem goes anyway.
>
> So picking the second option would - I believe - mean that lines and
> pages never overflow, which would eliminate the need for checking
> character position against any limits and, as van Vliet says, "fixing
> page [or line] overflows".  This kind of activity - removing
> unnecessary code - is always desirable in my opinion at least, but I
> suppose I'm not 100% comfortable in my determination of "necessity"
> here.
>
> Does anyone have any thoughts about this?

How can this play with the distinction between logical lines and
physical lines?  (ditto for pages).

Clearly I have to review my own notes on transput.. :/