Van Vliet transput opinions solicited

[chris hermansen]

Thanks for the replies Jose.

Back in the saddle here after a longish weekend in the snow and -20° of
central Canada.  Brr.

On Wed, Jan 28, 2026 at 12:38 AM Jose E. Marchesi <jemarch@gnu.org> wrote:

>
> > 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?
>
> I would go with Book, Channel, File, etc.  In fact, I have in my TODO to
> remove M_FILE, M_CHANNEL, etc as predefined modes in the compiler.  By
> doing so it will be possible to do:
>
>    File file;
>    Channel channel;
>
> And I see little reason why adding these as keywords.
>

I've gone through van Vliet's code and here are some examples of mode
definitions now:

   - mode {ℵ₀} Book = ...
   - mode Channel = ...
   - mode {ℵ₀} SimplOut = union({<} {𝑳} int {>}, {<} {𝑳} real {>},
     {<} {𝑳} compl {>}, bool,
     {<} {𝑳} bits {>}, char, [] char);

and so on.  I've also converted things like 'bool mended' to 'bool_mended'.

I also decided to replace "a of b" with "a'b".  Doing this has reminded me
how I miss
the ability to refer to "self", when I see expressions like:

(line_mended of f)(f)

This " of " -> "'" is taking awhile since the word "of" occurs regularly in
comments...

I will also be putting "pub" in front of things that don't have a {ℵ₀} in
their declaration, and getting ready to run sppp on it.

I as yet do not have a concrete plan for dealing with his pseudo-things,
but I'm thinking about it as I go.


> > 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?
>
> Yes this is the big one :)
>
> I have some thoughts about this but still need to organize them.  I have
> to dedicate this week's nights to put the support for formal holes
> upstream and a couple of new bits operators, then this weekend is
> FOSDEM.  But afterwards I will go back to transput and (hopefully)
> provide some useful feedback.
>

There is another possibility, which is to "just do it" the way it is and
then start refactoring... which occasionally seems to me to be of greater
potential for success.

>
> > 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...
>
> I think I get it: that way you can start the implementation right away,
> leaving these details for later?  Makes sense to me.
>

Another example he has is delegating some of what proc newpage does to proc
do_newpage, and similarly for others.  But for now I'm not worrying about
this in detail.

As I was editing away I bumped into mode Number which reminded me that we
previously discussed doing away with such things and using the united-mode
directly as a parameter.  I continue to prefer this approach as one can
easily see whether all elements of the united-mode are matched in the
conformity-clause within the procedure body.

Another matter that I noticed while editing was this:

mode {ℵ₀} SimplOut = union({<} {𝑳} int {>}, {<} {𝑳} real {>},
  {<} {𝑳} compl {>}, bool,
  {<} {𝑳} bits {>}, char, [] char);

mode {ℵ₀} OutType = union(PSEUDO51, SimplOut, string, struct(proc OutType
outtype)) {

OutType:: union of OUTTYPERS mode.
OUTTYPERS:: OUTTYPER; OUTTYPER OUTTYPERS.
OUTTYPER:: PLAIN;
           structured with OUTTAGS mode;
           ROWS of OUTTYPER.
OUTTAGS:: OUTTYPER field TAG; OUTTYPER field TAG OUTTAGS.
};

op {ℵ₀} STRAIGHTOUT = (OutType x) [] SimplOut:
  [] SimplOut(pseudo53) { the result of "straightening" 'x' };

and similarly for SimplIn, InType and STRAIGHTIN.

Perhaps I haven't stared at this long enough, but I don't feel measurably
closer to an implementation of OutType and STRAIGHTOUT than I do with the
description in the RR.

-- 
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/20260203/d287044f/attachment-0001.htm>