RFC on routines and mode Pos

[chris hermansen]

Good afternoon everyone,

Back prodding transput here and I have some doubts with which I hope
you all can help.

Quoting from the Revised Report pp. 141-144:

> mode {ℵ₀} pos = struct (Int p, l, c);

This mode is meant to be used to:
- indicate position in a file
- indicate the maximum size of a file

Parenthetically, several of van Vliet's procedures take parameters int p, l, c:
- construct_book;
- do_set
- establish
- set
and these parameters are treated much like the fields of mode Pos.

I am currently thinking that we should try to support the use of "p,
l, c" wherever possible, even though it seems like a weird concept in
the POSIX file system (especially having a file with a maximum number
of pages, lines per page and characters per line).

Let's use a concrete example:

File foo;
establish (foo, "foo", stand_out_channel, 500, 50, 132);

The above should create a writeable system file called "foo" composed
of 500 pages of 50 lines per page and 132 characters per line.  If the
file is "compressible" it can have less than 500 pages each of less
than 50 lines per page each of less than 132 characters per line.

Now, digging deeper I find in the RR these "on routines":

> on logical file end. The corresponding event routine is called
> when, during input from a book or as a result of calling set, the
> logical end of the book is reached (see 10.3.1.6.dd).

The concept of "logical file end" makes sense to me; no current concerns there.

> on physical file end. The corresponding event routine is called when
> the current page number of the file exceeds the number of pages in
> the book and further transput is attempted (see 10.3.1.6.dd).

The only way I can see handling the concept of pages in a POSIX file
is by using a character - probably the FF, or form-feed, character -
to indicate the end of a page.

If we are using GNU Algol 68 to write POSIX files, then having the
new_page procedure emit a FF and counting the number of FFs emitted
(among other tasks) seems plausible.  Also, having the transput
library ensuring that there is a FF every not more than 50 lines (in
our "foo" example above) also seems plausible.

Weird, but plausible.

Reading a system file, we can count the number of FFs.  Probably if we
are reading a file generated by a non-Algol 68 program we won't
encounter too many FF characters.

If we call new_page while reading a non-Algol 68 file, it seems
probable that the program would read until logical end of file while
looking for the FF.

> on page end. The corresponding event routine is called when the
> current line number exceeds the number of lines in the current
> page and further transput is attempted (see 10.3.1.6.dd).

As I said above, when writing, either new_page can be called
explicitly by the programmer or implicitly by the transput routine
when the number of lines in the current page exceeds 50 (the "foo"
example).

If the programmer, when reading the system file, calls new_page and
there is no following FF, new_page will read characters until the
logical end of file is encountered, which should call the
on_logical_file_end procedure.

> on line end. The corresponding event routine is called when the
> current character number of the file exceeds the number of characters
> in the current line and further transput is attempted (see 10.3.1.6.dd).

Similar to the above, when reading, on_line_end could be called either
because the position being read is past the maximum line length (132
for the "foo" example) or because a line boundary character, probably
LF, was read.

On writing, on_line_end could be called either because the programmer
is trying to write a line longer than the maximum or because the
programmer called new_line.

On pp. 9-10 of van Vliet volume II appears the following:
>   Positions within the text are indicated by a page number, a line number and
>   a character number. Two positions are of importance during transput:
>       - the "logical end", i.e., the position up to which the book has been
>         filled with information;
>       - the "current position", i.e., the position at which the next transput
>         operation will (normally) operate.
>
>   Before any actual transput operation may take place, the validity of the
>   current position must be ensured. Whether a given position is "valid"
>   depends on the kind of operation that is desired. (If a newpage is to be
>   given, only the page number has to be within its bounds; if a character is
>   written, the line number and the character number must be within their
>   respective bounds as well.) If one of the position entities need not be
>   within its bounds, it may be off by one at the upper end; in that case, the
>   line, page or book is said to have "overflowed".
>
>   (If p, 1 and c denote the page number, line number and character number,
>   then a typical text may look as follows:
>
>
>       c=  1 2 3 4 5 6 7 8
>       i=1 ⊡ ⊡ ⊡ ⊡ ⊡ ⊡ ·
>   p=1   2 ⊡ ⊡ ⊡ ·
>         3 ⊡ ⊡ ⊡ ⊡ ·
>         4 ·
>
>       i=1 ⊡ ⊡ ⊡ ⊡ ·
>         2 ⊡ ⊡ ⊡ ⊡ ⊡ ⊡ ⊡ ·
>   p=2   3 ·
>         4 ⊡ ⊡ ⊡ ·
>         5 ·
>
>   p=3 i=1 ·
>
>   Possible positions are indicated by ".", although information can only
>   be present at positions within a box. For the dots that are not placed
>   within a box, the condition "line ended" holds. At <1,4,1>, <2,5,1> and
>   <3,1,1> the condition "page ended" holds too, while at <3,1,1> the condition
>   "physical file ended" holds as well. Note that the above picture shows a
>   text which has 2 pages.)
>
>   (If the page has overflowed, the current line is empty (so the line has
>   overflowed too), and, if the book has overflowed, the current page and line
>   are both empty (so the line and page have both overflowed).)
>
>   If the current position has overflowed the line, page or book, then it
>   is said to be outside the "physical file". The position where the complete
>   book has overflowed is termed the "physical file end". (There is only one
>   such position.)
>
>   If, on reading, the current position is at the logical end, then it is
>   said to be outside the "logical file". It is impossible for the current
>   position to be beyond the logical end. Likewise, it is impossible for the
>   logical end to be beyond the physical end.

>From the above I infer that we could expect LFs to be present in the
file at the end of each line.

For example, there appears to be an LF at position (1,1,7), 1,2,4), (1,3,5).

Moreover, as he states, (1,4,1), (2,5,1) and (3,1,1) are both LF and FF.

Ok, I think I have stated enough above about what I think,

Any comments?  Would anyone prefer to mostly or entirely chuck the
whole (p,l,c) here?
-- 
Chris Hermansen · clhermansen "at" gmail "dot" com

C'est ma façon de parler.