Compact syntax for multi-select-hash

[springcomp]

Compact syntax for multi-select-hash

JEP	20
Author	Dan Vanderkam, Maxime Labelle
Status	draft
Created	26-Feb-2022

Abstract

This JEP proposes a grammar modification to support ES6-style compact multi-select-hash constructs.

Motivation

Consider the following JSON document:

{
  "values": [
    {"id": 1, "first": "Bill", "last": "Gates"},
    {"id": 2, "first": "Larry", "last": "Page"}
  ]
}

Let’s say we wanted to return a hash containing ids and first names.
This is currently possible using the following syntax:

values[*].{id:id, first:first}

Since {x:x, y:y} is such a common pattern, ES6 introduced compact object literal notation to simplify this. In ES6, {x,y} is equivalent to {x:x, y:y}.

This JEP supports this syntax to make JMESPath usage slightly less verbose. In addition, this JEP enables empty multi-select-hash and – for consistency – multi-select-list expressions.

Specification

The multi-select-hash production will be changed as follows:

multi-select-hash       = "{" *( multi-select-hash-entry ) "}"
multi-select-hash-entry = identifier / keyval-expr
keyval-expr       = identifier ":" expression

Note that an empty multi-select-hash becomes legal and produces an empty JSON object.

search( {}, {"foo": "bar"} ) -> `{}`

For consistency, an empty multi-select-list is also legal and produces an empty JSON array.

search( [], { "foo": "bar" } ) -> `[]`

Motivating Example

With these changes defined, the expression in the “Motivation” section can be written as:

values[*].{id, first}

Which evaluates to [{"id": 1, "first": "Bill"}, {"id": 2, "first": "Larry"}].

Compliance Tests

This JEP standardizes a syntax that was formely not valid. For this reason, one of the syntax.json compliance tests must be changed or removed altogether:

    {
      "comment": "Multi-select hash syntax",
      "given": {
        "type": "object"
      },
      "cases": [
        {
-         "comment": "Not a key-value pair",
+         "comment": "Valid single-key multi-select hash extraction",
          "expression": "a.{foo}",
-         "error": "syntax"
+         "result": null
        }
      ]
    }

New tests will also be added to the multiselect.json file.

Rationale

This JEP is inspired by an idea from Dan Vanderkam.

History

Date	Description
16-August-2022	Supports { foo } single-key multi-select-hash expression.
03-November-2022	Supports { } empty multi-select-hash expressions.
19-June-2023	Simplified grammar and supports mixed key / kev-val entries.

[springcomp]

Should we standardize support for empty multi-select-hash expressions here?

[gibson042]

Why not support { key1, key2: "val2", key3 } mixtures like ECMAScript?

multi-select-hash       = "{" *( multi-select-hash-entry ) "}"
multi-select-hash-entry = identifier / keyval-expr

[springcomp]

One more reason we may need to support this.

When using combinations of the items(), from_items() and zip() functions, one might end up with an final expression like-this:

• from_items( { k:k, v:v }.zip(k, v) )

Allowing from_items( { k, v }.zip(k, v) )
Additionally. we could expand zip() to accept a multi-select-hash : allowing from_items( zip({ k, v } ))

[kit494way]

Why not support { key1, key2: "val2", key3 } mixtures like ECMAScript?

multi-select-hash       = "{" *( multi-select-hash-entry ) "}"
multi-select-hash-entry = identifier / keyval-expr

This looks good to me.
I want this feature, but this JEP is still in draft.
What else is needed for this JEP to be stable and proceed to implementation?

[springcomp]

@kit494way Thanks for your feedback, this feature is currently set to be included in the next version of the specification.

I originally planned to publish one specification every year at least.

Unfortunately, community engagement seems a bit lagging and as a result there is not as much feedback as I thought there would be when I set out to steward improvements to the specification. That said, you can see what is currently planned for the next iteration to the specification. I hope to be able to publish a new version by the end of year at the earliest.

Out of curiosity, what language implementation would you like to see this included in ?

[kit494way]

@springcomp Thanks for your reply.
I want to use this syntax in jp and jpterm, so I would like to see this included in go and python implementation.