parser: fix precedence of DOTDOT.

The problem is that a.b .. c.d parses as (qref a b..c d),
which is useless and counterintuitive.

Let's fix it, but with a backward compatibility switch to give
more leeway to any hapless people out there whose code happens
to depend on this unfortunate situation.

We basically use two token numbers for the .. token:
OLD_DOTDOT, and DOTDOT. Both are wired into the grammar. In
backward compatibility mode, the lexer pumps out OLD_DOTDOT.
Otherwise DOTDOT.

* parser.l (grammar): When .. is scanned, return OLD_DOTDOT
when in compatibility with 185 or earlier. Otherwise DOTDOT.

* parser.y (OLD_DOTDOT): New terminal symbol; introduced at
the same high precedence previously occupied by DOTDOT.
(DOTDOT): Changes precedence to lower than '.' and UREFDOT.
(n_expr): Two productions added involving OLD_DOTDOT.
These are copy and paste of the existing productions involving
DOTDOT; the only difference is that OLD_DOTDOT replaces
DOTDOT.
(yybadtoken): Handle OLD_DOTDOT.

* txr.1: Compat notes added.

1 files changed, 19 insertions, 0 deletions

diff --git a/txr.1 b/txr.1
index e288d7ab..ec7ca80f 100644
--- a/txr.1
+++ b/txr.1
@@ -61407,6 +61407,25 @@ is that user code which binds custom macros to
 or
 .code sys:expr
 may be affected by 184 or lower compatibility.
+.IP 185
+A value of 185 or lower restores the old precedence of the
+double dot notation for expressing ranges, relative to the
+referencing dot. Until \*(TX 185, the expression
+.code a.b..c.d
+parsed as
+.codn "(qref a (rcons b c) d)" .
+What is worse, it parsed this way even if written as
+.codn "a.b .. c.d" .
+Starting in \*(TX 186,
+.code ..
+has a lower precedence, producing the more useful and intuitive parse
+.codn "(rcons (qref a b) (qref c d))" :
+in other words, the range with endpoints given by
+.code a.b
+and
+.codn c.d .
+
+
 .IP 183
 A value of 183 or lower restores an inconsistent behavior in the
 .code "@(bind)"