Jonathan Nieder's spark-precedence fix.

Jonathan Nieder's spark-precedence fix.

From jrnieder@hotmail.com  Fri Feb 25 11:00:42 2000
Date: Fri, 25 Feb 2000 21:21:03 -0800
From: Jonathan Nieder <jrnieder@hotmail.com>
X-Mailer: Mozilla 4.7 [en] (Win95; I)
To: esr@thyrsus.com
Subject: Intercal Bugfix

can be fixed quite easily (in code changes; not in that search for
the problem, though).  I'm not sure about side effects of my
solution.  It's not very well-tested.  But, the following program
compiles and does the right thing:

PLEASE ,1 <- #1 BY #1
DO ,1 SUB #1 #1 <- #0
DO WRITE OUT ,1 SUB #1 '#1'

So, it must fix the bug.  Here's the deal.  As bison parses that
third line, it eventually ends up with an unambig on the stack
and a spark in look-ahead.  It wants to know whether it should
"reduce" the unambig to a sublist1 or to continue parsing and
hope for a unambig followed by a new sublist1.  This particular
reduction has the prescedence of the (fake) token HIGHPREC.
HIGHPREC, in this particular grammar, has the highest prescedence
possible.  Since it has higher prescedence than the look-ahead
token, bison reduces, and it is straightforward from there to
parse the DO WRITE OUT ,1 SUB #1 as a command.  It then goes
on the parse the new "command" after it, and it can't even
find a DO to make into a "please".  Since programs can only
be lists of commands, it of course signals an error.

So, to fix it, simply switch the command (on line 103 of ick.y)
        %nonassoc HIGHPREC
with the command (on line 102)
        %nonassoc EARS SPARK

So, change
        %nonassoc EARS SPARK
        %nonassoc HIGHPREC
to
        %nonassoc HIGHPREC
        %nonassoc EARS SPARK

Then recompile and enjoy a new ick that has THAT problem fixed...
It's such a trivial change that I decided not to include a contextual
diff.

Hope this helps INTERCAL to suck in even more programmers' time...