Re: Lee's feature proposal

On 5 May 2009, at 14:23, Axel Polleres wrote:
> I think the ASK subquery in FILTER solution is more intuitive than the
> OPTIONAL/!BOUND or OPTIONAL/boundchecker.ttl
> I personally would be perfectly fine with moving it there.
> Now my question should rather be: If we had ASK subqueries in  
> FILTERs, would we still need some extra surface syntax UNSAID or  
> isn't FILTER( !ASK ) sufficient alone?

Personally, I don't like having multiple syntaxes for the same thing.  
It's one of the things that makes SQL difficult to learn (and debug),  
as people are often taught the "," join syntax first, then they hit  
the JOIN syntax when they're taught left joins.

So, I'd prefer to have FILTER(!ASK ...) and not UNSAID.

You could argue for UNSAID and not subqueries in FILTER, but I can  
think of other uses for FILTER(ASK). Also, I may have got the wrong  
end of the stick, but it sounds like UNSAID { ... } would have  
unexpected scope behaviour from what Andy S. said in email when we  
discussed it briefly.

> Indeed, in order to avoid that, I am trying to identify concrete  
> parts of the currently discussed features that could be subsumed here.
> I think before we agree about the feature "surface syntax" we should  
> have these "sub-features" clearly identified and prioritised, that  
> is where I am trying to get.
>
> At the moment I think we have the following candidates, seen from  
> the discussions and from the feature description:
>
> - Surface syntax for Negation (translated into subqueries)
> - Surface syntax for LimitPerReseource (translated into subqueries)
> - Surface syntax for ProjectExpressions (translated into assignments)
> - Surface Syntax for disjunctions in FILTERs (IN ( ... ), BETWEEN  )
> - Surface Syntax for paths (operators for concatentation "/", reverse
>   path "^" and alternation "|")
> - Surface Syntax for expression lists (commas in SELECT ?a, ?b, ?c)

Some of these are sensitive to what we standardise, eg. "Surface  
syntax for ProjectExpressions (translated into assignments)" would  
make more sense as "Surface syntax for assignments (translated into  
ProjectExpressions)" - though that said, I still think an assignment  
syntax is a fantastically bad idea, even if it's just a macro ontop of  
a projection.

> If we opt for Surface syntax we should agree on whether and which of  
> these we want. Are there more candidates I forgot here?

Surely it depends on how far we get down the list of required/optional  
features, and what the syntax looks like.

If the subquery syntax is sufficiently horrible then we may want an  
UNSAID or LimitPerResource type notation, but if it's reasonable  
enough then there's no need. There is an educational cost to sugar, as  
above, which is all too easy to forget when you spend a lot of time  
with the language, so lets not decide now that were going to add sugar  
that we may not need after all.

- Steve

Received on Tuesday, 5 May 2009 13:43:55 UTC