Parse map literals to key/value pairs

[waddie]

When parsing map literals, it would be useful to group the subtree into k/v pairs. This would allow querying for the matching k/v pair, all keys, etc.

e.g. given a map literal:

{:foo "bar" :baz "quux" "tom" "jerry"}

Instead of parsing to 6 values:

(source [0, 0] - [1, 0]
  (map_lit [0, 0] - [0, 38]
    value: (kwd_lit [0, 1] - [0, 5]
      name: (kwd_name [0, 2] - [0, 5]))
    value: (str_lit [0, 6] - [0, 11])
    value: (kwd_lit [0, 12] - [0, 16]
      name: (kwd_name [0, 13] - [0, 16]))
    value: (str_lit [0, 17] - [0, 23])
    value: (str_lit [0, 24] - [0, 29])
    value: (str_lit [0, 30] - [0, 37])))

Parse to 3 map_entry key/value pairs:

(source [0, 0] - [1, 0]
  (map_lit [0, 0] - [0, 38]
    (map_entry [0, 1] - [0, 11]
      key: (kwd_lit [0, 1] - [0, 5]
        name: (kwd_name [0, 2] - [0, 5]))
      value: (str_lit [0, 6] - [0, 11]))
    (map_entry [0, 12] - [0, 23]
      key: (kwd_lit [0, 12] - [0, 16]
        name: (kwd_name [0, 13] - [0, 16]))
      value: (str_lit [0, 17] - [0, 23]))
    (map_entry [0, 24] - [0, 37]
      key: (str_lit [0, 24] - [0, 29])
      value: (str_lit [0, 30] - [0, 37])))))

[sogaiu]

IIUC, this is something we considered and decided against for the time being.

As GH makes searching longer issues / prs / discussions cumbersome because of its "collapsing" [1], I'll post some links to specific comments that touch on entries in the issue:

• Failure to properly handle return type metadata? #65 (comment)
• Failure to properly handle return type metadata? #65 (comment)
• Failure to properly handle return type metadata? #65 (comment)
• Failure to properly handle return type metadata? #65 (comment)
• Failure to properly handle return type metadata? #65 (comment)
• Failure to properly handle return type metadata? #65 (comment)
• Failure to properly handle return type metadata? #65 (comment)

---

[1] I very much would have preferred discussion elsewhere but unfortunately the relevant parties were not inclined in that direction.

[waddie]

Many thanks for taking the time to dig out those comments @sogaiu. +1 for focused discussion threads. 😄

For context, the specific use-case I wanted this for was Helix’s match in/around data structure entry functionality:

With this in the grammar, you can quickly type mie to select the key or value, or mae to select the entire k/v pair. Without it in the grammar, there might be a Helix-side solution when the plugin system finally lands, but for now I think the latter is impossible. Helix has lots of tools for extending selections, but it’s still a significant time-saver to be able to grab the pair at once, especially in large/deep maps.

At least, I couldn’t figure out any way of doing that in a t-s query, which kicks what seems like a parsing problem all the way up to application/plugin code in the consumer.

Grammatically, a map is only valid when composed of balanced pairs, and I feel like the ideal place to parse that information is in the grammar, where it’s close to free and gives every consumer the same solid foundation.

And philosophically, in a just and pure world, I think handling syntactically incorrect forms should be a consumer problem. What should move form forwards/backwards do if you have a syntax error? I don’t know, but don’t you need to handle that in the implementation of move form anyway?

But pragmatically, making life harder for any Emacs Clojure programmers for the benefit of Helix Clojure programmers (of whom there are, like, maybe three, including me), would be a ludicrous decision. Maintaining a half-dozen line fork is no great burden, and Helix makes it easy to override the grammar and queries in your local config.

Maybe revisit if the prospect of Scheme-based extensibility entices a few more over to Helix. 😄

[sogaiu]

Thanks for sharing your thoughts and the background involved. If the topic is revisited, what you shared might be of help at that point.

---

ATM, just wanted to make a brief note...

Grammatically, a map is only valid when composed of balanced pairs

I think the example in this comment might be a counter-example:

{:a 1 #?@(:clj [:b 2])}
;; =>
{:a 1, :b 2}

Due to splicing of reader conditionals, one might say that there are an odd number of items in the map literal.

---

Maybe revisit if the prospect of Scheme-based extensibility entices a few more over to Helix.

Getting closer?

[waddie]

I think the example in this comment might be a counter-example:

Ah, that’s a fair point, I missed the implication of that one.

Maybe revisit if the prospect of Scheme-based extensibility entices a few more over to Helix.

Getting closer?

🤞