SPICE-0021: Binary renderer and parser

[HT154]

No description provided.

[bioball]

Hm.. I don't feel that we need this parameter. We should either:

1. Use the enclosing module from the caller as "context" (we should be able to do this by special-casing InvokeMethodVirtualNode and passing in extra arguments)
2. Don't run trust level checks

The trust levels concept is a mechanism that is designed to prevent, say, an HTTPS module from importing a file-based module, with no opt-out. If we have this parameter here, I think the most likely outcome is that users will just keep trying to pass in another "context" until the parse call works.

[bioball]

Worth clarifying: there's user-facing values (org.pkl.core.PClass, org.pkl.core.TypeAlias, etc), and there's in-language values (org.pkl.core.runtime.VmClass, org.pkl.core.runtime.VmTypeAlias, etc).

The in-language parser should decode to these VmValues, and the user-facing API should provide the exported value (e.g. PClass).

We'll probably need two classes; a VmPklBinaryDecoder (internal) and a PklBinaryDecoder (user facing).

Also, we should think about how this plays into ConfigEvaluator and Java/Kotlin codegen.
With codegen, you write this Java code:

try (var ev = ConfigEvaluator.preconfigured()) {
  return ev.evaluate(mySource).as(Person.class);
}

How does this work when you are working with pkl-binary?

[bioball]

The purpose of the binary encoding is so that we can eschew any evaluation. It's kind of strange that the binary decoder would still require an importer.

Also: it should receive either a Buffer, byte[] or ByteArrayInputStream as a source, rather than MessageUnpacker. Probably good enough to have:

I don't know if parse needs to be an instance method, should be good enough to make these static, e.g.

public final class PklBinaryDecoder {
  private PklBinaryDecoder() {}

  public static Object decode(byte[] bytes) {
    // impl
  }

  public static Object decode(ByteArrayInputStream inputStream) {
    // impl
  }
}