Re: Possible grammar problem with decimal numbers

Not speaking officially...

On Tue, Apr 9, 2013 at 1:21 PM, Thomas Visel <TVisel@algebraixdata.com>wrote:

>  Gentlemen,****
>
> While verifying our implementation of Sparql, I have encountered what
> several suspected problems in the grammar.****
>
>   ****
>
> 1st Case:  The following production (in
> http://www.w3.org/TR/sparql11-query/#rUnaryExpression) permits decimal
> numbers of the following exemplary forms:  ddd.d    ddd.ddd   .ddd  .
> Decimals of the form  ddd.  are not permitted.****
>
> ** **
>
> [147] ****
>
> DECIMAL****
>
> ::= ****
>
> [0-9]* '.' [0-9]+****
>
> ** **
>
> If this was not the intended result, the right-hand side of the production
> might better read as****
>
> ** **
>
> [0-9]* '.' [0-9]+ | [0-9] '.'****
>
> ** **
>
> The original motivation might be the conflicting use of a floating number
> in the *object* position of a triple, where a fraction-free float’s
> decimal point would conflict with the triple’s closing AND ‘.’ mark.
>

It was due to a related reason. The decimal point would have been conflated
with the DOT ending the triple if the triple ended in an integer. So:

{?a :p 2.}
{?a :p 2 .}

Would have two different meanings (the first would be a floating point
object, and the second would be an integer).

I don't know what the implications of requiring a space before a triple
terminator would be (as this could be a disambiguator), but it would
certainly create incompatibilities with SPARQL 1.0 as well as Turtle and
N3, and that alone is enough to mean the WG had to continue to keep the
space optional.

The implications of leaving [147] as-is is that *FILTER [?data > 29.]* is
> not legal, a visible annoyance.****
>
> **
>

Perhaps it's annoying, but that's better than inconsistency between numbers
in expressions and those in triples.


> 2nd Case:  There is a slight inconsistency in treatment of DECIMAL (per
> above) and DOUBLEs:
>
> ** **
>
> [148] ****
>
> DOUBLE****
>
> ::= ****
>
> [0-9]+ '.' [0-9]* EXPONENT<http://www.w3.org/TR/sparql11-query/#rEXPONENT>| '.' ([0-9])+
> EXPONENT <http://www.w3.org/TR/sparql11-query/#rEXPONENT> | ([0-9])+
> EXPONENT <http://www.w3.org/TR/sparql11-query/#rEXPONENT>****
>
> ** **
>
> For single precision DECIMAL, the leading digit is optional.  For DOUBLE,
> a leading digit is mandatory.  Is there a motivation for this difference?
>

The leading digit is optional in the second forn, but not in the first.
Requiring it in the first form prevents the following from being legal:  .E2

Unlike doubles, a trailing '.' won't be mistaken as a triple terminator,
since it will always be followed by the exponent, which is why the first
form in [148] allows a trailing DOT.

Regards,
Paul Gearon