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.
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?!