GNU Algol 68 transput - why not use QAD?

[Jose E. Marchesi]

> 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!

Oh well.. back to the original plan then? :)