Re: Possible grammar bug with PrimaryExpression and ArgList

Dave Beckett wrote:
> On Wed, 2005-08-10 at 17:52 +0100, Seaborne, Andy wrote:
> 
>>Dave Beckett wrote:
>>
>>>I was wondering what changed as in the current rq23 ArgList is optional
>>>for function calls and this seemed like a syntax change.  This took a
>>>little digging into the record so I'm recording what I found.
>>
>>Thanks for doing that.  Something seems to have gone amiss.
>>
>>
>>>I finally tracked it down to rq23 between CVS 1.451 and 1.452:
>>>[[
>>>Revision 1.452  2005/08/04 10:57:36  aseaborne
>>>+ Added "_" to start of variable names
>>>~ Tidied up by intrpducing NCCHAR1p and making NCCHAR1 be NCCHAR1p | '_'
>>>]]
>>>
>>>(for reference the last WD was around 1.432).
>>>
>>>This change seems to do a bit more than that:
>>>* FunctionCall is removed from Constraint
>>
>>v1.463 says:
>>
>>[25] Constraint ::= 'FILTER' ( BrackettedExpression | BuiltInCall | FunctionCall )
>>[55] FunctionCall ::= IRIref ArgList
>>
>>[56] ArgList ::= ( '(' ')' | '(' Expression ( ',' Expression )* ')' )
>>
>>The argument list is not optional for a function call at this point.
>>
>>The formatting for BuiltInCall could be better.
>>
>>Eric had some suggestions from using flex/bison related to the double meaning of 
>>() as an empty argument list and as rdf:nil.  This was addressed by inlining 
>>explicitly the () cases, not having an explicit rule suggesting a unique 
>>tokenization.
> 
> 
> That would have been helpful to have in the changes.
> 
> 
>>>* ConstructTemplate uses ConstructTriples for it's inner content
>>
>>I thought this had happened a while ago - must have had a synchronization error.
>>
>>In support of yacc, Eric made various suggestions that made it easier for him 
>>(and I presumed all bison/flex LALR(1) setups) as well as made the grammar more 
>>LL(1).
>>
>>
>>>* ConstructTriples added with content from above.
>>>* GraphTerm inlines the RDFTerm token and adds '(' ')' (empty
>>>collection)
> 
> 
> For what it's worth, I don't do empty ()s either way before or after
> this change, but check it elsewhere.
> 
> 
>>Removed a rule that was used only once.  Again, sometime ago and there has been 
>>a sync error.  Apologies.
>>
>>
>>>* BuiltInCall renamed from CallExpression and FunctionCall is removed as
>>>an option.
>>>* PrimaryExpression:
>>>    CallExpression renamed to BuiltInCall
>>>    Adds IRIref ArgList?
>>
>>Result of the discussion about resolving the ambiguity of qname vs function.
>>"IRIref ArgList?" covers both cases.
>>
>>Example:
>>
>>   FILTER ( ?x = ex:p )   # ex:p is a qname
>>
>>   FILTER ( ?x = ex:f(?a, ?b) )   # ex:f is a function call
>>
>>http://www.w3.org/2005/06/14-dawg-irc
>>
>>Worrying mistake somewhere after that.
> 
> 
> That makes sense now.  So this would have been a lot clearer to me if it
> had read IRIref | FunctionCall  as they are really two entirely
> different things: qname, functioncall.  I'd hope you would change this.

I'd like to.

I believe, for bison, it would be covered by the lookahead rule.

   http://dinosaur.compilertools.net/bison/bison_8.html#SEC69

but I'd be grateful if someone would confirm this.

 Andy

> 
>   
> 
>>>    Adds RDFLiteral | NumericLiteral | BooleanLiteral | BlankNode | Var
>>>
>>>Most of that is tidying or reasonable change but the addition that is
>>>the problem is IRIref ArgList? which is not the same as FunctionCall:
>>>IRIref ArgList which I'm guessing it was intended to be.
>>>
>>>If you want a test:
>>>
>>>PREFIX my: <http://example.org/>
>>>SELECT *
>>>WHERE {
>>>  ?s ?p ?o .
>>>  FILTER my:function
>>>}
>>>
>>>is legal according to my reading of rq23 whereas it used to be illegal.
>>
>>FILTER with no brackets follows rule 55 which does not allow omission of the 
>>argument list.
> 
> 
> My example was in error; it should have been
>   FILTER (my:function)
> 
> However as you've described now, I see it does have a meaning.  I'm not
> sure quite what to propose here with tests.   Maybe make tests with both
> FILTER (my:function()) which is the function, and FILTER (my:function)
> as a qname evaluated as an EBV (always true?) explaining exactly what
> they are doing.  Somebody might get caught out if they left out the ()s
> as some languages let you do that.
> 
> 
>>>I assume the additional '?' is a mistake or have I missed something?
>>>Maybe just using FunctionCall instead would be easier.
>>
>>At that point it does. It's the other way of getting there that has the ambiguity.
>>
>>
>>>Dave
>>
>>
>> Again, thanks
>> Andy
>>
>>
> 
> 
> Dave
> 
>

Received on Thursday, 11 August 2005 12:48:45 UTC