Re: INC/DEC behaviour

[acken@informatik.uni-kl.de]

> From: Guy Laden <guy@math.tau.ac.il>
> Date: Tue, 26 Aug 1997 00:31:32 +0300 (GMT+0300)
> 
> > I would like to see the INC/DEC type compatibility exactly the same
> > as the statements:
> > 
> >       i:=i+j   or i:=i-j
> 
> I think the issue is: which of the two semantics maps more directly 
> and transparently to the machine-level.
> IMO, INC/DEC as mere shortcuts for the above assigments wouldn't have 
> made it into Oberon. It seems to me they were kept for efficiency 
> and because they correspond directly to machine-level instruction.
> So we should try and understand whether the ETH version is still, in
> general, more efficient to implement on todays CPU's and if so, thats 
> the way to go.

Such considerations apply to SYSTEM functions, but not to the standard
language level.  The report doesn't give any type rules for INC/DEC,
it simply states that INC(v,x) is equivalent to v:=v+x.

Of course this isn't true if `v' is a complex designator with
side-effects.  In this case INC(v,x) only evaluates `v' once, while
`v:=v+x' would do it twice.  Seen this way INC/DEC are more than just
shortcuts.  Efficiency isn't really an issue here since a type
conversion to a larger type is a no-op on all current machines: all
calculations are done in machine words (32 or 64 bit) anyway.

The current implementation of INC is this:
INC(v,x) is valid if
a) x is a constant and the type of v includes the value of x, or
b) x is an expression and has the same type as v.

I don't like the distinction between constants and all other
expressions here.  Especially since you can't derive this special rule
from the language report.

-- mva