Discussion:
Modula-2 Dialect Comparison Chart
(too old to reply)
trijezdci
2016-08-28 14:23:57 UTC
Permalink
http://modula-2.info/m2r10/pmwiki.php/Reference/ComparisonChart
tbreeden
2016-08-29 17:01:45 UTC
Permalink
Post by trijezdci
http://modula-2.info/m2r10/pmwiki.php/Reference/ComparisonChart
nice!
Martin Brown
2016-08-30 09:21:59 UTC
Permalink
Post by trijezdci
http://modula-2.info/m2r10/pmwiki.php/Reference/ComparisonChart
That is an impressive list and comparison. I have a few minor comments.

A couple of these I know we will have to agree to disagree on but there
are a couple of quirks here that I think do need refining in the draft.

Having REAL subrange types worries me a bit.

[0..0.1] of REAL will have fence post issues in IEEE FP implementations
since there is no finite representation of 0.1 aka 1/10 in base 2.

I'd hope there is a pragma to permit old style constants or you
immediately orphan all pre-existing Modula 2 code by requiring rework
just to try it out with the new compiler.

Constant delimiters 123'456'789 is there any reason why it can't be ,
(granted some cultures use "," for "." in FP numbers but M2 doesn't)

String delimiters are not mentioned. PIM allowed both " and '.
The string examples in the text only use "".

The empty statement ";" has already been done to death.

The case for killing unary "+" is the same philosophy
(and I agree that *it* should go)

However, it rears its ugly head again in the CASE statement.

The "|" is a logical OR separating the various cases and as such should
only appear between clauses and not precede the first one. It is
inconsistent to put this "|" phantom in and then fault trailing ";".

The other thing is that it should have an ELSE clause in both columns

CASE statement
CASE a OF b1: ... | b2: ... ELSE ... END;
CASE a OF | b1: ... | b2: ... ELSE ... END;

ELSE being the path taken if none of the CASEs are met.

There was also an ugly kludge in PIM M2 where you could do something of
the form of a CASE BOOLEAN OF TRUE: | FALSE: END inside a RECORD to
create a variant that could be interpreted different ways. I presume
this is so far against the spirit of R10 that you don't even mention it.
The ugliness of this should still be recorded for posterity.

I think removing generic FOR loops is a mistake. They are used for a lot
more than just iterating over ARRAYs and limiting them to only that will
result in inconvenience when for example summing the results obtained by
calling a function whilst doing an integration for instance.

It is also necessary to iterate repeatedly over some arrays with a
sequence of unusual strides for example in the computation of an FFT.

Likewise I think removing WITH is probably a mistake as using this
wisely makes code using records a lot more readable.

I'm inclined to think that the "T" in TMAX, TMIN etc is redundant.

I also reckon that HALT(status) should be promoted out of UNSAFE and
into predefined procedures. You want to encourage people to use it.

That is about all I can see.

I think CASE statement and FOR statements both need adjustment.
--
Regards,
Martin Brown
trijezdci
2016-08-30 09:57:49 UTC
Permalink
Post by Martin Brown
That is an impressive list and comparison. I have a few minor comments.
I respond here to the points that are factually incorrect or missing in the chart. All other comments, I will reply to in separate threads.
Post by Martin Brown
String delimiters are not mentioned.
Good catch. I simply forgot those :-) Added now.
Post by Martin Brown
[The CASE statement] should have an ELSE clause in both columns
CASE statement
CASE a OF b1: ... | b2: ... ELSE ... END;
CASE a OF | b1: ... | b2: ... ELSE ... END;
Indeed, added now.

I had left it out because two of the machines I used to check how it looks have lower resolution displays which caused ugly table formatting issues.


thanks for the feedback.

Loading...