Closed jdunkerley closed 10 months ago
Assigned to @JaroslavTulach to triage and assess what is needed.
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?
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
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.
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 = ...
ORfoo 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.
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.
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:
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=
.