W3C home > Mailing lists > Public > public-qt-comments@w3.org > April 2004

Re: [XQuery] semicolon separator after declarations

From: Xavier Franc <xfranc@online.fr>
Date: Mon, 26 Apr 2004 18:53:33 +0200
Message-ID: <408D3E8D.2040804@online.fr>
To: public-qt-comments@w3.org

Right, optional semicolons is not the best possible idea.
I did it in Qizx only to keep compatibility with
former syntax.

In fact, semicolons should be *terminators* on simple declarations,
and not separators.

>Incidentally, I prefer a simple rule ("a declaration ends with a 
>semicolon") to any rule that has exceptions ("a declaration ends with a 
>semicolon except if it is a function declaration...)

Yet this is exactly how it is in mainstream languages like
Java, Javascript, C, C++, C#, to name a few...
Why wouldn't  XQuery adopt a usual approach, 
rather than inventing a new one?

>1. Semicolons at the end of declarations simplify parsing of the 
>language - not only for recognition, but also for error detection, 
>making it possible to give good error messages.
This is hardly a good reason for introducing them.
Easiness-of-implementation considerations should not
influence the design of a language, IMHO.

Jonathan Robie wrote:

>> -  make optional the separator ';' between prolog declarations.
>> (unless this creates a real lexical issue but it doesn't seem to
>> be the case.)
>> Though the semicolon can improve readability in some
>> cases,  it is both heavy, ugly and unnecessary
>> after functions or variable initializations.
>To me, making them optional is the worst possible approach - XQuery 
>processors would still need to be able to parse the language with or 
>without the semicolons. If we were to do that, it would be better to 
>simply remove the semicolons so everybody writes queries with the same 
>But the semicolons do make error reporting easier, and simplify parsing 
>of the language. More importantly, they also make it more likely that 
>future versions of XQuery will have the flexibility they need to extend 
>the language.
Received on Monday, 26 April 2004 12:55:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:56:56 UTC