[Bug 25445] [XP3.1] Replace curly array constructor with a function

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25445

--- Comment #3 from Jonathan Robie <jonathan.robie@gmail.com> ---
(In reply to Michael Kay from comment #2)
> I did not intend to reopen the discussion about the semantics of [a,b,c]. I
> think we got it right in Prague: it creates an array with three members,
> these being the values of a, b, and c.

I think this issue inherently reopens the discussion of the syntax of array
constructors.  And frankly, I'd rather first rewrite all the use cases in our
current syntax before we revisit these decisions, we spent a lot of time
getting to where we are now. If we do revisit these decisions, we should look
at construction of arrays in general, not just one kind of array constructor. 

In Prague, we had agreement that we needed two kinds of constructors. One camp
felt that the comma in [a,b,c] should have the same meaning that it has in
(a,b,c).  The other camp felt that the comma should have the same meaning that
it has in function calls, separating arguments.

In this issue, you have suggested that we use function call syntax for array
constructors. I think that makes most sense for the syntax that uses commas the
same way function calls do.

> We can't do this with a function call unless it is a variable-arity
> function call.

Yes, it would be variable arity.

> I'm concerned here with the other construct, array{X}. I want to understand
> whether there is a good reason for having custom syntax for this, rather
> than using a function call as we do with its inverse, seq(X).

Why do you have this question only for one of the two array constructor
syntaxes?  The question seems equally apt for both.

> I see this being used in situations like
> 
> array {
>   for $x in employee
>   return $x/salary/data()
> }
> 
> and perhaps this is why curlies were chosen; the FLWOR looks more like a
> statement than an expression to people from other cultures, because of its
> sentential syntax, and in those cultures curly braces are used to group
> "statements". But that's not our culture; we have an expression language,
> and array{} is semantically a pure function call. 

In our culture, we use {} for computed constructors of many kinds - documents,
elements, attributes, maps, even text nodes, PIs, and comments. To me, this
seems perfectly in line with those constructs.

> Making it a pure function allows things like
> 
> (a/b/c) => array()
> 
> which people will increasingly expect to be able to write.

We could certainly add a function to do that. I'm not sure how important it is
to create structures this way, or why arrays are different from documents,
elements, attributes, maps, etc. 

We're talking about syntax here, and I think the best way to determine the most
convenient syntax for expressions in a language is to look at a body of
examples, written in each proposal. Syntax always has a high potential for bike
shedding, so I suggest we first rewrite the use cases in our current syntax,
then entertain change proposals for attribute constructors.

[
  for $w in $s()
  return { "pos" : $w(2), "lemma" : $w(1) }
]

array { a/b/c }

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 25 April 2014 15:52:35 UTC