add service initialization parameters

[chenyan-dfinity]

Discussed in dfinity/motoko#1549. This adds initialization parameters to the higher order case as well. Since this requires changing the binary format, better to change it now than later.

[rossberg]

Don't you need to say something in the serialisation and value sections as well? Even if it is just that references uninitialised services are not supported at the moment.

[rossberg]

Hm, it may be good to make the difference more explicit. The parameters aren't just "optional". If they are present, the type describes a different kind of entity. That probably deserves a separate paragraph.

[chenyan-dfinity]

I wonder if { <methtype>;* } should just be a sugar for () -> { <methtype>;* }? So the presence of parameters represents different stages of the service: uninitialized vs installed

[rossberg]

In what context? In general, they are totally different things, the former typing a canister reference, the latter a Wasm module. They are no more related than Nat and () -> Nat.

[chenyan-dfinity]

In the sense that the did file generated by Motoko is only a Wasm module. It becomes a canister only after installation. So the actor from Motoko is always () -> service.

[rossberg]

We should also allow forming

... | <tuptype> -> <id>

where <id> refers to an initialised actor type.

[chenyan-dfinity]

Should we? It's symmetric with functions, which don't allow <tuptype> -> <id>. What does (nat) -> service (int) -> { f: () -> () } mean? Initializing this service gets another uninitialized service?

[rossberg]

Oh, I didn't suggest that you can nest them, thus initialised actor type. Only that you can write this:

type A = service {...};
type B = service (Nat) -> A;

The id can only be a non-arrow type, i.e.,

type C = service (Nat) -> B;

would be an error.

[crusso]

Hmm, I don't see why we are going higher-order now, when it is unnecessary and won't be supported for a while. What was wrong with the original proposal from the discussion:

<prog>  ::= <def>;* <actor>;?
<def>   ::= type <id> = <datatype> | import <text>
<actor> ::= service <id>? : (<tuptype> ->?)  (<actortype> | <id>)

without extending <actortype> itself.

(dfinity/motoko#1549 (comment))

This doesn't require introducing (first-class) types for classes (nor any wire format) and just adds the possibility of parameterising the main service.

[chenyan-dfinity]

I don't see why we are going higher-order now, when it is unnecessary and won't be supported for a while.

Because the higher order case is a breaking change for wire format. Better to change the format sooner? Otherwise, we can just extend the main actor.

[crusso]

I don't see why we are going higher-order now, when it is unnecessary and won't be supported for a while.

Because the higher order case is a breaking change for wire format. Better to change the format sooner? Otherwise, we can just extend the main actor.

Fair enough, maybe that should be @rossberg's call.

[rossberg]

I'm fine "reserving" the syntax and wire format already. I'm also fine restricting for now. I'm not yet concerned about adding extensions to the format that are technically breaking changes. Ones we're live that becomes more of an issue.

What would it actually take to support the higher-order case? The wire format of a service constructor would just be the blob containing the Wasm module, wouldn't it? If that's all then it seems pretty straightforward.

[crusso]

I'm fine "reserving" the syntax and wire format already. I'm also fine restricting for now. I'm not yet concerned about adding extensions to the format that are technically breaking changes. Ones we're live that becomes more of an issue.

What would it actually take to support the higher-order case? The wire format of a service constructor would just be the blob containing the Wasm module, wouldn't it? If that's all then it seems pretty straightforward.

Yeah, I'm not sure about that. Ideally you'd probably just want it to be the id/address of some installed code, not the code itself, but who knows. The current model of literally passing the code around and duplicating at each instantiation seems unfortunate to me, though it's the only method of instantiation we have at the moment. To my mind, installing a service module should install the code once and return a reference to a constructor that peels off fresh instances sharing the code, but providing new instance data/state.

[rossberg]

Yeah, I agree that it would be nicer if the platform had a way to reference modules, though I doubt we'll see much excitement for that from the execution team. The easiest way to get there might be by providing an inefficient version of the feature and wait for performance pressure from actual use cases. :) Then we can still extend the wire format to support both ways of passing it.

[chenyan-dfinity]

If breaking changes are not a concern for now, I would prefer to restrict the change to main actor for now. I don't fully understand the higher order case, as it is tied to the question of where we store the candid file. PTAL.

[chenyan-dfinity]

Do we want to merge this?

[nomeata]

I guess. I wasn’t part of the discussion the last two weeks, so maybe @crusso can make that call. But the PR as it stands seems innocent enough.