POV-Ray : Newsgroups : povray.beta-test : POV-Ray v3.8.0-alpha.10011104 : Re: POV-Ray v3.8.0-alpha.10011104 Server Time
28 Nov 2023 13:42:18 EST (-0500)
  Re: POV-Ray v3.8.0-alpha.10011104  
From: clipka
Date: 14 Jan 2019 13:41:32
Message: <5c3cd7dc$1@news.povray.org>
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:

       DIGIT... [DECIMAL_POINT | [DIGIT2...] |

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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.