Re: [PATCH V2] Support for the Algol 68 language

> On 18/05/2025 17:21 CEST Jose E. Marchesi <[email protected]> wrote:
>=20
> =20
> [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.]
>=20
> Hi Bruno.
>=20
> > In <https://lists.gnu.org/archive/html/autoconf-patches/2025-04/msg0000=
0.html>
> > Paul Eggert renamed the variable A68 =E2=86=92 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/msg0000=
0.html>
> > Jos=C3=A9 Marchesi renamed the variable A68FLAGS =E2=86=92 A68CFLAGS, w=
ith 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 enco=
mpass
> >      non-GNU implementations as well.
>=20
> 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:
>=20
>   gcc      CC
>   g++      CXX
>   gdc      DC
>   ga68     A68
>   gcobol   COBOL
>   gm2      M2
>   objc     OBJC
>   gccrs    RS
>   gccgo    GO
>=20
> >   2) The GCS [2] has examples where the variable name is the program na=
me,
> >      uppercased.
> >
> >   3) As a result, users would be looking for a command 'a68c', but ther=
e is
> >      no such command.
>=20
> Yes I agree, that is bad.
>=20
> > 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 nat=
ural
> >     (per GCS [2]) to call the variables M2 and M2FLAGS.
> >
> >   * Calling the variable M2C would be very very confusing, because ther=
e 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 wa=
nt
> > to support it in Autoconf and Automake.
> >
> >   * The GNU D compiler is called 'gdc'. Therefore, and because a 1-lett=
er
> >     variable 'D' would be really odd, it makes sense to called the prog=
ram
> >     variable 'DC'.
> >
> >   * Whether the flags variable is then called DFLAGS (for consistency w=
ith
> >     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 t=
he rationale, but mirroring CC/CFLAGS seems to be what was done.

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

In the DM implementation of D, they also used DC/HOST_DC in their make scri=
pts 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.