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

Previous Next

To reply to this bug, email your comments to 78481 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: autoconf-patches <at> gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Gaius Mulley <gaiusmod2 <at> gmail.com>, automake-patches <at> gnu.org,
 José Marchesi <jemarch <at> gnu.org>
Subject: Re: [PATCH V2] Support for the Algol 68 language
Date: Sun, 18 May 2025 16:40:29 +0200

Hi,

Reply to this mail thread:
https://lists.gnu.org/archive/html/autoconf-patches/2025-01/msg00014.html
https://lists.gnu.org/archive/html/autoconf-patches/2025-01/msg00015.html
https://lists.gnu.org/archive/html/autoconf-patches/2025-01/msg00016.html
https://lists.gnu.org/archive/html/autoconf-patches/2025-02/msg00000.html
https://lists.gnu.org/archive/html/autoconf-patches/2025-02/msg00004.html
https://lists.gnu.org/archive/html/autoconf-patches/2025-03/msg00000.html
https://lists.gnu.org/archive/html/autoconf-patches/2025-04/msg00000.html
https://lists.gnu.org/archive/html/autoconf-patches/2025-04/msg00001.html
https://lists.gnu.org/archive/html/autoconf-patches/2025-05/msg00000.html
https://lists.gnu.org/archive/html/autoconf-patches/2025-05/msg00004.html

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.

  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.

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.

I think part of the problem comes from looking at the Go support.

  * Go is different than Algol 68 and Modula-2. The reference implementation
    ('go') and the GNU implementation ('gccgo') are multi-purpose programs.
    To compile a program, one uses
      $ go build foo.go
      or
      $ gccgo build foo.go
    To compile and run a program, one uses
      $ go run foo.go
      or
      $ gccgo run foo.go

  * The AC_PROG_GO macro [6] sets variables GOC and GOFLAGS. Which already
    violates the letter of the GCS [2].

Since the AC_PROG_GO macro already violates the letter of the GCS [2] and is
instead following the rule "The compiler options for programming language X
is in variable XFLAGS", it is hard to reach both goals at the same time:
  (I) Following the letter of the GCS [2],
  (II) Consistency with the existing language support in Autoconf.

I can see two reasonable ways of naming the variables; the current proposal
from José is, unfortunately, not among them:

Proposal A: Define (I) as the more important goal.

  GO            GOFLAGS

  A68           A68FLAGS

  M2            M2FLAGS

  DC            DCFLAGS

  This implies changing AC_PROG_GO so that it defines the GO variable, and
  deprecating the GOC variable.

Proposal B: Define (II) as the more important goal.

  GOC           GOFLAGS

  A68 or A68C   A68FLAGS

  M2            M2FLAGS

  DC            DFLAGS

  Here (II) is nearly fulfilled, except that we cannot use M2C as variable,
  as explained above. So, goal (II) is not entirely reached. Instead, the
  *FLAGS variable depends on the programming language, not on the compiler
  command. Goal (I) cannot be reached either, but it's a reasonable compromise
  nevertheless.

Bruno

[1] https://gitweb.git.savannah.gnu.org/gitweb/?p=automake.git;a=blob;f=t/a68-demo.sh;h=a69d2328bbe7d74c65bdfd19be2e49e7b30a038f;hb=HEAD#l19
[2] https://www.gnu.org/prep/standards/html_node/Command-Variables.html
[3] https://www.mathematik.uni-ulm.de/modula/man/man1/m2c.html
[4] https://www.nongnu.org/m2c/
[5] https://github.com/m2sf/m2c
[6] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/html_node/Go-Compiler.html

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Jose E. Marchesi" <jemarch <at> gnu.org>
To: Bruno Haible <bruno <at> clisp.org>
Cc: Iain Buclaw <ibuclaw <at> gdcproject.org>, autoconf-patches <at> gnu.org,
 Paul Eggert <eggert <at> cs.ucla.edu>, "James K.
 Lowden" <jklowden <at> schemamania.org>, Robert Dubner <rdubner <at> symas.com>,
 automake-patches <at> gnu.org, arthur.cohen <at> embecosm.com,
 Gaius Mulley <gaiusmod2 <at> gmail.com>
Subject: Re: [PATCH V2] Support for the Algol 68 language
Date: Sun, 18 May 2025 17:21:02 +0200

[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.
>
> I think part of the problem comes from looking at the Go support.
>
>   * Go is different than Algol 68 and Modula-2. The reference implementation
>     ('go') and the GNU implementation ('gccgo') are multi-purpose programs.
>     To compile a program, one uses
>       $ go build foo.go
>       or
>       $ gccgo build foo.go
>     To compile and run a program, one uses
>       $ go run foo.go
>       or
>       $ gccgo run foo.go
>
>   * The AC_PROG_GO macro [6] sets variables GOC and GOFLAGS. Which already
>     violates the letter of the GCS [2].
>
> Since the AC_PROG_GO macro already violates the letter of the GCS [2] and is
> instead following the rule "The compiler options for programming language X
> is in variable XFLAGS", it is hard to reach both goals at the same time:
>   (I) Following the letter of the GCS [2],
>   (II) Consistency with the existing language support in Autoconf.
>
> I can see two reasonable ways of naming the variables; the current proposal
> from José is, unfortunately, not among them:

It actually was, initially ^^

> Proposal A: Define (I) as the more important goal.
>
>   GO            GOFLAGS
>
>   A68           A68FLAGS
>
>   M2            M2FLAGS
>
>   DC            DCFLAGS
>
>   This implies changing AC_PROG_GO so that it defines the GO variable, and
>   deprecating the GOC variable.
>
> Proposal B: Define (II) as the more important goal.
>
>   GOC           GOFLAGS
>
>   A68 or A68C   A68FLAGS
>
>   M2            M2FLAGS
>
>   DC            DFLAGS
>
>   Here (II) is nearly fulfilled, except that we cannot use M2C as variable,
>   as explained above. So, goal (II) is not entirely reached. Instead, the
>   *FLAGS variable depends on the programming language, not on the compiler
>   command. Goal (I) cannot be reached either, but it's a reasonable compromise
>   nevertheless.

For Algol 68 I always preferred A68/A68FLAGS to A68C/A68CFLAGS, and it
matches both proposals A and B.

So if the Autoconf and Automake maintainers agree to use Proposal A or
Proposal B, I will happily submit patches to change it in Automake and
update the Autoconf patch to reflect it.  Fortunately the Algol 68
support in Automake hasn't been released yet, so there is still time to
correct this.

Message #11 received at 78481 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: jemarch <at> gnu.org
Cc: ibuclaw <at> gdcproject.org, autoconf-patches <at> gnu.org, eggert <at> cs.ucla.edu,
 rdubner <at> symas.com, arthur.cohen <at> embecosm.com, jklowden <at> schemamania.org,
 78481 <at> debbugs.gnu.org, bruno <at> clisp.org, gaiusmod2 <at> gmail.com
Subject: Re: [bug#78481] [PATCH V2] Support for the Algol 68 language
Date: Sun, 18 May 2025 15:03:18 -0600

Personally I prefer A68 and A68FLAGS, without the C.

(And I'd like to make the Automake release quite soon.)

Thanks,
Karl (for Automake)

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

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, Paul Eggert <eggert <at> cs.ucla.edu>,
 Robert Dubner <rdubner <at> symas.com>, automake-patches <at> gnu.org,
 arthur.cohen <at> embecosm.com, "James K. Lowden" <jklowden <at> schemamania.org>,
 Gaius Mulley <gaiusmod2 <at> gmail.com>
Subject: Re: [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.

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gaius Mulley <gaiusmod2 <at> gmail.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: autoconf-patches <at> gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 automake-patches <at> gnu.org, José Marchesi <jemarch <at> gnu.org>
Subject: Re: [PATCH V2] Support for the Algol 68 language
Date: Tue, 20 May 2025 09:17:21 +0100

Bruno Haible <bruno <at> clisp.org> writes:

> 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.
>
>
> Proposal A: Define (I) as the more important goal.
>
>   GO            GOFLAGS
>
>   A68           A68FLAGS
>
>   M2            M2FLAGS
>
>   DC            DCFLAGS
>
>   This implies changing AC_PROG_GO so that it defines the GO variable, and
>   deprecating the GOC variable.
>
> Proposal B: Define (II) as the more important goal.
>
>   GOC           GOFLAGS
>
>   A68 or A68C   A68FLAGS
>
>   M2            M2FLAGS
>
>   DC            DFLAGS
>

Hi Bruno,

from the modula-2 perspective - this looks great thanks

regards,
Gaius

Message #22 received at 78481-done <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: jemarch <at> gnu.org
Cc: 78518 <at> debbugs.gnu.org, 78518-done <at> debbugs.gnu.org,
 78033-done <at> debbugs.gnu.org, 78481-done <at> debbugs.gnu.org
Subject: Re: [bug#78518] [PATCH] algol68: rename A68C and A68CFLAGS back to A68
 and A68FLAGS
Date: Wed, 21 May 2025 14:18:36 -0600

Installed, and closing this (and related bugs from the same discussion).
Thanks Jose. -k

Previous Next

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