Excellent, thanks. I believe these naming conventions do greatly enhance the readability of M2 code, at least in my experience of decades of programming in M2 ;-). And making such naming conventions conspicuous for anyone helps, as it is good to hear about such conventions upfront. Of course they are old as they come from PIM times, i.e. when I collaborated with Niklaus Wirth and his colleagues.
Prof. em. Dr. Andreas Fischlin
IPCC Vice-Chair WGII
Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics
CHN E 24
+41 44 633-6090 phone
+41 44 633-1136 fax
+41 79 595-4050 mobile
Make it as simple as possible, but distrust it!
"Fischlin Andreas" <email@example.com
Benjamin is making excellent points I fully concur with and urge to consider.
However, I use this opportunity to comment on another problem I have with gm2 given some sample code in this thread. 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.
These simple rules are a very useful and well established practice how to code in Modula-2 as it let’s one immediately understand what kind of object one is dealing with, in particular also in code sections that are far
below the initial declaration. They have proven to be very helpful for efficient programming (reading, writing, checking correctness of code etc). It escapes me why gm2 seems to be plagued from C like or other habits
that deviate from this helpful Modula-2 practice. A pity. BTW, for me this is the biggest turn off from gm2 and its library.
many thanks for the suggestions - I'll add these guidelines to a new
section in the documentation - and migrate the source code to adopt them
(internally). It might be useful to have a -fm2-style option which
emits notes when  and  are violated