gm2
[Top][All Lists]
Advanced

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

Re: Size of SET type


From: Fischlin Andreas
Subject: Re: Size of SET type
Date: Tue, 28 Mar 2023 12:51:22 +0000

Dear Gaius,

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.

Andreas


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
SWITZERLAND


+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 17:08, Gaius Mulley <gaiusmod2@gmail.com> wrote:

"Fischlin  Andreas" <andreas.fischlin@env.ethz.ch> writes:

Dear all,

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.

Andreas

Hello Andreas,

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 [1] and [2] are violated

regards,
Gaius

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


reply via email to

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