Semi-formal specification for method resolution

[Akirathan]

Pull Request Description

Semi-formal spec for method invocation. Documents the desired behavior that is being implemented in #13962.

Important Notes

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  TypeScript,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• Unit tests have been written where possible.
• If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
  or the Snowflake database integration, a run of the Extra Tests has been scheduled.
  • If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

[Akirathan]

RFC engine and libs team (@JaroslavTulach , @jdunkerley , @4e6 , @hubertp , @GregoryTravis ): Do you consider this kind of semi-formal specification for method resolution and method evaluation useful? Is it better than looking at our tests or in our code base? Do you want me to finish it? Do you have any other suggestions how to improve it? Note that this PR is WIP, obviously.

[JaroslavTulach]

Suggested change

	- 2.2. No parent type is present. Raise `No_Such_Method` panic and stop.
	- 2.2. No parent type is present. Raise `No_Such_Method` panic and terminate.

[JaroslavTulach]

• This is not really a "dynamic dispatch"
• but it is an interesting topic
• and complicated - e.g. term like all transitively imported modules sounds scary
• I'd move it to its own "lexical dispatch" document

[Akirathan]

I believe that as of ed299f5, this is really the final specification that should work for all our use cases. As demonstrated by the updated tests in 7b58937

[JaroslavTulach]

I believe that as of ed299f5, this is really the final specification that should work for all our use cases. As demonstrated by the updated tests in 7b58937

This diff is more important than #13961 (comment) and it’s 7b58937 as it shows the diff against current behavior. Can we make it less red?

[Akirathan]

This diff is more important than #13961 (comment) and it’s 7b58937 as it shows the diff against current behavior. Can we make it less red?

@JaroslavTulach Done. See #13962 (comment)

[JaroslavTulach]

Or is it

Suggested change

	"allTypes(Singleton_Type.type) == [Singleton_Type.type, Any]",
	"allTypes(Singleton_Type) == [Singleton_Type, Any]",

;-?

[Akirathan]

I am really not sure about this one. See the line 159 with assertThat("is eigen type", raw.isEigenType(), is(true)). So I think it should be written as Singleton_Type.type.

[Akirathan]

Changes introduced in Type.fillInTypes necessary to make the newly introduced TypeChainTests green, breaks other stuff. For example in https://github.com/enso-org/enso/actions/runs/18308891816/job/52133745709?pr=13961#step:14:1114.

Can be reproduced with:

vec = [1,2,3]
vec.at 100 == Nothing

which, on this PR, returns False, but should return Index_Out_Of_Bounds error.

This is caused by the fact, that on develop allTypes(Error) == [Error], but on this PR, allTypes(Error) == [Error, Any]. In turn, this means that an UnresolvedSymbol("==").resolveFor(Error) will resolve to Any.== which is incorrect.

TypeChainTest as well as changes in Type are necessary for #13962. Let's move it to that PR and keep this PR only about documentation.

---

Moved in 1522b50 and 5a40ad8

[JaroslavTulach]

keep this PR only about documentation.

• (Unit) tests are essential part of documentation.
• I prefer to keep the test and just disable (or @Ignore) the parts that are known to diverge
• Leave comments with references to tasks that will fix the disabled parts

[Akirathan]

@JaroslavTulach Tests are again in this PR, with a single ignore.