On Mon, 22 Apr 2024 at 17:33, Fischlin Andreas wrote:
Agreed, but let’s keep it simple.
In Wirth’s book PIM1 (I would call this the birth of M2) we find on p. 155
Operand types are said to be assignment compatible, if either they are compatible or both are INTEGER or CARDINAL or subranges with base types INTEGER or CARDINAL.
or our case with actual and formal parameters of procedures on p. 156
The types of corresponding actual and formal parameters must be identical In the case of variable parameters, or assignment compatible in the case of value parameters.
or in the report part of PIM1, i.e. p.161
The types of corresponding actual and formal parameters must be identical In the case of variable parameters, or assignment compatible in the case of value parameters.
And then I would say your fine wording
"Modula-2 follows loose name equivalence, except for assignments between (1) INTEGER and CARDINAL, (2) INTEGER and LONGINT, (3) LONGINT and CARDINAL, (4) REAL and LONGREAL, where implicit type conversion shall occur.”
while absent from the report is nevertheless the common assumption and practice in M2 since its beginning and I would argue we should continue using it, even if it makes compilers a bit more complex.
It may be a common assumption, but that doesn't mean it is correct behaviour.
I had already mentioned unary minus. That is a common assumption, too. And it is incorrect behaviour.
If the specification does not explicitly say that implicit conversion should occur, and in particular in which cases such implicit conversion should occur, then it is basically up to the compiler implementor to implement whatever conversions they please, leading to incompatibilities between implementations. Who says that there shouldn't be an implicit conversion between BOOLEAN and CARDINAL, or between REAL, CARDINAL and INTEGER, and between LONGREAL and LONGINT, or any other combinations? If the language specification is not authoritative, then why have a specification in the first place?
I am sorry but for me the language specification is always authoritative and should reign supreme. If any deviation is provided, that should be made explicit as a compiler specific extension and enabled through compiler switch.
Also, I consider this a matter of best practices in development management:
(1) No software should be written without a written specification.
(2) No behaviour that is not in the specification shall ever be implemented.
And it thus follows,
(3) should it become apparent that something is missing or incorrect in the specification, the specification must first be updated before development can commence.
This is a matter of project management and discipline. It has nothing to do with complexity of implementation.
I disagreed with Niklaus Wirth always on the point that programmer's life as a user of a language needs also to be considered when designing and/or defining a language, not only the compiler builder’s one. Keep it as simple as possible for all!
I agree wholeheartedly with those two sentences, and this is precisely why I argue against (1) features that are not in the language specification, and (2) implicit conversions.
Unspecified features violate the law of least astonishment and increase opportunity for error.
Implict actions also violate the law of least astonishment and increase opportunity for error.
In M2 R10 we have established as one of a few first principles: Explicit is preferable over implicit.
If you are concerned about the inconvenience of having to write explicit conversions, what about the inconvenience of having to read code without explicit conversions. It may be "easier" on the writer, but it sure isn't easier on the reader.
And if you are concerned about the inconvenient conversion syntax, then you should be asking how that syntax can be improved. In M2 R10 we recognised that with explicit conversions, the conversion syntax should be more convenient and intuitive, and thus we introduced a type conversion operator, which is ::, which coincidentally was or is the same in VAX-Pascal and PL/SQL.
i := n :: INTEGER;
n := i :: CARDINAL;
BTW, if the compiler provides a mechanism to do explicit conversions, then complexity of implementation is pretty much the same as with implicit conversions. The conversions have to be implemented anyway. It makes very little difference. As far as I am concerned, that is not the motive here. Clarity of code is.
regards
benjamin