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.

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]; , 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. :)

Should be fixed in rev. 29d370e1c5c4. Better?

Much better, thanks.