Van Vliet transput opinions solicited

[chris hermansen]

Hello everyone,

I have cracked open the van Vliet code to which Jose pointed me.  I have
done a first pass of SUPPERing it.  Now I am taking a look at the mode
definitions and I have some questions...

1. naming modes - shall I go with the SUPPER proposal of for example
    - the original mode BOOK -> mode Book
    - the original mode CHANNEL -> mode Channel
    - the original mode FILE -> mode File
    or does everyone prefer public modes e.g. CHANNEL, FILE to go to
channel, file
    so that they are similar to int, real, char, string etc?

2. to my way of thinking, the whole business with the triple (p,l,c)
creates a lot of weird
    situations when applied to something like character files as we all
know them in
    Linux:
    - many Linux files have no form feed characters embedded therein, so
calling
      newpage(f) when reading file f is most often just going to sail off
to the end of
      the file;
    - calling newpage(f) for binary reading or writing is of completely
dubious merit;
    - calling newpage(f) when writing a file could reasonably put a FF
character into
      the output stream;
    - the whole notion of fixed-length pages and lines is, in my experience
anyway,
      a completely unusual situation in Linux;
    - we would like to be able to seek to positions in files not
representable as an int;
    - decisions on implementing (p,l,c) affect many procedures, for example:
      - newpage, newline, on_page_end, on_line_end, on_logical_file_end,
        on_physical_file_end, set, open, establish, create, char_number,
        line_number, page_number, space, backspace, set_char_number, put,
get
    I don't have a really great compact solution to propose.  At one point,
I almost
    convinced myself to forget about page, line and char positions entirely
to
    see what that looked like - just dealing with FF and LF (or CR/LF) in
the
    character stream.  Still seems kind of appealing.  Any thoughts?

3. van Vliet often takes the approach of more non-published procedures to
    handle the low-level details of things, which seems to do a nice job of
    decoupling common code or really implementation dependent code
    from published procedures.  For example, he has a non-published
    proc find_book_in_system that is called by published proc open.

    I'm thinking that maybe this could be a thing to do in order to decouple
    some of the uncertain stuff (like (p,l,c) and its associated
assumptions such
    as fixed page and line length).  Any comments on this idea?  Maybe I
need
    to provide a specific example...

That's it for now.  Probably radio silence for the next few days as I'll be
otherwise occupied.
-- 
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/20260127/df743644/attachment.htm>