INC() broken?

[diegosardina]

MODULE test;
  VAR
    int,int2  : INTEGER;

BEGIN
  int  := 1234;
  int2 := 0;
  INC(int2, ASH(int,24));
END test.

INC seems to be broken with expressions that contain ASH(). This code compiles well on oxford oberon-2 and other oberon compilers.

$ voc -m test.mod
test.mod  compiling test.

   8:   INC(int2, ASH(int,24));
                            ^
    pos   102  err 111  operand inapplicable to (this) function

Module compilation failed.

[dcwbrown]

The Oberon 2 spec defines ASH in section 10.3 Predeclared procedures. It's result type is fixed as LONGINT. Since int2 is an INTEGER, it's not large enough to hold the result.

(Maybe it would be reasonable to be less fussy, but I believe that's the fundamental reason for this error.)

Does the Oxford Oberon2 spec have anything to say about the result type of ASH or the parameter types of INC that allow this?

[norayr]

this compiles:

MODULE test;
  VAR
    int,int2  : INTEGER;

BEGIN
  int  := 1234;
  int2 := 0;
  INC(int2, SHORT(ASH(int,24)));
END test.

report states, that the output type of ASH is LONGINT, and the argument types of INC(v, n) should be integer types. LONGINT is also an integer type. For some reason OP2 expects INTEGER as an argument type of INC?

[norayr]

Ah, @dcwbrown is right.

MODULE test;
  VAR
    int,int2  : LONGINT;

BEGIN
  int  := 1234;
  int2 := 0;
  INC(int2, ASH(int,24));
END test.

This also compiles. The reason is int2's type.

[diegosardina]

Yes, it makes sense.

In INC(v,n) v and n are defined as integer type (that means SHORTINT, INTEGER or LONGINT), but of course expression n must have the same type of v, although the report says nothing about this and of course this is the reason why other Oberon compilers don't complain.

(Maybe it would be reasonable to be less fussy, but I believe that's the fundamental reason for this error.)

In my opinion this behaviour is correct, the semantic is the same as v := v+n; and since there is a LONGINT type in the expression, the result must be LONGINT.

By the way, I would improve error messages for Oberon specific procedures and function procedures.

[diegosardina]

expression n must have the same type of v

Uhm, that's not entirely correct, since it will exclude type inclusion. Anyway, assignment rule applies in this case.

[norayr]

can anyone suggest more understandable error message for that case?