On Mar 12, 2018, at 17:14, Fischlin Andreas wrote:
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.
Fair enough, since function procedures can be generally used in expressions in place of a variable (or constant). And indeed function procedures such as sin(x) look better with lower case [...snip...].
However, [...snip...], there is another difference. We use lower case for constants to emphasize that constants and variables can be used typically interchangeably and that they can be easily distinguished from the capitalized types.
To us it was important that readers of the code could easily tell the difference between constants and variables even if the code is not rendered by a syntax highlighter.
I do not see how distinguishing constants from types could become an issue. Constants are used within expressions, types aren't (except in type transfers). Types are used within type and variable declarations, constants aren't (except in array bounds). This does not have any potential for ambiguities/confusion.
By contrast, there is an issue with distinguishing constants and variables. Both constants and variables are used within expressions and this does present potential for ambiguity/confusion.
This is all the more important in classical Modula-2 where variables are exported mutable (even though PIM clearly recommends that they shouldn't -- alas, Wirth didn't follow his own recommendation).
In summary, there isn't a need for assistance in telling constants and types apart, but there is a need for assistance in telling constants and variables apart.
Starting constants with an uppercase character and variables with a lowercase character provides a simple and elegant solution.
As for math constants like e, pi, tau, etc, we make an exception for those.
Since there are fewer math constants than there are math functions, our naming convention (capitalised constants and lowercase functions) requires fewer exceptions than yours (capitalised functions and lowercased constants).
From this angle, I trust this makes more sense now.
having visited the given website (thanks, did not know it)
This is merely the public repository of our project on github. Github provides the option of a wiki for each repo which is very useful since everything is then in one place.
regards
benjamin
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.
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!
________________________________________________________________________
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
_______________________________________________
gm2 mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/gm2