IDL-AS mapping spec

[nomeata]

I tried to first list goals (including reasonably formal ones), maybe
lets focus on them first.

I also want this to be a blueprint for other languages. In particular,
in how we handle types that exist in one language but not the other
(Char in one direction; float32 in the other).

Not done yet: The tooling interface and workflow specification (should
it be in this document or somewhere else?)

[nomeata]

The current specification exports Char as text, and traps when reading a wrong value; this is good enough for round-tripping AS values. Can we do something better? Maybe export to different types depending on whether we are in covariant or contravariant position?

(This question is less about Char in particular, but more about the general way of handling host language types that can’t be expressed precisely in the IDL)

[nomeata]

Hmm, thinking more about how to actually use the IDL, I can see how things work when we use the exported IDL that was exported from ActorScript, because the compiler has the ActorScript type, and thus knows the IDL type, and can do serialization/deserialization accordingly and correctly.

But how about the import story? Consider foo.didl with

service foo : { getInt8 : () -> (int8) }

if we translate that to

type foo = actor { getInt8 : () -> async Word8 }

then how would an actor instantiating this type know that it has to send a value of type int8 and not nat8?

Should we make e injective and simply not support any IDL types outside the range of e? But that would be unfortunate.

Or should we have a type constructor service <actor> : <typ> that embedds the IDL types into the ActorScript type system?

[rossberg]

Generally looks great, but I suggest modifying a couple of cases of the mappings.

[crusso]

Hmm, thinking more about how to actually use the IDL, I can see how things work when we use the exported IDL that was exported from ActorScript, because the compiler has the ActorScript type, and thus knows the IDL type, and can do serialization/deserialization accordingly and correctly.
But how about the import story? Consider foo.didl with
service foo : { getInt8 : () -> (int8) }

if we translate that to
type foo = actor { getInt8 : () -> async Word8 }

then how would an actor instantiating this type know that it has to send a value of type int8 and not nat8?
Should we make e injective and simply not support any IDL types outside the range of e? But that would be unfortunate.
Or should we have a type constructor service : that embedds the IDL types into the ActorScript type system?

Hmm, this is actually an interesting observation. In a traditional IDL, the client would implemented the interface using a generated skeleton library that does the marshalling according to the IDL type, not its projection into the language type system. I guess the simplest fix would be to extend AS with all the types and minimal set of operations we need to make e injective. Languages that rely on generated skeletons from IDL won't really have this problem, will they?

[nomeata]

In a traditional IDL, the client would implemented the interface using a generated skeleton library that does the marshalling according to the IDL type, not its projection into the language type system.

Note that we are talking about the server here, not the client. But yes, this would of course work too: didlc foo.didl could, for example, turn

service foo : { getInt8 : () -> (int8) }

into

// foo.as
import FooImpl "foo-impl.as";
actor class foo() {
  private iml = FooImpl.foo();
  getInt8 () : async Word8 {
    @magic_serialize_Word8_as_int8(impl.getIng8)
  }

and the programmer can then fill in

// foo-impl.as
class foo() {
  getInt8 () : Word8 {
    …actual code…
  }

(I am using two files to avoid telling the developer to edit a generated file).

But that's ugly, and I am not sure if creating these synthesized wrappers actually works in the higher-order case, where you pass functions around.

I guess the simplest fix would be to extend AS with all the types and minimal set of operations we need to make e injective.

…in order to make i the inverse of e, right?

That would require e to be injective and surjective (it can still be partial).

I agree that many things would be easier to explain if we can make the mapping from AS types to DIDL types injective and surjective.

Languages that rely on generated skeletons from IDL won't really have this problem, will they?

What about the higher-order case? Is there a problem or does it work?

[nomeata]

Summary from the phone call: We will extend AS with Int8…, make the mapping i injective, and e its inverse, and then many of these problems go away.

[nomeata]

Ok, did a revision based on the phone call where i is injective. This solves some of the fundamental questions we had about how to actually implement this.

[nomeata]

@rossberg PTAL

[rossberg]

Looks good, except for the argument issue. But see suggestion below.