On 1/14/19 1:41 PM, clipka wrote:
> 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.

Thanks for the detail. I've been playing with variations for the last 
hour or so and created some new parser test cases in my collection to 
track this change. While 1..2 gets treated as two numbers .1..2 and the 
like do not - so even the exposure to period over comma typos is small.

Not picked up anything new and have switched over to your latest code - 
it fixed all the recursive return fails I had. Should finish up tomorrow 
sometime and will post again only if something new turns up.

For the record I'm only checking the parser with my tests. I'm not doing 
image to image compares. Image compares will happen over time after I 
rebase my branches onto the current master head and continue other 
efforts.

Bill P.

Post a reply to this message