On 28/08/2016 15:23, trijezdci wrote:
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)