[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xquery-talk] Mistakes made in the design of XQuery 3.1
- From: Michael Kay <mike@saxonica.com>
- To: Benito van der Zander <benito@benibela.de>
- Date: Sat, 9 May 2015 22:22:40 +0100
>
> I think the array constructor was the biggest mistake. (I believe arrays more frequently used than null)
> I doubt it would be possible to make a worse definition.
>
> Three constructors, map { ... }, array { ... }, [ ... ]
>
> Only [ ... ] looks out of place.
>
> Every other constructor in XQuery uses { }. Even node constructors.
>
> There is no reason to add [ .. ] for arrays, if you want to make a consistent language.
I agree with you, I’m not happy with this aspect of the design. But the decision was reached after lengthy arguments at a F2F meeting which I didn’t attend, so I couldn’t complain.
The problem is that neither construct does the whole job. [a,b,c] can only be used to create an array whose size is statically known, whereas array{X,Y,Z} can only be used to create an array whose members are single items.
But the underlying problem is really that arrays are second-class citizens in the language. FLWOR expressions, filter expressions, even the comma operator, work on sequences but not on arrays. We tried many different design approaches for arrays in attempting to tackle this problem, but this was the best we could do.
>
> So the only reasonable definition is to concat sequences in [ ] and not concatenate them in array { }
>
>
> But no, you do the complete opposite!
>
Yes. I tried to get it changed to be the other way around, and failed. Just in case Daniela thinks I got everything my way.
Michael Kay
Saxonica
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]