[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Identifier Naming

From: Fischlin Andreas
Subject: Re: Identifier Naming
Date: Mon, 27 Mar 2023 10:52:03 +0000

Again excellent arguments made by Benjamin, which would be very good to take to heart.


ETH Zurich
Prof. em. Dr. Andreas Fischlin
IPCC Vice-Chair WGII
Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics
CHN E 24
Universitaetstrasse 16
8092 Zurich

+41 44 633-6090 phone
+41 44 633-1136 fax
+41 79 595-4050 mobile

             Make it as simple as possible, but distrust it!

On 27 Mar 2023, at 11:15, Benjamin Kowarsch <> wrote:

One more thing on identifier naming ...

One might think that it cannot be helped but using C identifiers in Modula-2 code when using C libraries through a foreign function interface. At first, we fell into that trap, too. But eventually we found a very simple way how to map Modula-2 identifiers to identifiers of any language, even in the event that the identifiers of the library are in conflict with the Modula-2 grammar. We do this using a simple pragma to establish the mapping.

If you implemented this pragma in GM2, it will be possible to use Modula-2 identifiers for any foreign C identifier.

Not only C identifiers but any identifiers can be mapped to, as the example shows:

(* Interface to an OpenVMS SMG library routine *)
  ( displayID, pasteboardID : INTEGER; row, column : INTEGER ) : CARDINAL;

Such interfacing would not otherwise be possible unless the Modula-2 grammar was changed to allow dollar signs in identifiers. And what do you do when you want to interface to languages that permit yet other characters in identifiers, what if the identifiers can include hyphens or whitespace?

Isn't a generic facility that can cover any possible scenario while preserving the native identifier syntax much better than bolting on language extensions for every single case and make the identifier syntax more and more convoluted in the process?!


On Mon, 27 Mar 2023 at 17:58, Benjamin Kowarsch <> wrote:

On Mon, 27 Mar 2023 at 17:33, Fischlin Andreas wrote:

I use this opportunity to comment on another problem I have with gm2 given some sample code in this thread.

I wholeheartedly agree.
At the risk of repeating myself, strictly applying following capitalisation rules would make gm2 code much more readable:
  1. MODULE, TYPE, and PROCEDURE identifiers should always start with a capital
  2. CONST and VAR identifiers should start with a lower case. 
  3. PROCEDURE identifiers should be based on a verb
  4. TYPE identifier should be based on an adjective, adverb or a property describing noun.
A similar additional distinction for CONST and VAR identifiers as given by rules 3 and 4 does not exist but is less needed as semantically rarely of relevance in Modula-2.

It is always a good idea to decide on and write down a naming convention before starting to write the first line of code for any given project. Unless of course there is already an established and documented naming convention for the language itself, in which case it should probably be followed.

We did this for our project and it is part of the language specification document:

In addition to the naming convention, we also needed a coding standard to exclude the use of features that aren't portable between dialects and compilers since our bootstrap code has to be portable across dialects and compilers:

BTW, for me this is the biggest turn off from gm2 and its library.

Perhaps, GM2 could use a documented naming convention and coding standard, too.

Gaius, feel free to borrow. ;-)


Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]