Support sequence, array, and map destructuring declarations

[rhdunn]

Given a function that returns a sequence, array, or map of a fixed length or structure, it would be useful to extract those values in a destructuring declaration like can be done in other languages (such as JavaScript, Kotlin, C++, and Python). For example:

let $(sin, cos) := sincos(math:pi()) (: sequence :)
let $[x, y, z] := camera-angle() (: array :)
let ${r, i} := complex(1, 2) (: map :)

These would be equivalent to:

let $ret := sincos(math:pi()), $sin := $ret[1], $cos := $ret[2] (: sequence :)
let $ret := camera-angle(), $x := $ret?(1), $y := $ret?(2), $z := $ret?(3) (: array :)
let $ret := complex(1 ,2), $r := $ret?r, $i := $ret?i (: map :)

It should be possible to define the type of a component and/or the whole construct:

let $(sin as xs:float, cos) as xs:float* := sincos(math:pi()) (: sequence :)

For maps, it would also be useful to rename the components, such as:

let ${re := r, im as xs:double := i} := complex(1, 2) (: map :)

It should also be possible to capture any left-over items in the sequence/array/map, for example:

let $(headings, rows) := load-csv("test.csv")

A destructuring declaration should be usable anywhere a variable binding can be defined.

It should not be an error to use the same variable name twice. This supports conventions such as using _ for unused values. For example:

let $[_, y, _] := camera-angle()

[ChristianGruen]

I like the approach. Deconstruction is a powerful feature in other programming languages, and I see many use cases for it in XQuery.

If a sequence is deconstructed, I would indeed suggest assigning all remaining items to the last variable:

let $(a, b, c) := 1 to 4
return $c  (: 3, 4 :)

@rhdunn I assume you also had this in mind in the CSV example?

[rhdunn]

Yes, that's what I had in mind with the CSV example. It should also apply to arrays and maps -- if there is one value left, assign that value to the last variable; otherwise assign an array/map with the remaining values to the variable.

[ChristianGruen]

+1 for arrays. Maybe it’s not really required for maps (and I’m not sure how that’s supposed to look like?). I would guess that unreferenced keys won’t be relevant to the user most of the time. An example:

let $inc-x := function($coords) {
  map:put($coords, 'x', $x?x + 1)
}
let $coords := map { 'x': 1, 'y': 3, 'z': 0 }
let $(x, y) := $inc-x($coords)
return $x + $y

[rhdunn]

You are right, it would make more sense to ignore unreferenced/unnamed keys for maps.

[michaelhkay]

I have to confess I've never really seen the attraction of this feature in other languages, it's one that I tend not to use. That probably inclines me to the view that it's not needed.

I can see the attraction with maps/records - with the introduction of record types we're starting to introduce the idea that the names of the entries in a map might be known statically and that we can take advantage of this knowledge to make programs more readable and more statically checkable, and there's some attraction in being able to write

let $(x, y) := coordinates($rectangle)

in preference to

let $r := coordinates($rectangle), $x := $r?x, $y := $r?y

In XSLT I guess it could be <xsl:variable name="x, y" select="coordinates($rectangle)"/>

For sequences and arrays I'm less convinced, because I don't particularly want to encourage these data types to be used in a way where the semantics are non-uniform, e.g. where items 1 and 2 in a sequence/array mean different things and are used in different ways. I think the right structure for that kind of job is a map. I would always use a map, for example, for coordinates in three-dimensional space, not a sequence or an array.

[rhdunn]

The benefit of this feature to me is in being able to make it clear what the intent is (i.e. I'm only interested in these components), can give meaningful names to things, and write that in less code. If the item is being referred to in multiple places, I can avoid repeating the code.

Regarding arrays and sequences, one key use case would be the CSV example above where you want to filter out the headers (first row of the CSV) from the rest of the CSV. There may be other cases where this is useful -- especially for existing functions (which is a stated goal with the variadic argument work) such as MarkLogic's xdmp:tidy which returns the errors/warnings in the first item and the tidied result in the second. For example:

let $(messages, result) := xdmp:tidy($doc)
return if ($messages/tidy:error) then fn:error() else $result

I don't think the language should be constraining a feature to any one type because there is no perceived use for that, or because it is generally discouraged. It creates gaps in the language, resulting in people asking why does one feature support sequences and arrays, another maps only, and a third all three, when there is no technical reason preventing such usage.

[michaelhkay]

It feels to me like bad data modelling to use the first item in a sequence for headers, and subsequent items for data. I don't think we should be providing features to make it easier to manipulate data that's badly designed. Just because it was designed that way before maps/tuples were available doesn't really change that argument.

[ChristianGruen]

One popular use case for using deconstruction is the access to the head and tail of a sequence, which potentially allows you to save one extra variable binding:

(: old :)
let $data := ...
let $head := head($data)
let $tail := tail($data)

(: new :)
let $(head, tail) := ...

But I share your concerns: Deconstruction is also misused as quick’n’dirty replacement for cleaner data structures.