Re: Identifier Naming

On 27 Mar 2023, at 11:15, Benjamin Kowarsch <trijezdci@gmail.com> 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.

https://github.com/m2sf/m2bsk/wiki/Language-Specification-(12)-:-Pragma-Facilities#pragma-ffident

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 *)
PROCEDURE PasteVirtualDisplay <*FFIDENT="SMG$PASTE_VIRTUAL_DISPLAY"*>
( 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?!

regards
benjamin

On Mon, 27 Mar 2023 at 17:58, Benjamin Kowarsch <trijezdci@gmail.com> 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:
MODULE, TYPE, and PROCEDURE identifiers should always start with a capital
CONST and VAR identifiers should start with a lower case.
PROCEDURE identifiers should be based on a verb
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:

https://github.com/m2sf/m2bsk/wiki/Language-Specification-(E)-:-Naming-Convention

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:

https://github.com/m2sf/m2bsk/wiki/Coding-Standard

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. ;-)

regards
benjamin

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