Add syntax for specifying the return type on the same line as function arguments (parser part)

[jdunkerley]

Discussed in https://github.com/orgs/enso-org/discussions/5987

Add the ability to define types of parameters and return type in a single line for a function.

The new (additional) syntax to define a function would be:

Any.my_function self that:Integer -> Text =

Parameters have their types attached (as is already allowed in a few places). The return type of the function is given after the -> before the =.

[jdunkerley]

Assigned to @JaroslavTulach to triage and assess what is needed.

[JaroslavTulach]

I tried to parse the above given signature with

diff --git engine/runtime/src/main/java/org/enso/compiler/TreeToIr.java engine/runtime/src/main/java/org/enso/compiler/TreeToIr.java
index 13141b665b..366e252e78 100644
--- engine/runtime/src/main/java/org/enso/compiler/TreeToIr.java
+++ engine/runtime/src/main/java/org/enso/compiler/TreeToIr.java
@@ -573,6 +573,9 @@ final class TreeToIr {
           loc = Option.empty();
         }
       }
+      case Tree.OprApp withType when "->".equals(withType.getOpr().getRight().codeRepr()) -> {
+        return translateMethodReference(withType.getLhs(), alwaysLocation);
+      }
       default -> throw translateEntity(sig, "translateMethodReference");
     }
     return new IR$Name$MethodReference(type, method,
diff --git engine/runtime/src/test/java/org/enso/compiler/EnsoCompilerTest.java engine/runtime/src/test/java/org/enso/compiler/EnsoCompilerTest.java
index e5f6e75ebd..eee1556599 100644
--- engine/runtime/src/test/java/org/enso/compiler/EnsoCompilerTest.java
+++ engine/runtime/src/test/java/org/enso/compiler/EnsoCompilerTest.java
@@ -1221,6 +1221,14 @@ public class EnsoCompilerTest {
     equivalenceTest("a = x.f 1", "a = FREEZE x.f 1");
   }

+  @Test
+  public void testInnerTypes() throws Exception {
+    equivalenceTest(
+      "Any.my_function self:Any that:Integer -> Text = 'hi'", 
+      "Any.my_function self that = 'hi'"
+    );
+  }
+
   @Test
   public void testSkip() throws Exception {
     equivalenceTest("a = x", "a = SKIP x");

the Rust side parses the one-line type signature as Tree.Assignment - that's probably not correct. We'd like to get Tree.Function. That will require changes on the Rust parser side, right @kazcw?

[radeusgd]

This ticket is concerned with extending the parser functionality to allow us to specify the return type with the -> X syntax.

Handling the syntax in the compiler will be done as a followup ticket #8240

[radeusgd]

We will need to think carefully how to handle a few ambiguous cases like:

foo a : Integer -> Integer = ...

Should this be interpreted as foo (a : Integer) -> Integer = ... OR foo a : (Integer -> Integer) = ...?

I imagine the former makes more sense, and in general we should just prefer to use brackets on argument types, but in case the user does not specify them we need to be clear what is the precedence.

[kazcw]

We will need to think carefully how to handle a few ambiguous cases like:

foo a : Integer -> Integer = ...

Should this be interpreted as foo (a : Integer) -> Integer = ... OR foo a : (Integer -> Integer) = ...?

I imagine the former makes more sense, and in general we should just prefer to use brackets on argument types, but in case the user does not specify them we need to be clear what is the precedence.

@radeusgd I think we are constrained here by other uses of the same operators. If : were to bind more tightly than ->, we would not parse signature declarations like Column.expect : Text -> Vector -> Test_Result correctly.

Given our existing operator precedence, when the operators are not grouped by spacing or parentheses it will parse as an assignment to an invalid pattern, which is a syntax error.

[enso-bot[bot]]

Keziah Wesley reports a new STANDUP for today (2023-12-05):

Progress: Implemented new syntax. Cleaned up representation of default arguments, and aligned frontend treatment with backend. It should be finished by 2023-12-05.

Next Day: Next day I will be working on the #8367 task. AST-driven edits.