[comp.lang.modula2] "FOR loop" control var. and limit expression types

harv@ksuvax1.BITNET (Harvard Townsend) (04/08/88)

I am interested in people's opinions on the restrictions of compatibility
between a FOR loop control variable and the types of limit expressions.
On page 158, section 9.8, of Wirth's 3rd, corrected ed. of Programming in
Modula-2, he states that the limit expressions (he calls them the starting
value and limit) must be "compatible" (as distinct from "assignment
compatible") with the control variable.  On page 65, he says

        "Two types are are said to be compatible, if they are declared
        as equal or satisfy certain compatibility rules to be discussed
        subsequently.  An important case of exceptional compatibility
        are the types INTEGER and CARDINAL.  Hence, the assignment
        i := c is admissible."

Finally, on page 148, section 6.3, he says

        "A type T1 is said to be compatible with a type T0, if it is
        declared either as T1 = T0 or as a subrange of T0, or if T0 is
        a subrange of T1, or if T0 and T1 are both subranges of the
        same (base) type."

At least one text book on Modula-2 says that the limit expressions must
be "assignment compatible" with the control variable (see p. 103 of
"Modula-2 Discipline & Design" by Arthur Sale, Addison-Wesley, 1986).
The issue arose during my work to port the 1-pass MC68K native code ETH
compiler.  The parser appears to define yet another type of compatibility.
It allows the starting value to be truely "assignment compatible".
However, the limit must be either 1) equal type with the control variable
or, 2) a CARDINAL constant < MAX(INTEGER) when the control variable is an
INTEGER type.  In other words, it does NOT allow a CARDINAL variable limit
with an INTEGER control variable, a CARDINAL constant limit with a CARDINAL
control variable, a CARDINAL variable limit with a CARDINAL control
variable, etc.  I intend to change it to allow a free mix of CARDINAL
and INTEGER control variable and limit expressions, but I wanted to get
others opinions and interpretations first.  Have the standardization
committees dealt with this?
______________________________________
Harvard Townsend, Systems Manager
Dept. of Computing & Information Sciences
Kansas State University, Manhattan, KS 66506   (913)532-6350
CSNET:  harv@cis.ksu.edu -or- harv@kansas-state.csnet
BITNET: harv@ksuvax1.bitnet -or- harv%ksuvax1.bitnet@cunyvm.cuny.edu
UUCP:   ihnp4!wnuxa!ksuvax1!harv -or- ...!psuvax1!ksuvax1.bitnet!harv
AT&T Mail: attmail!htownsend

randy@oresoft.UUCP (Randy Bush) (04/11/88)

It would seem that in

	FOR i := j TO k BY l

As j is being assigned to i, they should be assignment compatible.

As k is being compared to i, they should be comparison (eg. expression)
compatible.

As l is being added to i, they should be expression compatible.

Am I missing something here?
-- 
randy@oresoft.uu.net                                          FidoNet:1:105/6.6
randy%oresoft.uu.net@relay.cs.net                             +1 (503) 245-2202
{ ..!mcvax!uunet, ..!textronix, ..!sun!nosun } !oresoft!randy

mikec@tekgvs.GVS.TEK.COM (Micheal Cranford) (04/14/88)

Harvard, you resently stated :

"I am interested in people's opinions on the restrictions of compatibility
between a FOR loop control variable and the types of limit expressions."
............................[deleted]..................................
"The issue arose during my work to port the 1-pass MC68K native code ETH
compiler."
............................[deleted]..................................
"I intend to change it to allow a free mix of CARDINAL and INTEGER control
variable and limit expressions, but I wanted to get others opinions and
interpretations first."
............................[deleted]..................................


  I have nothing useful to offer here except the painfully obvious `it seems
the parser is even more confused than Wirth's definition of compatibility.'.
Your proposed solution sounds just fine to me (follows Wirth's `INTEGER :=
CARDINAL assignment rules).

  So why am I bothering you?  I am interested in the "1-pass MC68K native code
ETH compiler".  I am currently using an optimizing MC68K native code Modula2
compiler that has a number of problems.

  1. A number of irritating `bugs'.
  2. No compiler support available due to (3).
  3. Original authors had a fight and went separate ways.
  4. Incredibly slow to optimize (over 1/2 hour on a 1K line program).
  5. No compiler source available (they are still fighting over `ownership').
  6. Some of the optimization is apparently for another microprocessor (i.e.
   instead of using BSET (BCLR) it uses `ROR, OR#1 (AND#FE), ROL' with sets!).
  7. Etc......

  Some Modula2 compilers that I currently have source to are :

  1. 4 pass for ETH Lilith (generates `M' code - currently unused)
  2. 4 pass for VMS VAX (derived from ETH multipass - currently unused)
  3. 5 pass for MC68000 (derived from ETH 5 pass PDP11 - currently unused)
  4. 1 (or 2?) pass for MC68000 (locally generated, little documentation,
   author departed over 2 years ago, has been used - currently unused).

  I just received #4 (above) and have started checking to see how involved it
will be to make it operational (I don't know about optimizations, etc).  My
best choice may be to look elsewhere for a compiler (with source available).

  Some standard questions for you :

    1. Is the "1-pass MC68K native code ETH compiler" `public domain'?
    2. IF `yes' then can you send me a copy, otherwise, how much $?
    3. What optimizations does it perform?  Reliability?  Bugs?

  Standard answers (check one or more) :

 [] 1. No.
 [] 2. Yes.
 [] 3. Maybe.
 [] 4. Go away.
 [] 5. Don't bother me.
 [] 6. Other ... please specify in reply

                                     Micheal Cranford