GNU Algol 68 transput - why not use QAD?
chris hermansen
clhermansen@gmail.com
Tue Jun 30 00:53:10 GMT 2026
Thanks for writing back, Jose,
On Mon, Jun 29, 2026 at 11:53 AM Jose E. Marchesi <jemarch@gnu.org> wrote:
>
> > 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? :)
>
I think so. But QAD provides proven ideas as to how to fill in some of the
"pseudo" stuff in van Vliet.
--
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/24a1b2f2/attachment-0001.htm>
More information about the Algol68
mailing list