[BUG] compiler bug regarding "=>" in loop

[oldk1331]

My code for 'concat!' in r2591 is correct, but it runs
incorrectly, because there is a compiler bug.

Specifically, this bug happens when there is a single "=>"
expression inside a loop.  This bug causes the loop to only
run once.

After some debugging, I'm not sure if this bug happens in
"incExitLevel" in "parseIf".

Example:

)abbrev package TEST Test
Test() : Exp == Imp where
  Exp == with
    test1 : List Integer -> Integer
  Imp == add
    test1 l ==
      n := 0
      while not empty? l repeat
        -- 1+1 -- uncomment this line to workaround this bug
        first l = 3 =>
          n := n + 1
          l := rest l
      n

===== -- should return 4 instead of 1
(1) -> test1 [3,3,3,3]

   (1)  1

[Waldek Hebisch]

Well, clearly what compiler generates is different than "obvious"
meaning of the code. But in general issue is somewhat tricky:
'=>' is supposed to exit current block. In FriCAS single
instruction does _not_ form a block... ATM I would reccomend
to use 'if' in such situations.

--
Waldek Hebisch

[Ralf Hemmecke]

Hi Waldek,

> Well, clearly what compiler generates is different than "obvious"
> meaning of the code. But in general issue is somewhat tricky: '=>'
> is supposed to exit current block. In FriCAS single instruction does
> _not_ form a block... ATM I would reccomend to use 'if' in such
> situations.

You suggest some workaround, but you did not say whether or not you
agree that this should be considered a bug.

If something that comes after "repeat" should not always be considered
as a "block", then I think that is confusing. Maybe it doesn't appear
too often, that => is a single statement after a "repeat", but if it
does, it should be compiled in the "obvious" meaning.

Ralf

[Waldek Hebisch]

Consider:

...
if x > 0 then
y > 0 => 0
...

Should this exit larger block or not? Arguably, this code could
be written in clearer way, but the same applies to 'repeat'
case ('if' is clearer).

Now, I consider it a bug in Spad language that it is not clear
enough what should happen in such cases. And I probably would
prefer spec saying that in cases above single instruction
is in fact a block. But that is larger issue that needs to
be worked out, in particular we should look at conseqences
in various cases. And only having firm language spec we
should hack compiler to conform to the spec. Of course,
if proposed spec is hard to implement, then there is red
sign that maybe it is too complicated. But spec should
go first...

--
Waldek Hebisch