Re: Size of SET type

[Fischlin Andreas]

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

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

andreas.fischlin@env.ethz.ch

www.sysecol.ethz.ch/people/andreas.fischlin.html

+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 06:44, Benjamin Kowarsch <trijezdci@gmail.com> wrote:

Hi Gaius,

On Mon, 27 Mar 2023 at 05:17, Gaius Mulley wrote:

here is a further example using the <* bytealignment(0) *> attribute
(for non SET types):

TYPE
    Small_Set_T = PACKEDSET OF [0..7] ;
    bar = ARRAY [0..7] OF BOOLEAN <* bytealignment(0) *> ;

Using language syntax should be reserved for features that have semantic impact, while pragmas should be used for features that merely influence the compilation process without changing the semantics. Controlling alignment does not alter the semantics, it is merely an optimisation. It should therefore always be done by pragma, not by language syntax.

Very unfortunately, PACKEDSET is one of those things ISO M2 inherited from WG13, the sum of which then messed up the entire standard leading to a bloated and inconsistent design. It is thus understandable that you wanted to keep the feature around, just so as to satisfy the standard specification.

However, it does introduce yet another inconsistency when the alignment pragma won't apply to SET types. It would be more consistent to simply allow the alignment pragma to also be used with SET types in effect becoming a PACKEDSET. Although this violates the principle that there should ideally be only one single syntax for every feature, one has to ask the question, which is worse: The inconsistency/non-orthogonality or the violation of the single-syntax principle?

In my view, consistency and orthogonality is far more important and in order to preserve it, a violation of the single-syntax principle is the lesser evil in this particular case.

Furthermore, when GM2 is used in PIM mode, there is no PACKEDSET type constructor, but the pragma should still be available.

I therefore encourage you to allow the alignment pragma to be used with the SET constructor in both PIM and ISO mode.

I also encourage you to implement the pragma convention in our revised M2 specification:

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

Note this is a reduced pragma set for the bootstrap specification which lacks the alignment pragma. In the complete set, the alignment pragma symbol is ALIGN. For any implementation specific pragmas, there should be a compiler identifier preceding the pragma symbol, thus

Common pragma:

TYPE FooSet = SET OF [0..7] <*ALIGN=1*>;

GM2 specific pragma:

TYPE FooSet = SET OF [0..7] <*gm2.bytealignment(0)|WARN*>;

The idea here is that a compiler can always identify whether any given pragma is intended for it or not, and what to do if a pragma is found that is specific to another compiler. This way, the facility becomes portable even for unknown pragmas, which is possible precisely because pragmas do not change semantics, but only optimisations (in the widest sense).

regards

benjamin

smime.p7s
Description: S/MIME cryptographic signature