GNU bug report logs - #78481
[PATCH V2] Support for the Algol 68 language

Previous Next

Package: automake-patches;

Reported by: Bruno Haible <bruno <at> clisp.org>

Date: Sun, 18 May 2025 14:41:01 UTC

Severity: normal

Tags: patch

Done: Karl Berry <karl <at> freefriends.org>

Full log


View this message in rfc822 format

From: ibuclaw <at> gdcproject.org
To: "Jose E. Marchesi" <jemarch <at> gnu.org>, Bruno Haible <bruno <at> clisp.org>
Cc: autoconf-patches <at> gnu.org, eggert <at> cs.ucla.edu, rdubner <at> symas.com, 78481 <at> debbugs.gnu.org, arthur.cohen <at> embecosm.com, jklowden <at> schemamania.org, gaiusmod2 <at> gmail.com
Subject: [bug#78481] [PATCH V2] Support for the Algol 68 language
Date: Tue, 20 May 2025 02:46:51 +0200 (CEST)
> On 18/05/2025 17:21 CEST Jose E. Marchesi <jemarch <at> gnu.org> 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.




This bug report was last modified 25 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.