Problem 1
A question from Rick Sutcliffe on behalf of Dmitry Leskov
Hi all
What do the rest of you lawyers think of this question?
Rick
>From: "Leskov, Dmitry"
>To: "'Rick Sutcliffe'"
>Subject: A question on the Modula-2 standard
>Date: Tue, 16 Jun 1998 16:58:46 +0700
>X-Priority: 3
>
>Dear Rick,
>
>A researcher of our institute currently translates the ISO M2 standard
>into Russian. He has encountered a problem understanding the parameter
>compatibility rules. Can you help? I'm inserting his question below.
>
>Thanks in advance,
>
>Dmitry Leskov
>
>
>Consider the example:
>
> MODULE M; FROM SYSTEM IMPORT LOC;
> TYPE L = ARRAY [0..1],[0..1] OF LOC;
> T = ARRAY [0..1],[0..1] OF CHAR;
> VAR r: ARRAY [0..1] OF T;
> PROCEDURE P (x: ARRAY OF L); BEGIN END P;
> BEGIN P(r)
> END M.
>
>Do the formal and actual parameters, x and r, match, as it seems
>plausible to be the case? But let us see.
>
>According to 6.9.3.1 (Static Semantics), the formal type of a value
>parameter is compatible with the type of an actual parameter in the
>four cases (a-d), from which only case c) MAY BE valid in our
>situation. This case c) requires that the component type of the formal
>type (here L) should be "open-array-component-compatible" with the
>component type of the actual type (here T). In its turn
>"open-array-component-compatibility" means one of the following:
>1) Either the component types of the formal and the actual types,
> namely L and T, are system storage parameter compatible - but it's
> not the case (see 6.9.3.3).
>2) Either L and T are identical identified types - neither this is the
> case.
>3) Or L and T have themselves component types, here LOC and CHAR, that
> are compatible in one of the ways 1) or 2). This implies that at
> least L is an identified array type (as it is in our example) and
> L therefore may not be considered neither as a formal type nor as
> an open array.
>
>Or we are not right and L shall be tacitly understood as both, in
>which case the point 1) will fit and the procedure M will work?
>
>And, by the way, does the situation depend on the number of dimentions
>in L and T?
>
>REFERENCE: Draft International Standard, ISO 10514-1994
>
>---------------
>Dmitry V. Leskov
>XDS Products Division Manager
>snowman@xds.ru
>
>XDS Ltd. Home Page is http://www.xds.ru/
>
Rick Sutcliffe Math/Cmpt Trinity Western University
CDN Chair WG13, FAQ maintainer comp.lang.modula-2
Answer from Keith Hopper:
Greetings from a wet and soggy winter,
I thought to reply to the question Rick sent out, not so much as from
just an M-2 interpretation point of view, but also wearing my WG20 'hat'.
The question posed was --
> >Consider the example:
> >
> > MODULE M; FROM SYSTEM IMPORT LOC;
> > TYPE L = ARRAY [0..1],[0..1] OF LOC;
> > T = ARRAY [0..1],[0..1] OF CHAR;
> > VAR r: ARRAY [0..1] OF T;
> > PROCEDURE P (x: ARRAY OF L); BEGIN END P;
> > BEGIN P(r)
> > END M.
> >
> >Do the formal and actual parameters, x and r, match, as it seems
> >plausible to be the case? But let us see.
Apart from the fact that a LOC is implementation defined (see 7.1.3.1) and
a CHAR value (see 6.10.2.5) has an implementation-defined encoding which
are NOT required in the standard to be compatible definitions, there is, in
the days of ISO 10646, the problem that a character encoding may be
anything up to 192 bits in size, depending on the character being encoded.
I understand the query, but suggest that the correct interpretation IN
THIS CASE at least has to be based upon the fact that the standard nowhere
requires compatibility between types in SYSTEM (which have an
implementation-defined meaning) and language defined types which have
implementation-defined instance values.
Just my penn'orth!
Keith
Answer from Albert Wiedemann
Hi all,
> MODULE M; FROM SYSTEM IMPORT LOC;
> TYPE L = ARRAY [0..1],[0..1] OF LOC;
> T = ARRAY [0..1],[0..1] OF CHAR;
> VAR r: ARRAY [0..1] OF T;
> PROCEDURE P (x: ARRAY OF L); BEGIN END P;
> BEGIN P(r)
> END M.
>
>Do the formal and actual parameters, x and r, match, as it seems
>plausible to be the case? But let us see.
Really a nice riddle, more because it looks like "all is clear" as is
stated above.
The VDM gives a (for me at the first moment) unexpected answer (see
6.9.3.1):
"is-value-parameter-compatible" : the third condition holds, we have to
look at "is-open-array-value-parameter-compatible"
"is-open-array-value-parameter-compatible": "is-array-type (et)" returns
true, we have to look at "is-open-array-component-compatible"
"is-open-array-component-compatible" none of the conditions holds, so:
r *is not* value parameter compatible to "ARRAY OF L".
Well, thatīs unexpected, but that's ok, as the history of system types
tells. In PIM (2) the only system storage type was "WORD" (enough e.g. for
the old Lilith computers). Later "BYTE" was added, as this was need for
byte oriented machines. Anything was compatible to ARRAY OF BYTE, and
anything with a size that is a multiple of TSIZE (WORD) was compatible to
ARRAY OF WORD.
To be more flexible for the future (and to have a clean model) the standard
replaced all machine dependent system storage types by LOC and ARRAY [0 ..
n-1] OF LOC. These (and only these) types replaced the old BYTE and WORD
(and whatever type an implementation might have added).
"L = ARRAY [0..1],[0..1] OF LOC;" is *not* one of the privileged types, so
compatibilty is tested accoring to the "normal" rules, which say "no", as
"LOC" and "CHAR" are different types.
A remark on Keith's mail:
TSIZE (CHAR) needs not be 1, but it is implementation defined, so a value
of type CHAR or a value of type ARRAY [min .. max] OF CHAR is in any case
value parameter compatible to x: ARRAY OF LOC, though HIGH (x) may differ
on different implementations.
Greetings,
Albert
Answer from Peter Moylan:
On Sat, 20 Jun 1998 17:00:03 -0400, Albert Wiedemann wrote:
>> MODULE M; FROM SYSTEM IMPORT LOC;
>> TYPE L = ARRAY [0..1],[0..1] OF LOC;
>> T = ARRAY [0..1],[0..1] OF CHAR;
>> VAR r: ARRAY [0..1] OF T;
>> PROCEDURE P (x: ARRAY OF L); BEGIN END P;
>> BEGIN P(r)
>> END M.
>>
>>Do the formal and actual parameters, x and r, match, as it seems
>>plausible to be the case? But let us see.
>
>Really a nice riddle, more because it looks like "all is clear" as is
>stated above.
[Analysis snipped]
>"L = ARRAY [0..1],[0..1] OF LOC;" is *not* one of the privileged types, so
>compatibilty is tested accoring to the "normal" rules, which say "no", as
>"LOC" and "CHAR" are different types.
I think Albert is right, but this points out a problem:
(a) This was a question that was difficult even for the experts.
(I, personally, could not have answered it without some very careful
searching through the standard.) Yet it is, in principle, the sort of
question that you'd think any reasonably competent programmer
could answer.
(b) The correct answer is illogical, in my opinion. It doesn't seem
right to have one rule for one-dimensional arrays, and a different
rule for two-dimensional arrays. This violates the principle of
"no hidden surprises".
What this means to me is that there is a glitch in the language
definition that ought to be fixed in order to restore "economy of concept".
Is anyone keeping track of issues that should be addressed for the
next revision of the standard? There are a couple of other things like
this that have occurred to me from time to time, and it would be useful
to have a master list somewhere.
Peter
Answer from Wolfgang Redtenbacher
Peter Moylan wrote on
22-Jun-98 02:18 CEST:
>I think Albert is right, but this points out a problem:
> (a) This was a question that was difficult even for the experts.
> ...
> (b) The correct answer is illogical, in my opinion. ...
>
>What this means to me is that there is a glitch in the language
>definition that ought to be fixed in order to restore "economy
>of concept".
As Keith had answered Rick's question within hours and correctly
pointed out that the 2 types in question were NOT compatible, I
considered the matter cleared up and thus saw no need to post
myself. And Albert's analysis was of course correct.
Peter's statements, however, raise my disagreements:
(a) A programmer who carefully checks the standard, can find the
answer both in the normal text and in the VDM. So there is
neither an error nor an omission in the standard. (And a sloppy
programmer who is too lazy to study the standard would anyway
"answer" the question by simply attempting to compile some sample
code with a conforming ISO M2 compiler and check whether the
compiler complains or not ...)
(b) The answer is not illogical. The fact that any type is
assignment compatible with an "ARRAY OF LOC" (= unstructured
mapping) is very different from assignment compatibility with a
multi-dimensional array of LOC (= a structured mapping!). The
latter was never intended by the standards committee, and this
point had been explicitly brought up at least once in the
development of the standard (= at the meeting in Milton Keynes).
>Is anyone keeping track of issues that should be addressed for the
>next revision of the standard?
It can be helpful to add some clarifying notes to the standard if
questions come up repeatedly, but I would certainly not suggest
any change to the compatibility rules.
Wolfgang Redtenbacher