Subject: [bug#78481] [PATCH V2] Support for the Algol 68 language

From: [email-masked]
Date: Tue, 20 May 2025 02:46:51 +0200 (CEST)

> On 18/05/2025 17:21 CEST Jose E. Marchesi <[email-masked]> wrote:
> 
>  
> [Adding in CC:
>  - Iain Buclaw, the D front-end maintainer for GCC.
>  - Arthur Cohen, the Rust front-end maintainer for GCC.,
>  - James K. Lowden and Robert Dubner, the COBOL front-end maintainers
>    for GCC.]
> 
> Hi Bruno.
> 
> > In <https://lists.gnu.org/archive/html/autoconf-patches/2025-04/msg00000.html>
> > Paul Eggert renamed the variable A68 → A68C, with the rationale:
> >   "Use the shell variable A68C, not A68,
> >    for the compiler.  This is for consistency of names compared to
> >    support for other languages like Go."
> >
> > In <https://lists.gnu.org/archive/html/autoconf-patches/2025-05/msg00000.html>
> > José Marchesi renamed the variable A68FLAGS → A68CFLAGS, with the rationale:
> >   "as mandated by the GCS"
> >
> > The result of these renamings makes no sense to me:
> >
> >   1) The GNU Algol 68 compiler is meant to be named 'ga68', not 'ga68c'. [1]
> >      The prefix 'g' is specific for the GNU implementation; it's normal
> >      to ignore it here, when we talk about conventions that should encompass
> >      non-GNU implementations as well.
> 
> Some other GCC compilers use 'gcc' as a prefix, which I think could also
> be considered "specific for the GNU implementation".  If so, we would
> have:
> 
>   gcc      CC
>   g++      CXX
>   gdc      DC
>   ga68     A68
>   gcobol   COBOL
>   gm2      M2
>   objc     OBJC
>   gccrs    RS
>   gccgo    GO
> 
> >   2) The GCS [2] has examples where the variable name is the program name,
> >      uppercased.
> >
> >   3) As a result, users would be looking for a command 'a68c', but there is
> >      no such command.
> 
> Yes I agree, that is bad.
> 
> > I'm bringing this up because a similar case will be with the GNU Modula-2
> > compiler, when we want to support it in Autoconf and Automake.
> >
> >   * The GNU Modula-2 compiler is called 'gm2'. Therefore it will be natural
> >     (per GCS [2]) to call the variables M2 and M2FLAGS.
> >
> >   * Calling the variable M2C would be very very confusing, because there is
> >     a Modula-2 to C translator called 'm2c' [3][4][5] and, unlike gm2, it
> >     produces C code, not an executable.
> >
> > And the big picture should also consider the GNU D compiler, when we want
> > to support it in Autoconf and Automake.
> >
> >   * The GNU D compiler is called 'gdc'. Therefore, and because a 1-letter
> >     variable 'D' would be really odd, it makes sense to called the program
> >     variable 'DC'.
> >
> >   * Whether the flags variable is then called DFLAGS (for consistency with
> >     CFLAGS) or DCFLAGS (per GCS [2]), can be debated.
> >

WRT D env flags, this was added quite some time ago, I can't say I recall the rationale, but mirroring CC/CFLAGS seems to be what was done.

However, within GCC configure/make scripts, the env variables are GDC and GDCFLAGS respectively.

In the DM implementation of D, they also used DC/HOST_DC in their make scripts at one point. This is now dropped in favour of DMD/HOST_DMD.

> > Proposal A: Define (I) as the more important goal.
> >
> >   GO            GOFLAGS
> >
> >   A68           A68FLAGS
> >
> >   M2            M2FLAGS
> >
> >   DC            DCFLAGS
> >

If you were to go with this convention, I think it would make more sense to name the flags D2 and D2FLAGS.

Pedantically, it *is* version 2 of the language (and there's no appetite to change the versioning from 2.xxx to 3.x) - though no one expresses it that way in conversation, it's either D or dlang.

Iain.