gm2
[Top][All Lists]
Advanced

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

[Gm2] Naming conventions


From: Benjamin Kowarsch
Subject: [Gm2] Naming conventions
Date: Mon, 12 Mar 2018 05:17:24 +0900


On Mar 11, 2018, at 23:10, Fischlin Andreas wrote:

Dear all,

AFAIK your interpretation is right.

However, to make for once a comment on the bad habit of gm2 programmers to NOT capitalize procedures and types is really a very big drawback of gm2.

I agree in general, however, for our project at TWU we have chosen to use a lowercase convention for function procedures.



To give an example, the discussed code should have been coded as follows:

MODULE Test ;

CONST
  foo = Bar ;

PROCEDURE Bar (ch: CHAR) : CHAR ;
BEGIN
  RETURN CAP (ch)
END Bar ;

VAR
  ch: CHAR ;

BEGIN
  ch := foo ('a')
END Test.


In general the rules used by M2 programmers at ETH Zurich since its invention are:

types Start always with upper case - use class names
constants and variables   Start always with lower case - noun or adjective + type name
function procedures Start as procedures always with upper case - otherwise same rule as for variables
procedures (modules) Start always with upper case - use a verb

One of the biggest advantages is that basic types can be deduced naturally from the identifier, since capitalized are types or procedures, but the latter use verbs (only exception are function procedures) while types use class names. Lower case identifiers are a constant or variable, which can typically used interchangeably. These are the rules we have been following in general at ETH Zurich by all those programmers working in close collaboration with Niklaus Wirth and we never regretted following these rules. It is a pity gm2 code has unfortunately AFAIK largely ignored these very helpful conventions. Some arguments are nicely discussed in Keller (1990), but we do not capitalize, e.g. constants, as Keller writes. But Keller (1990) nicely explains the philosophy behind using nouns vs. verbs etc.

Regards,
Andreas


Cited References:
------------------------
Keller, D., 1990. A guide to natural naming. ACM, 25: 95-102.  doi: 10.1145/382080.382637   Ke183


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

address@hidden
www.sysecol.ethz.ch/Staff/af

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

             Make it as simple as possible, but distrust it!
________________________________________________________________________








On 10/03/2018, at 14:50, Gaius Mulley <address@hidden> wrote:

Michael Riedl <address@hidden> writes:

Hallo Gaius,

many thanks for the new version. Most compiler crashes I had before
are gone - only one is left.

Collected the necessary files in the attached tar file (it's the
module Differ.mod).

And one small hurdle is the renaming of functions, see
TestRename.mod. In my view a legal construct

COST CABS = LongComplexMath.abs;

(or similar) does not work.

Will do further tests (especially multidimensional arrays) and report.


Michael

Hi Michael,

many thanks for testing and the feedback.  Yes I had seen this in your
code, it is a very interesting usage.  Currently the compiler does not
handle this - but it could be changed - I see that it could be useful.

Separately to the above, I'd just like to clarify that this is ISO M2 legal?

MODULE test ;

CONST
  foo = bar ;

PROCEDURE bar (ch: CHAR) : CHAR ;
BEGIN
  RETURN CAP (ch)
END bar ;

VAR
  ch: CHAR ;
BEGIN
  ch := foo ('a')
END test.

I think this is so as the standard document p229 note 1 and 2 says:

1.  A value designator that denotes a function procedure is either a
procedure identifier of a function procedure heading (possibly qualified
by the name or names of modules from which the procedure identifier is
exported), a value designator that denotes a constant that has a
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
function procedure value, or a value designator that denotes a variable
^^^^^^^^^^^^^^^^^^^^^^^^
that has a function procedure type.

2.  The identifiers of predefined procedures are not value designators
since predefined procedures are not values that can be assigned,
compared in expressions or passed as procedure parameters.

assuming that my understanding is correct - I'll work on a fix,

regards,
Gaius

_______________________________________________
gm2 mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/gm2

<Ke183.pdf>_______________________________________________
gm2 mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/gm2


reply via email to

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