W3C home > Mailing lists > Public > www-ql@w3.org > January to March 2004

Re: IfExpr has a mandatory else clause

From: TAN Kuan Hui <kuanhui@xemantics.com>
Date: Wed, 28 Jan 2004 10:40:28 +0800
Message-ID: <001601c3e548$21a31dd0$f040bada@pinecone>
To: "Bas de Bakker" <bas@x-hive.com>, <www-ql@w3.org>, "Jonathan Robie" <jonathan.robie@datadirect.com>

Greatly appreciate the transparency in the your clarification.

From: "Jonathan Robie" <jonathan.robie@datadirect.com>
> At 04:49 AM 1/26/2004, TAN Kuan Hui wrote:
> >So is grammar ambiguity the reason that IfExpr has a
> >mandatory else clause ?
>
> Yes.
>
> >Are there other design considerations ?
>
> Not really.
>

I have tried this through my parser without ambiguity.

[54]    IfExpr    ::=    <"if" "("> Expr ")" "then" "{" ExprSingle "}"
(<"else" "{"> ExprSingle "}")?

where
    <"else" "{"> calls pushState(DEFAULT);


Even without the explicit blocking construct, the else clause is
distinguishable against NCName in the Operator state; nested
if-then-[else] are then tied through parentheses. I would
appreciate if anyone on this list can dispute this ?

So I personally do not think grammar ambiguity should be
a consideration for justifying for a mandatory else clause.
Its unnecessarily restrictive and IMO appreciating the
fact that coding a dangling else () is to enforce a
functional language programming style would be the least
enlightening for the stressed out programmer.

Aside, with an optional else clause, nothing stops you from
still being able to explicitly dangle a "else ()" to every IfExpr
if you really want to enforce that "functional" programming style.
Each implementation can also easily issue warnings or stops
compiling as an option for the programmer to exercise
rather than having this enforced through the grammar.

On the other hand nothing stops an implementation from
having an optional else clause even if the grammar says
otherwise when it can similarly be made XQuery compliant
through an option to the parser right ? But this will inevitably
introduce interop problems, so its still better that this is
resolved at the grammar level.

> Well, there is one justification that makes some sense. This is a
> functional language, every expression evaluates to something, and if the
> conditional expression evaluates to the empty sequence, there is some
> virtue to saying so explicitly. That's not much of a reason, but it will
do
> as a post-hoc rationalization ;->
>
IMO this is merely a programming style and nothing really to do
with making XQuery an abstractly functional perfect grammar.
Having an optional else clause does not make IfExpr less functionally
expressive nor does returning an empty sequence without an else clause
non intuitive.

> But resolving the ambiguity is important. For what it's worth, every entry
> in this thread is reminiscent of discussions we had at length within the
> Working Group. These are reasonable positions, but not new ones.
>
So if grammar ambiguity can be resolved, would the Working Group kindly
reconsider having an optional else clause ?
Received on Tuesday, 27 January 2004 21:40:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 22 July 2006 00:10:19 GMT