Debugger doesn't show atom fields when there are multiple constructors

[Akirathan]

From the InteropLibrary perspective, an Atom lists all field for all constructors as members. But it should list just fields for the constructor that was used to construct that atom.

The Atom members are, e.g., displayed as fields in the chrome inspector debugger. For the following atom:

type My_Type
  Cons_1 f1 f2
  Cons_2 g1 g2

main =
  My_Type.Cons_1 1 2

we would like to see only f1 and f2 fields, not any other.

An example of wrongly listed fields in the debugger:

All field accessors for all constructors are registered in AtomConstuctor.collectFieldAccessors.

Tasks

Beta Give feedback

1. Enable tests in AtomInteropTest.java
2. Enable test in DebugEnsoTest.java

Related to:

• Debugger doesn't show atom fields #10144

[JaroslavTulach]

It is annoying to see the fields of sibling Atoms in the debugger. The simplest fix is to not list them in InteropLibrary.getMembers as you suggest. How would the fix be related to

• Interop Atom's members test should return inherited members as well #6303
• How comes the Atom.getMembers messages only lists functions?
• How comes the functions aren't visible in the debugger? Does the debugger avoids displaying members that return true from isMemberInvocable?

[Akirathan]

How comes the functions aren't visible in the debugger? Does the debugger avoids displaying members that return true from isMemberInvocable?

@JaroslavTulach Because Atom.isMemberReadable only returns true for constructor fields. Debugger does not avoid members that are invocable - it normally displays them as functions.

How comes the Atom.getMembers messages only lists functions?

That seems like a historical inheritance. I have no idea. We should rethink the interop protocol for Atom. Let's consider the following snippet:

type My_Type
  Cons_1 f
  Cons_2 g
  instance_method self = 1
  static_method = 42
My_Type.extension_method self = 42

obj1 = My_Type.Cons_1 1
obj2 = My_Type.Cons_2 2

My proposition is:

• Members of obj1 should be just f - that is, only fields of the corresponding constructor.
• In similar way, only member of obj2 should be g.
• Members of My_Type shall be [Cons_1, Cons_2, instance_method, static_method, extension_method], that is, all methods and all constructors for the type.

For convenience, we can introduce a special internal member of atom called, say, _type_ that refers to its type and one could expand it in the debugger and see all the methods on the type, similarly to how, e.g., JavaScript does that via its [[prototype]] internal member.

[JaroslavTulach]

With 2024.3.1-nightly.2024.7.27 version I see in Chrome Dev Tools:

E.g. neither f or g field is displayed.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-10-06):

Progress: - Changing and testing the polyglot interop contract for Atom to support the debugging properly. It should be finished by 2024-10-09.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-10-07):

Progress: - Helping with aws-wrapper project in #10714 and fixing AWS_Tests

• Solving problems with module dependencies, service loaders, etc. It should be finished by 2024-10-09.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-10-08):

Progress: - Helping to fix more module-related issues in #10714.

• Trying to get the atom interop contract to the state before this year's April.
  • Atom members are fields and methods
  • Fields and (public) methods are readable and invocable. It should be finished by 2024-10-09.

[JaroslavTulach]

• please also look at Interop Atom's members test should return inherited members as well #6303

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-10-14):

Progress: - Helping Hubert with modularization issues - #11323

• Review of Jaroslav's minipass changes in Migrate some passes to Mini passes #11191
• Regression in stdlib benchmarks - Float.parse regression in org_enso_benchmarks_generated_Number_Parse_float_parse #11322
• Review comments fix and merging Show only fields from current atom constructor in the debugger #11217 It should be finished by 2024-10-15.

[JaroslavTulach]

I can confirm that the debugging experience in VSCode and runEngineDistribution --debug is great and doesn't need any urgent improvements!