RE: IfExpr has a mandatory else clause

Obviously the empty sequence.  I often find myself writing expressions
like

if (expr1) then expr2 else ()

so as a matter of convinience, one could allow omitting the else clause
if its value is the empty sequence.  This is simply a syntactic
shortcut.  It has also been proposed to allow "where" without "for" or
"let", achieving the same effect:

where (expr1) return expr2

Bas de Bakker
X-Hive Corporation

> -----Original Message-----
> From: Torsten Grust [mailto:Torsten.Grust@uni-konstanz.de]
> Sent: Monday, January 26, 2004 10:55
> To: TAN Kuan Hui
> Cc: Bas de Bakker; www-ql@w3.org
> Subject: Re: IfExpr has a mandatory else clause
> 
> 
> G'day all,
> 
>   grammar issues aside for a minute, I perceive XQuery as a
> _functional_ query language.  The IfExpr thus constitutes a
> conditional expression rather than a control flow construct (like in
> procedural programming languages).
> 
> As a conditional expression, IfExpr is required to evaluate to a
> well-defined value, regardless of the outcome of the tested
> condition.  This is why I find it quite natural that the `else' clause
> is mandatory.  What would be the value of an IfExpr in case the
> conditition evaluates to false?
> 
> Greetings,
>    --Torsten
> 
> On January 26 (17:49 +0800), TAN Kuan Hui wrote with possible
> deletions:
> |
> | Syntactically seems to parse but will this cause confusion ?
> | Using () instead of {} will also re-introduce the
> | ambiguity with an optional else clause although distinguishable.
> |
> | So is grammar ambiguity the reason that IfExpr has a
> | mandatory else clause ? Are there other design considerations ?
> | Appreciate any clarification.
> 
> 
> 
> --
>   | Dr. Torsten Grust                          
> Torsten.Grust@uni-konstanz.de |
>   |                                   
> http://www.inf.uni-konstanz.de/~grust/ |
>   | Database Research Group, University of Konstanz (Lake 
> Constance/Germany) |
>   |             (Please avoid sending me MS Word or 
> PowerPoint attachments.) |
>

Received on Monday, 26 January 2004 05:08:42 UTC