Am 14.01.2019 um 18:15 schrieb William F Pokorny:

> Suppose my question was too whether we should consider the 3.7/3.8 
> behavior broken - you seem to be saying it was.

Let's put it this way: Going by the reference docs on numeric 
expressions - specifically FLOAT_LITERAL - the v3.7 behaviour would have 
to be considered broken, unless interpreting the syntax in a 
self-inconsistent manner.

The key question is under what circumstances a sequence of characters 
that matches the production rules of FLOAT_LITERAL, followed by some 
other character that does not fit in, constitutes a broken 
FLOAT_LITERAL, as opposed to a valid FLOAT_LITERAL token immediately 
followed by the next token.

The v3.6 behaviour can easily be interpreted as consistently treating 
such cases as valid, but erroneously implementing MANTISSA as:

     MANTISSA:
       DIGIT... [DECIMAL_POINT | [DIGIT2...] |
       DECIMAL_POINT DIGIT2...
     DIGIT2:
       DIGIT | DECIMAL_POINT

The v3.7 behaviour must be interpreted as treating such cases as broken 
if the non-matching character is a dot, but valid if it is any other 
character. That's a pretty arbitrary distinction.

The (new) v3.8 behaviour consistently treats all such cases as valid 
again, while implementing MANTISSA as documented.


> Folks can again cause parsing to separate values by using extra decimal 
> points in numeric strings. Has me wondering what might happen with typos 
> like 1..2 (not tried it).

That would have to be `1.` followed by `.2`.

> Or where we specify lists of values separated 
> by commas or not. Can the latter get scrambled in ways that are confusing?

Dots don't constitute valid infix or postfix operators in numeric 
expressions, so there's no ambiguity there.

Post a reply to this message