[nem-en] Increment and decrement operators

[Kamil Skalski]

2006/2/26, Michal Moskal <michal.moskal at gmail.com>:
> On 2/26/06, Kamil Skalski <kamil.skalski at gmail.com> wrote:
> > On the other hand, having ++ behave as expected by many would be very
> > nice - maybe we should have a special case for ++ and -- so that they
> > will return void in general, but if expected some value, they will
> > return it...
>
> This shouldn't be very hard to do, as the warning is issued in T2, it
> should be easy to get rid of it.

Well, my original thought was that ++ returns void, but if something
is *expected* then it choose to return something :)  But this would be
probably hard to do - after macro has expanded and the result is
typed, it is much harder to make it return a value.

So maybe the better approach would be to just disable the warning in
case of ++ and -- operators.
This would of course spoil the cases, where ncc is not very good at
merging branches (http://nemerle.org/bugs/view.php?id=460), but in
general it would work.
Also it means that code like
def f () {
  x++
}

would now mean void -> int  function instead of current void -> void


> Do you have any patches for +++?

You mean

macro @+++ (expr) {
   <[ def x = $expr;
       $expr = $expr + 1;
       x
   ]>
}

(ok, this need to use the special construct for not computing
expression twice, which we have for ++)

>
> I just wonder if it won't screw up things like:
>
> if (...)
>   i++
> else
>   ()
>
>

t.n:12:4:12:6: error: expected int-, got void in computation branch:
int is not a subtype of void [simple require]
t.n:12:4:12:6: hint: this means two branches of ``if'' or ``match''
have different types

for
--------------------------
mutable i = 0;

def f () {
  i = i + 1;
  i
}

if (true)
   f()
else
   ()
-------------------

Also, it is hard to distinguish in our current parser if we have  ++i or i++

--
Kamil Skalski
http://nazgul.omega.pl