GNU Algol 68 transput - why not use QAD?

[chris hermansen]

Good morning everyone,

I've spent some more time recently with QAD and I have some thoughts on why
it's not the best idea; please see below.

On Thu, Jun 25, 2026 at 7:26 PM chris hermansen <clhermansen@gmail.com>
wrote:

> Good evening everyone,
>
> On Thu, Jun 25, 2026 at 1:18 PM Jose E. Marchesi <jemarch@gnu.org> wrote:
>
>>
>> There may be two problems though:
>>
>> 1) The QAD prelude uses some ALGOL68-RS extensions, which very likely
>>    includes straightening.  Porting the relevant code may not be
>>    trivial.
>>
>
> There are a few such things I've stumbled over in my cursory inspection:
>
> - there is a mode VECTOR which is sort of like an Algol 68 row but with
> fixed lower bound 1 that is used for example to define the transput buffer;
> (PAME p. 218)
> - there is a kind of STRUCT that takes a size, making it sort of like an
> array, I think compatible with C arrays;
> - there is the BIOP 99/ "built-in operator" which 'maps its parameter (of
> one mode) onto its yield (of another mode). It effectively acts as a cast'
> from one mode to another (PAME p. 218-9);
> - mode SIMPLIN looks mostly like the RR definition except the last option
> in the union is "STRAIGHT SIMPLIN" which I take to be the straightening
> mechanism; (PAME p. 131);
> - and similarly for SIMPLOUT.
>
> Some interesting modes are CSTR = REF STRUCT 16000000 CHAR, whose trailing
> comment is # char * #, and CPTR = REF BITS, whose trailing comment is #
> void * #.
>
> BIOP 99 is used to realize quite a number of operator definitions (29 by
> my quick count).  A foursome that look interesting to me (qad/spops.a68)
> are:
>
> OP(REAL)STRUCT 8 CHAR             FLAT = BIOP 99;
> OP(SHORT REAL)STRUCT 4 CHAR       FLAT = BIOP 99;
> OP(STRUCT 8 CHAR)REAL             FLAT = BIOP 99;
> OP(STRUCT 4 CHAR)SHORT REAL       FLAT = BIOP 99;
>
> "oh so that's how we're going to get the sign, exponent, mantissa etc etc".
>
> An interesting comment on p. 219 of PAME is:
>
> "Then the value of mode CSTR [REF STRUCT 16000000 CHAR] is converted using
> the operator CSTRTORVC to a value of mode REF VECTOR[]CHAR which is
> dereferenced and then coerced to a value of mode STRING. In fact, the
> a68toc compiler will silently coerce values of mode REF STRUCT i MODE to
> mode REF VECTOR[]MODE and thence to REF[]MODE. Notice that you cannot
> coerce a value of mode REF VECTOR[]MODE to REF FLEX[]MODE. The mode STRING
> has no flexibility (it is equivalent to []CHAR).
>
> Of course I'm relieved that a68toc doesn't noisily coerce the
> above-mentioned values, but this sounds somewhat involved.
>
> Not all of the tricky bits are handled by BIOP 99; for example
> (qad/spops.a68):
>
> OP CSTRTORVC = (CSTR s)RVC:
> # Converts a C string to an RVC using the standard RS Algol 68
>   compiler REF STRUCT n CHAR to RVC coercion. Mainly used to
>   access C strings yielded by C library routines. The string
>   must be null-terminated. #
> IF s:=:NIL THEN NIL ELSE s[:posix strlen(s)] FI;
>
>
>>
>> 2) Unfortunately Dr. Sian Leitch (later Sian Mountbatten) didn't specify
>>    any license in the source files under ctrans/qad.  Just:
>>
>>         Copyright (C) 2000 Sian Leitch
>>
>>    Since she is deceased, we cannot ask her to clarify the distribution
>>    terms of that code.
>>
>
> The GitHub repo I've been examining includes the same copyright; the
> bottom of the README is signed:
>
> Neil Matthew
> neil@tilde.co.uk
> May 2021
>
> It may be worthwhile contacting him.
>
>
>
>>
>>    It _might_ be ok to assume these files are intended to use the same
>>    distribution terms than the ctrans compiler itself, which is:
>>
>>
>>        Use, reproduction, production of amended versions and/or transfer
>>        of this Program is permitted provided that:
>>
>>        (a)  this legend be preserved on any such reproduction and amended
>> version,
>>        (b)  any amended version of this Program be clearly marked to show
>> the
>>             nature of the amendment and of the name of the amending
>> organisation,
>>             and
>>        (c)  any recipient  of such reproduction or amended version accept
>> the
>>             conditions set out in this legend.
>>
>>
>>    The copyright holder of ctrans is the UK Crown.
>>
>> The first problem is not a big one necessarily.  We will have to face
>> straightening sooner or later, be it via user visible coercion like
>> ALGOL 68RS or, as I would prefer, via compiler-wired pragmats in the
>> relevant transput procedures.
>>
>
> The beginning of Chapter 9  indicates:
>
>  "At various points you have been reading external values from the
> keyboard and displaying internal values on the screen. This chapter
> addresses the means whereby an Algol 68 program can obtain external values
> from other sources and send internal values to places other than the
> screen. straightening is the only new language construct involved and all
> the matters discussed are available in the standard prelude.
>
> On p. 132 PAME states 'The STRAIGHT operator converts any structure or
> multiple into a row of values of the constituent fields or elements'.  But
> the only place I find STRAIGHT occurring is in the SIMPLIN and SIMPLOUT
> mode definitions (qad/spmodes.a68) and as mode selector in
> conformity-clauses in get, put, get_bin and put_bin (qad/transput.a68).  In
> neither case does STRAIGHT seem to be working as an operator.
>
>
>
>
>
>> I would like to ask the Free Software Foundation about the second, to be
>> on firm ground.
>>
>
> Sounds like a decent idea, especially if a conversation with Neil Matthew
> doesn't pan out.
>
>>
>> > I like Mountbatten's QAD, including the different channels it supports.
>> > She spent a looong time getting that prelude right.
>> >
>> > We could first port it from ALGOL68-RS (ctrans) to GNU Algol 68, then
>> > see to do some modifications.
>> >
>> > I would be ok with that approach.
>> >
>> >> Good morning everyone,
>> >>
>> >> In the process of attempting to implement van Vliet's transput code on
>> top
>> >> of POSIX, I've been spending more time looking at QAD (the Algol 68 to
>> C
>> >> translator's standard prelude and transput code) as well as
>> /Programming
>> >> Algol 68 Made Easy/, Mountbatten's textbook on using a68 toc.
>> >>
>> >> This morning I realized that, were someone to ask me why GNU Algol 68
>> >> should not use QAD transput, I could not present a cogent argument
>> against
>> >> that idea.
>> >>
>> >> Sooooooooooo.... anyone here familiar with Algol 68 and willing to
>> convince
>> >> me that using QAD transput - as "as-is as possible" - would be a bad
>> idea?
>>
>
> No takers on "QAD is a bad idea"?
>

 Some things to ponder about reusing QAD (at least, as-is anyway):

   1. "The a68toc compiler does not support formatted transput" (PAME
   p.262) - I assume we would like to have this capacity, so if we wish to
   build on past experiences, we will need to bolt some format capacity (van
   Vliet, for example) onto QAD.  I note in passing that GNU Algol 68 does not
   currently support Format denotations, so I presume we would first want to
   settle on the mode definition for Format, then on the ability to parse
   denotations into that structure.
   2. The builtin "thing" called STRAIGHT which is used by the declaration
   of modes SIMPLIN and SIMPLOUT and which PAME calls an operator; and yet it
   appears in mode declarations in a manner similar to REF and in
   conformity-clauses.
   3. Neither modes SIMPLIN nor SIMPLOUT include PROC(REF FILE)VOID, nor
   does the declaration of procedures getf nor putf, which leaves me wondering
   how one passes (say) newline to them; though PAME p.131 claims this is
   possible.
   4. There are some additional built-ins required to support QAD in
   a68toc, including the STRUCT n and VECTOR modes and various modes derived
   from them, operators and procedures that use them (PAME §13.5).
   5. There some equivalences between the Algol 68 implementation in a68toc
   and the C language, including mode CPTR = ref bits { void * }, CINTPTR =
   ref int { int * }, CCHARPTR = ref char { char * }, and a few others (PAME
   §13.5).  Also generally the way one writes procedures to be passed as
   parameters to system routines (PAME §13.5).
   6. The garbage collector is exposed and parametrized in the transput
   module (to what end I cannot say at this time) (PAME §13.5).
   7. The BIOP 99 construct is used to "reinterpret" memory locations as
   different modes; for example op(real) struct 8 char FLAT = BIOP 99 converts
   a real (double precision) into something similar to a [1:8]char (PAME
   §13.5).
   8. REAL in algol68toc is double precision and SHORT REAL is single
   precision; also for COMPL and SHORT COMPL.

So in summary, to use QAD as-is will be difficult; at least the mechanisms
defined in the GNU Algol 68 compiler to link with C will have to be
reviewed and changes may be required to the QAD code in order to
accommodate those mechanisms.

I am tending to think that the best use of QAD could be as a concrete guide
to implementing some of the lacunae in van Vliet.

I hope to hear reactions to all of this!

-- 
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/20260629/e2597a90/attachment-0001.htm>