Literal format for the Map type

[jdunkerley]

As we now have a built-in Map type we would like to add a literal format to create a map instance.

There appears to have been old support within the old parser for a syntax:

enso/engine/runtime/src/test/scala/org/enso/compiler/test/pass/analyse/DataflowAnalysisTest.scala

Line 1295 in d1c52fe

|{ x := a ; y := b }

The format appears to have been: { x := 1; b := 2 }.

Readding support to this for the parser would be the first step, and then making the engine produce a Map from it.

For example:

• { x := 1; b := 2} would be translated to Map.empty.insert a 1 . insert b 2
• { "key" := 1, "value" := 2} would be translated to Map.empty.insert "key" 1 . insert "value" 2

A ticket for the parser has been added by @kazcw: #6162

Is everyone happy on adding this back in?
I would suggest switching to , as the delimiter rather than ; as appears to be the case in the old parser.

cc: @hubertp @Akirathan @JaroslavTulach @wdanilo @radeusgd @GregoryTravis

[wdanilo]

The old format was accidental and we never designed it properly. I believe that the old syntax does not fit the current Enso language design. I do not know yet what design is correct though. I think something like {a = 1, b = 2, c = 3} is already better than the one above, but what I don't like here is the need of using curly braces, even with multi-line definition, which is something new in Enso syntax. Alternatively, we could do something like (map is a macro here): v1 = map (a = 1, b = 2, c = 3) which could be used as:

v1 = map
    a = 1
    b = 2
    c = 3

Anyway, this needs IMO a little bit more discussion and brainstorming. I'd love to hear what you think about these ideas.

[jdunkerley]

The curly brace felt natural to me as it is very similar to python (although python uses :) and JavaScript.
Agree just having an = is cleaner than the := above.

We use square brackets exclusively for Vector literals so having a similar unique marker for brackets feels in keeping.

The macro syntax would be a new thing we haven't had before (or at least not such that an average user would know).

[wdanilo]

@JaroslavTulach that's bad. Hmm, the new parser should support that. Could you check out the AST you've got from that? CC @kazcw, are we supporting this form?

[kazcw]

The body of main parses as:

(ArgumentBlockApplication (Ident x) #(
 (OprApp (Ident a) (Ok "=") (Number () "5" ()))
 (OprApp (Ident b) (Ok "=") (Number () "7" ()))
 (OprApp (Ident c) (Ok "=") (Number () "9" ()))))

This representation is awfully low-level, but not inaccurate. (Some day I'd like to introduce an enum ArgumentBlockValue--a bunch of things are Tree that I'd prefer to restrict.).

It looks like translation doesn't support named-arguments in argument-block-applications. Translation work was driven by parsing the .enso corpus and passing the stdlib tests; this case never came up, and I didn't notice support was missing.

[JaroslavTulach]

This representation is ... low-level, but not inaccurate

True, I can see how to convert it into IR.

translation doesn't support named-arguments in argument-block-applications

The remaining question is, what's the key differentiator from:

main = x
    a = 5
    b = 7
    a * b

e.g. a block of statements (like in the else branch of if_then_else?). When one is supposed to treat ArgumentBlockApplication as set of named arguments and when one is supposed to treat it as a sequence of statements?

[JaroslavTulach]

map is just a function that takes arbitrary number of arguments.

I don't think we have any support for that in the IR and after.

It is possible to create such functions using macros in Enso now.

Maybe, but the rest of the pipeline is unlikely ready for them. We were hoping for a focused, small change to support map literals - not a support for a new abstraction cross-cutting the whole compiler stack.

map: Map_Builder and it is just a struct, which behaves like an empty Map, but if you provide it with an argument, it should consume it and add it to the underlying map.

I guess it was this sentence which inspired me to write the Map.make <| "A" <- 3 <| "B" <- 5 proposal.

[kazcw]

When one is supposed to treat ArgumentBlockApplication as set of named arguments and when one is supposed to treat it as a sequence of statements?

In the tree, this is distinguished by the block type: ArgumentBlockApplication is always application of arguments--they can be mixed named- and unnamed-arguments. A sequence of statements is represented as a BodyBlock. Syntactically, the distinction is: If a block is introduced by a line ending in an operator (or certain keywords, as in if/else), it is parsed as a body block; otherwise, it is an argument block (unless it fits the operator block syntax).

[JaroslavTulach]

If we shall go with the "block based syntax", then we don't need any parser changes at all. This diff implements such syntax fully in Enso standard libraries:

enso$ git diff
diff --git distribution/lib/Standard/Base/0.0.0-dev/src/Data/Map.enso distribution/lib/Standard/Base/0.0.0-dev/src/Data/Map.enso
index ad0a4a85f1..f684e1c88b 100644
--- distribution/lib/Standard/Base/0.0.0-dev/src/Data/Map.enso
+++ distribution/lib/Standard/Base/0.0.0-dev/src/Data/Map.enso
@@ -5,6 +5,8 @@ import project.Data.Text.Extensions
 import project.Data.Text.Text
 import project.Errors.Illegal_Argument.Illegal_Argument
 import project.Errors.No_Such_Key.No_Such_Key
+import project.Runtime.State
+import project.Runtime.Ref.Ref
 
 from project.Data.Boolean import Boolean, True, False
 from project import Error, Nothing, Any, Panic
@@ -23,6 +25,12 @@ from project import Error, Nothing, Any, Panic
    treated as a Map.
 @Builtin_Type
 type Map key value
+    make : Any -> Map
+    make ~action =
+        ref = Ref.new Map.empty
+        State.run Map ref action
+        ref.get
+
     ## Returns an empty map.
     empty : Map
     empty = @Builtin_Method "Map.empty"
@@ -357,3 +365,9 @@ type Map key value
     ## PRIVATE
     get_builtin : Any -> Any -> Any
     get_builtin self key ~if_missing = @Builtin_Method "Map.get_builtin"
+
+Any.$ self that =
+    ref = State.get Map
+    map = ref.get
+    new_map = map.insert self that
+    ref.put new_map
diff --git test/Tests/src/Data/Map_Spec.enso test/Tests/src/Data/Map_Spec.enso
index 64975c0676..3b3f84348f 100644
--- test/Tests/src/Data/Map_Spec.enso
+++ test/Tests/src/Data/Map_Spec.enso
@@ -359,6 +359,13 @@ spec =
             m2.to_vector.sort on=_.first . should_equal [["A", 1], ["B", 2]]
             m3.to_vector.sort on=_.first . should_equal [["A", 1], ["C", 3]]
 
+        Test.specify "nicer syntax for maps" <|
+            m1 = Map.make <|
+                "A" $ 1
+                "B" $ 2
+                "C" $ 3
+            m1.to_vector.sort on=_.first . should_equal [["A", 1], ["B", 2], ["C", 3]]
+
         Test.specify "should handle inserts with same keys (1)" <|
             m1 = Map.singleton "A" 1
             m2 = m1.insert "A" 2

one can probably use other symbol instead of $. I tried :, but that one wasn't working. Usage of = is also out of question, but others (like <<= or <-) seem to be fine.

[wdanilo]

This is cool, but TBH:

+            m1 = Map.make <|
+                "A" $ 1
+                "B" $ 2
+                "C" $ 3

Looks like a hack, not a clean solution we should ship to users. It's cool though :)

[jdunkerley]

Expanding on this ticket and bring it back to life...

I think the multiline map syntax, would not work well within the node editing style we have (though would with a vertical editor like proposed for Vector). The brackets and inline style would be clear for users and render simply in the ide.

I think @wdanilo simplified {<key>=<value>, ...} is the most familiar to users.
I have no objections to also supporting the multi-line style no brackets literal for code based development, but feel the bracket inline style is a high priority literal to add.

cc: @sylwiabr

[wdanilo]

@jdunkerley I never proposed multiline-only syntax. Please note that

v1 = map
    a = 1
    b = 2
    c = 3

is the same as writing

v = map a=1 b=2 c=3

However, if you think that {..., ...} syntax is better, we can use it. In fact, we already have syntax [..., ...], which is not white-space based, so maybe it's not as bad as I initially thought! :)