invokeMember should behave the same as readMember.execute

[JaroslavTulach]

Pull Request Description

Turns out new version of GraalPy uses readMember . execute instead invokeMember. The silent assumption is that these two approaches yield the same result. That wasn't the case in Atom so far. This PR fixes that by binding self to a function returned from readMember interop message.

Checklist

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

• All code follows the
  Scala,
  Java,
• Unit tests have been written where possible.

[Akirathan]

If I understand your PR correctly, you basically ensure that if we read at atom method member via interop, we get a method that has the self preapplied. This kind of makes sense. Note however, that the intended contract for atom members, is that all methods are internal members. So I am wondering why does GraalPy read our internal Atom members?

[JaroslavTulach]

The best is to ask the authors, but ...

all methods are internal members. So I am wondering why does GraalPy read our internal Atom members

...as far as I see by looking into sent messages there is no call to isMemberInternal at all. Neither in version 24.0.0 nor 24.2.0. E.g. GraalPy doesn't care whether a foreign member is internal or not.

However, according to the java of isMemberInternal:

Internal members are only relevant to guest language implementations and tools, but not to guest applications or embedders

We certainly want GraalPy to invoke methods on Enso objects. Thus either:

• GraalPy continues to ignore isMemberInternal
• Enso methods cannot be isMemberInternal

It is doesn't really matter if GraalPy uses invokeMember or readMember . execute. That's completely orthogonal question to isMemberInternal.