Re: Draft: open issues around '?' use.

On Mon, 25 Oct 2004 02:35:37 -0700 (PDT), Dirk-Willem van Gulik <dirkx@webweaving.org> wrote:

<snip/> ...

I find your description of the problems as evidence to consider a change.

> With respect to the '?' issue; we therefore propose the following
> 
> ->	Investigate if it is possible to change/tighten the syntax to
> 	allow the engine to distinguish between a VAR and QNAME without
> 	needing the ? prefix.

As far as I know, that is possible.  QNames must have a : in them, all
other names could be variable names.  However, that would not make
them stand out in the syntax - which is useful for reading them

> -> 	Replace the '?' by a '$' or '_' or at the very least allow the use
> 	of a '$' or '_' as a synomym for the '?'.

I could support either replacing ? with $ or allowing both.  My
slight preference is for replacing ? with $, neutral to negative on
having both.

>  	Should the '$' or '_' not be acceptable; the = and # may be
> 	alternatives.

-1 to those; don't say 'variable' to me.

> 	Though the $ may confuse in, say perl, we've not found *DBC and
> 	other API's in combinations with languages where the $ is used as
> 	variable prefix where it caused problems. As in this case
> 	escaping DOES help; as it is a language level escape. e.g. the
> 	typical pattern is:
> 
> 		$foo = 'bar';
> 		$sparql1 = ' ... $foo, ..';
> 		$sparql2 = "...\$foo ...';
> 
> 	(note that my vim syntax colouring does get it wrong :-) and
> 	unlike SQL escaping each language is consistent in its own
> 	escaping options by nessecity.
> 
>  	As to other choises we'd rather avoid the likes of *+-^|& due to
> 	their use in mathematics; but have only found one example
> 	of a precompiler (DB2) which actually looks at them (the || and
> 	&&).
> 
>  	We'd strongly would like to avoid the . and : as these also
>  	have special placeholder/abbreviate semantics trapped by
>  	a few precompilers and *DBC interfaces.

You mean .foo for a variable and :foo?  -1 to both of those as both of those
are already overloaded several times in RDQL, SPARQL and nearby
syntaxes such as N3.

Dave

Received on Monday, 25 October 2004 13:55:15 UTC