[pkg/ottl] Add map literals

[evan-bradley]

Component(s)

pkg/ottl

Is your feature request related to a problem? Please describe.

Currently there is no way in OTTL to create a new map. This makes certain use cases difficult and limits the language's expressiveness.

Describe the solution you'd like

Use {"key": value, [...]} as a map literal syntax, similar to how it looks in JavaScript, JSON, or Go structs. In particular, I would like the following to be possible when retaining the original log body while parsing a log:

- set(body, {"_raw": body})
- set(body["mykey"], "myvalue")
- merge_maps(body, ParseJSON(body["_raw"]))

Describe alternatives you've considered

Instead of map literals, we could add a Map function with optional parameters to create keys in the initial map. However, I think maps are important enough in OTLP to justify adding map literals to the language.

Additional context

Implementation will broadly look something like the following:

1. Update buildLexer in grammar.go to understand map literals.
2. Update the AST in grammar.go to capture keys and values in the map.
3. Update the parser to create pdata map objects from map literal nodes in the AST.

[github-actions]

Pinging code owners for pkg/ottl: @TylerHelmuth @kentquirk @bogdandrutu @evan-bradley. See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• pkg/ottl: @TylerHelmuth @kentquirk @bogdandrutu @evan-bradley

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[bacherfl]

@evan-bradley if this issue is still available, I would like to work on this

[evan-bradley]

That would be great @bacherfl, thank you.

[evan-bradley]

A few thoughts in response to #34168 (review):

1. Just like lists, map literals don't need to be indexible for the foreseeable future. We can add that functionality in a follow-up if there is user interest.
2. I would see the full-ish allowable syntax for a map literal looking like the following:

   {
       "str": "string",
       "int": 123,
       "bool": true,
       "double": 1.23,
       "math": value_int * 3
       "converter": ConvertCase(name, "upper"),
       "enum": METRIC_DATA_TYPE_SUM
   }
   

[TylerHelmuth]

How will non-static values be handled?

[TylerHelmuth]

Do list literals allow Enums Converters Editors, and MathExpressions?

[evan-bradley]

How will non-static values be handled?

They'll be evaluated as part of the statement. I think that's the most intuitive way to handle it.

Do list literals allow Enums Converters Editors, and MathExpressions?

They do. It's worth noting that editors are explicitly disallowed; the parser will catch them and return an error if it sees one.

[TylerHelmuth]

Ok, we should match the same types as list.