Re: Minor Syntax issues

On Fri, Feb 11, 2005 at 09:02:01 +0000, Andy Seaborne wrote:
> 
> This is about tuning the current syntax, post-WD2 publication, not 
> redesigning the whole thing.
> 
> 1/ Bound
> 
> This is special because it tests the variable, not the value.  It's the only
> case where this happens.
> 
> The suggestion (PatH) was to make this different.  In other programming 
> languages, there is just a plain function like many other library 
> functions. It returns a value (a boolean) like any other function.
> 
> Options:
> 1a/ BOUND(?x)   -- as the current grammar
> 1b/ BOUND[?x]   --  different grouping
> 
> Anything with a colon in it will look like a qname.
> 
> BOUND ?x is dangerous as it does not express the tight binding nature of
> this operator: "BOUND ?x && ?y" is strange.

There is a precident, that is what perl does. Not that I'm holding up perl
as a model of clarity :)
 
> I prefer "BOUND(?x)" -- leave as is.

I have a mild preference for BOUND ?x, but BOUND(?x) is fine too.

> BOUND[] as a one-off is over doing it.
> 
> 2/ AND
> 
> AND is a special keyword that starts constraints (SUCH THAT would be better
> but its two words).  Currently in the grammar it is required because ?x-?y 
> is unclear : can be "?x binary minus ?y" or two expressions "?x" then 
> "unary minus ?y"
> 
> Proposal: use [] to mark constraints (see below).

I dont like this very much. [] has lots of uses in syntax and programming
langages, but none of them relate to contraints in my experience.

> 3/ OPTIONALS
> 
> There are two syntactic forms "OPTIONAL" and "[]"
> 
> Proposal: just the OPTIONAL form, freeing up [] for constraints.

I have no proboem with using the OPTIONAL keyword instead of [].

> 4/ Functions , casting and specials.
>     &ex:foo() , xsd:byte(23) , isBlank(?x)
> 
> These have different aspects:
> 
> Functions act on values.  Currently, they are only filters (boolean valued).
> 
> The specials (isURI and friends) act on graph elements, not the individuals
> represented by those elements.  The could be functions if we define their 
> values - that would require a set of functions that all implementations had 
> to have.  At the moment, the function mechanism is an extension point and 
> an implementation can choose not to provide it at all.
> 
> Casting is like a function but it returns a value in a constrained way (no
> assignment to variables, fixed set of casts) and the return is typed.

We dont have assignment, so the distinction is moot.
 
> A concern I have with general functions (ones that return any value,
> especially if they can assign to variables)) is that we getting into a
> second computational system that needs a lot of thinking about, not in 
> technical terms but in scope and appropriateness terms.
> 
> The obvious simplification is to use the same syntax of functions and casts,
> make functions value-returning then provide a standard set of functions for
> the casts.  The specials like isURI can be functions.

I like that. Fewer syntatic forms is good.
 
> [Not sure about typing of function returns which might be lost in such a
> scheme.  Does it hurt optimization?]

I dont think so. Maybe makes it a bit harder, but its allready seriously
hard.
 
> 5/ LOAD => WITH
> 
> The word "LOAD" suggests, to some people, a permanent change to the 
> database which is a wrong implication.  DaveB suggested changing the word 
> to "WITH". I have done this change (rq23 and the tests).

OK by me.
 
> 6/ Clause order
> 
> The current order is:
> 
> BASE
> PREFIX
> SELECT
> WITH
> FROM
> WHERE
> LIMIT
> 
> which is a mixed style.  It would make sense to have WITH and FROM before 
> SELECT (declarations first) and have LIMIT before WHERE (modifier to 
> SELECT).  It has confused some RDQL users that FROM comes after SELECT.

>From before SELECT seems fine, its the other way round in SQL, but the SQL
FROM is very different. OTOH I prefer LIMIT at the end, as its parallel
with SQL is direct.

Incidentally, I dont think of LIMIT as modifying SELECT, I think of it as
modyfying the result set.

- Steve

Received on Sunday, 13 February 2005 10:56:31 UTC