parser: fix bad precedence of @ token.

Whereas @a..@b parses and transforms to (rcons @a @a),
@(a)..@(a) goes to @(rcons a @(a)).

* parser.l (grammar): Under 248 compatibility or lower, the @
character now produces the OLD_AT token. Otherwise it produces
the '@' character, as before.

* parser.y (OLD_AT): New token replaces the '@' at the old
low precedence position. '@' is now at the highest precedence,
together with OLD_DOTDOT.  (We don't care about interactions
between '@' and OLD_DOTDOT, because OLD_DOTDOT only exists in
185 compatibility, in which '@' is OLD_AT).
(meta): The two rules have to be unfortunately duplicated for
OLD_AT, since there is no BNF OR operator in Yacc.

* txr.1: Compat note added.

* lex.yy.c.shipped: Updated.

* y.tab.c.shipped, y.tab.h.shipped: Likewise.

1 files changed, 23 insertions, 1 deletions

diff --git a/txr.1 b/txr.1
index 4ca78509..b42cb75c 100644
--- a/txr.1
+++ b/txr.1
@@ -76996,7 +76996,29 @@ function defaulted to using
 equality for searching the hash table for matching values rather than the
 current
 .codn equal .
-A compatibility value of 248 or lower restores the behavior.
+Also, until 248, the
+.code @
+token for denoting meta-expressions was treated with a low precedence
+relative to the range dot
+.code ..
+token. This led to strange results, such as
+.code @(a)..@(b)
+parsing in a way equivalent to
+.code "@(rcons a @(b))"
+rather than
+.codn "(rcons @(a) @(b))" .
+Not is that undesirable due to the lack of symmetry, it's also
+inconsistent with
+.code "@a..@b"
+denoting
+.codn "(rcons @a @b)" .
+The latter is because in that case the
+.code @
+is handled as part of the symbol token as a token, and not as a separate operator.
+A compatibility value of 248 or lower restores the above old behaviors of
+.code @
+and
+.codn hash-revget .
 .IP 244
 Until \*(TX 244, the
 .code env-hash