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

Re: Request to remove unnecessary semicolons

From: Jonathan Robie <jonathan.robie@datadirect.com>
Date: Mon, 26 Apr 2004 09:43:08 -0400
Message-ID: <408D11EC.8070509@datadirect.com>
To: Jason Hunter <jhunter@acm.org>
Cc: public-qt-comments@w3.org

Hi Jason,

I still believe that we should keep semicolons as is, because

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.

2. Semicolons at the end of declarations give us more flexibility in 
extending the langauge. For instance, if you look at variable 
declaration syntax in the Nov 2003 WD, you will see that we had to 
require {} for the value of variables in the prolog because at the time 
we added that syntax we did not have semicolons. Before we added 
semicolons, we spent way too much time trying to devise a syntax for 
each kind declaration so that it could be parsed without semicolons - 
and that hurt the user-friendliness of the language.

3. Users get used to ending declarations with semicolons rather quickly, 
if my XQuery workshops are any indication.

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...)


Jason Hunter wrote:

> Please consider the attached a formal request from Mark Logic 
> Corporation to remove the need for semicolons.
> (Posting from a personal account rather than work account because the 
> personal acct has the most spam protection.)
> -jh-
> ------------------------------------------------------------------------
> Subject:
> Re: questionable syntax choices for XQuery
> From:
> Jason Hunter <jhunter@acm.org>
> Date:
> Wed, 21 Apr 2004 09:36:13 -0700
> To:
> Jonathan Robie <jonathan.robie@datadirect.com>
> To:
> Jonathan Robie <jonathan.robie@datadirect.com>
> CC:
> "Volkmann, Mark" <Mark.Volkmann@AGEDWARDS.com>, "'www-ql@w3.org'" 
> <www-ql@w3.org>
> Jonathan Robie wrote:
>> Volkmann, Mark wrote:
>>> I dove into learning about XQuery this weekend.  While I like what I 
>>> see, I think some questionable syntax choices have been made.  Here 
>>> are three of them.
>>> 1) Why is a semi-colon required at the end of a user-defined function 
>>> defintion?  It's clear that the end has been reached when '}' is 
>>> encountered.  I don't see how requiring a terminationg ';' makes 
>>> parsing any easier.  This is a known gotcha in C++.  I hate to see 
>>> XQuery borrow a syntax feature that is already a known issue.
>> Hi Mark,
>> XQuery does not have reserved keywords. This makes parsing more 
>> difficult in general, and we want to have a general way to make it 
>> easy for the parser to spot the end of a declaration. Therefore, all 
>> declarations, including function signatures, end with semicolons. This 
>> is easier to remember than requiring semicolons for some declarations 
>> but not for others. It's a bit redundant, but you do get used to it.
> Which is more important, making parser writing easier or making coding 
> XQuery easier?  I believe coding XQuery, because we're going to have 
> just some dozen XQuery parsers in the world but thousands or tens of 
> thousands of XQuery coders.  The easier we make the language, the more 
> coders we'll have.
> Empirical evidence shows that the May 2003 syntax is readily parsable (I 
> can point to you engines that parse it without ambiguity) so why push an 
> unnecessarily nastier syntax down to the thousands of future XQuery coders?
> I recognize it's tricky in a WG consisting almost entirely of 
> implementors (it was 100% vendors in the meeting I attended) to think of 
> what's best for XQuery coders.  The best solution would be to get more 
> coders involved, but in lieu of that, we should at least listen up when 
> a coder like Mark asks the vendors to make his life easier by 
> simplifying the syntax.
> -jh-
Received on Monday, 26 April 2004 09:43:50 UTC

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