Context.getVar failing compilation (and likely can't be deserialized)

[kushti]

test for method-call version of getVar (you can put it in BasicOpsSpecification) is failing compilation

property("getVar") {
    test("getVar", env, ext,
      "{ allOf(Coll(CONTEXT.getVar[Boolean](trueVar).get, true, true)) }",
      AND(GetVarBoolean(booleanVar).get, TrueLeaf, TrueLeaf).toSigmaProp
    )
  }

(and all the method calls with parametrized types as well)

Also, after fixing compilation serialization will be failed for Context.getVar[T] , as MethodCallSerializer is not serializing and so not able to restore T

[aslesarenko]

This is a limitation of MethodCall (see this ScalaDoc)

Specifically for this use case, since CONTEXT is singleton, every CONTEXT.getVar method call can be (and should be) compiled down to GetVar node, thus eliminating this specific MethodCall. Other method calls would still be supported.

The elimination would even work in lambdas like def f(ctx: Context) = ctx.getVar[Int](1).get, because every Context instance is the same object reference, so the lambda will be transformed to def f(ctx: Context) = GetVar[Int](1).get where ctx is just ignored.

Added a new issue https://github.com/ScorexFoundation/sigmastate-interpreter/issues/980

[kushti]

This is limitation of MethodCall, because we cannot use it to represent for example

• def Box.getReg[T](id: Int): Option[T], which require serialization of expected type T
• However it can be implemented using separate node type (new type code) and can be added via soft-fork.

Not necessary, see deserializeRaw implementation

Specifically for this use case, since CONTEXT is singleton, every CONTEXT.getVar method call can be (and should be) compiled down to GetVar node, thus eliminating this specific MethodCall.

You can replace method call with GetVar in compiler, but then what to do with the method itself, it is still available.

[aslesarenko]

You can replace method call with GetVar in compiler, but then what to do with the method itself, it is still available.

Well, if we will have either PolyMethodCall of just generalized MethodCall itself supporing types serialization then we can have CONTEXT.getVar as MethodCall in the ErgoTree and execute it at runtime. So lowering will be a compilation option (on or off).

In such case this issue can be fixed completely.