Re: CASE

On 18/11/10 13:37, Paul Gearon wrote:
> On Wed, Nov 17, 2010 at 7:12 PM, Lee Feigenbaum<lee@thefigtrees.net>  wrote:
>> A comment today on the -comments list asked for a CASE function, as a terser
>> way to write what would otherwise be multiple nested IFs.
>>
>> I'm inclined (here and with the rest of the function library discussion) to
>> begin declining new functions to keep the scope of our work manageable.
>> After all, we are in theory only a month away from Last Call.
>>
>> Is anyone in the group inclined to add a CASE function to SPARQL 1.1?

Not me.

> I would like a CASE function, and it would be trivial to implement.
> However, I think that your concerns about the timeframe are more
> relevant here.
>
> We put out the first public docs a year ago. If it was that important,
> someone would have mentioned it before now. So I vote against it.
>
> (Given the trivial nature of the implementation and implications, I
> won't be upset if we include it, but we need to draw a line
> somewhere).
>
> Regards,
> Paul Gearon

I agree, it does not look hard to implement and I agree that the need 
does not seem sufficiently high enough to justify the impact on the spec.

It's not obvious to me that the SQL CASE statement design (designs - 
there are two versions, for comparison and cascading boolean 
expressions), or a CASE statement at all, is the right one until other 
flow control forms are scoped out.

The comments email uses as example:

IF(e1, e2, IF(e4, e5, IF(e6, e7, IF(e8, e9, IF(e10, e11, e12))))

but I've never seen the use in practice of nested IFs, given we have 
COALESCE.

(If someone wants to do the work (scoping, discussion, grammar, doc 
text, test cases), then great.  I'm not going lead on this - if the WG 
makes a formal decision to do it in light of the time-cost, and it ends 
up with me, then that's what editors are for).

	Andy

Received on Thursday, 18 November 2010 15:09:23 UTC