Re: Possible grammar bug with PrimaryExpression and ArgList

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.

  
> 
> >     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 09:37:47 UTC