Weird behaviour after syntax error

[GoogleCodeExporter]

What steps will reproduce the problem?

> let a = [[1, 1], [1, 2], [2, 5], [3, 6]];
> [[x, y] | [x, y] = a];
[[1,1],[1,2],[2,5],[3,6]]
> [x, y] | [x, y] = a];
<stdin>, line 3: syntax error, unexpected ']', expecting ';'
> [[x, y] | [x, y] = a];
warning: rule never reduced: [x,y] = a;
[[3,6],[2,5],[1,2],[1,1],[1,1],[1,2],[2,5],[3,6]]
> 

What is the expected output? What do you see instead?
I would expect [[1,1],[1,2],[2,5],[3,6]] as a result again.

Please use labels and text to provide additional information.
Pure 0.51, llvm-2.9, MinGW GCC 4.6.1.

Original issue reported on code.google.com by jiri.spitz@gmail.com on 2 Jan 2012 at 12:56

[GoogleCodeExporter]

That looks weird indeed, but the explanation is simple. After seeing '[x, y] | 
[x, y] = a', the parser has read (and reduced) a valid rule, before it even 
finds that the following symbol ']' isn't the terminator that it looks for. At 
this point, syntax error recovery kicks in so that the parser skips over the 
invalid ']' character to find the terminator symbol ';' that it was looking for.

So at this point the rule '[x, y] = a' has already been added to the program 
(twice in fact, because of the '[x, y] |' prefix). You can verify this:

> [x, y] | [x, y] = a];
<stdin>, line 1: syntax error, unexpected ']', expecting ';'
> show :
infixr 1900 :;
[x,y] = a;
[x,y] = a;
> [1,2];
warning: rule never reduced: [x,y] = a;
a

The second rule is redundant, which explains the warning message. The other 
weird output is simply a consequence of the remaining rule (which maps any 
newly constructed two-element list to 'a'), if you have 'a' defined the way you 
did, considering the way that 'map' is defined in the standard library.

To work around the problem in interactive mode, all you have to do is clear the 
unwanted rules for the list constructor:

> clear :
> [1,2];
[1,2]

I agree that the effects of the parser's limitations are a bit bewildering in 
this case, and I will see whether I can massage the bison grammar so that this 
specific kind of error can be caught a bit earlier. But it's an unfortunate 
consequence of Pure's terse syntax that some syntax errors can only be caught 
after a seemingly valid construct has already been parsed and processed, 
sometimes with surprising consequences. :)

Original comment by aggraef@gmail.com on 5 Jan 2012 at 1:15

• Changed state: Accepted

[GoogleCodeExporter]

Should be fixed in rev. 29d370e1c5c4. Better?

Original comment by aggraef@gmail.com on 5 Jan 2012 at 1:47

• Changed state: Fixed

[GoogleCodeExporter]

Much better, thanks.

Original comment by jiri.spitz@gmail.com on 5 Jan 2012 at 2:16

[GoogleCodeExporter]

Original comment by aggraef@gmail.com on 5 Jan 2012 at 3:25

• Changed state: Verified