Motoko vs. System mismatch

[nomeata]

This issue is not really a single actionable issue, but more like an overview we use as a wiki and discussion cound. Once we know what we want to do about one of these, creating a separate issue or JIRA ticket (and link it from here) might be more appropriate.

System features not exposed in Motoko yet (as syntax or library):

• Non-linear async control flow (#942)

System features to come, but no design for Motoko yet:

• Randomness https://github.com/dfinity-lab/actorscript/issues/649
• Ingress message cost control (https://github.com/dfinity-lab/ic-ref/pull/3)
• Payments
• ~Declaring static gas costs per message~

Motoko features that the System (as currently envisioned) does not support:

• Non-top-level actors [deferred, but on the horizon]
• Local (anonymous) shared functions [deferred]
• Local (anonymous) shared functions capturing variables [deferred, needs seals]

Features in Motoko that are not yet in the System but that we can fake

• One-shot methods
• Passing public actor and function references

Features neither in the System nor in Motoko:

• Sealed values [deferred]

Anything else?

For the latter we need to decide if we want to

1. keep them in the language, but the compiler says “can’t do that” (e.g. in the typechecker)
2. remove them from the language, or
3. work towards adding them to the system

[nomeata]

First-class async values that can be await’ed on in unrelated calls (cross-call-tree control flow)

Based on phone call, best guess so far, it seems: Only allow await directly on shared function calls.

[matthewhammer]

Thanks for writing all of this down!

Anything else?

The stable annotation, and all associated language/system design around orthogonal persistence, and long-term state management in the face of dynamic canister upgrades.

[nomeata]

Feel free to edit the list above, i.e. treat it like a wiki (but good to also comment, to trigger notifications)

[matthewhammer]

Cool; just added:

• stable, either as an annotation, or as the default; Wasm VM support to make this real?

[rossberg]

I added upgrade hooks and made some tweaks. Also added annotations indicating our current plans, as far as they exist.

What's the "declaring static gas costs" thing, and how does it make sense in the gas models that have been discussed recently?

[nomeata]

What's the "declaring static gas costs" thing, and how does it make sense in the gas models that have been discussed recently?

Not sure what’s the most “recent” one? I know about https://docs.dfinity.systems/spec/client/sub_scenarios/gas_accounting/index.html, which has concepts like

ExpectedBalance(m: method) : Gas returns the minimal execution balance that the canister offering method m expects from the user.

Price(m: method) : Gas returns the fixed price (in GAS units) of a method call as specified by the respective canister. This price should ideally cover the execution costs as well as the total messaging costs caused by outgoing messages.

MinimumPrice(m: method) : Gas returns the minimum amount of gas needed to execute method m, as specified by the respective canister.

OfferedPrice(M: msg) : Gas returns the minimum amount of gas offered by message M, which can be an ingress or cross canister message.

SubsidyRate(m: method) : f32 returns the multiplicator by which the canister is willing to top up outgoing messages when its method m is called. The value must be greater than or equal 1. A subsidy rate of 2, for example, means that the canister will double the gas amount attached to outgoing messages from its own internal balance.

Subsidy(m: method) : Gas returns the amount of the subsidies assigned by the caller to the called method. This function allows to allocate the gas ("change") returned by callee.

So there clearly is the assumption of declaring static prices.

Other (maybe only verbally discussed) ideas even involve programmatic interaction with gas, e.g. checking how much gas is available for the current message and making decision based on that.

[nomeata]

Does [deferred] mean: We keep it in the language under the assumption that we will eventually (maybe post-launch) get support for them?

Local (anonymous) shared functions [deferred]

I think this also needs seals (or some other capability-like mechanism): Even if they don’t capture environment it would still be a big foot gun if the programmer (rightfully) thinks that these local functions are only be called by whoever they pass a refernece to, but they are actually compiled as normal public methods.

[nomeata]

Also, for some of the things marked as [deferred], we currently throw in the backedn or trap in the compiled code. We probably should catch these things as part of type checking with a helpful error message, right?

[nomeata]

Discussion about randomness: https://github.com/dfinity-lab/actorscript/issues/649

[rossberg]

Not sure what’s the most “recent” one? I know about https://docs.dfinity.systems/spec/client/sub_scenarios/gas_accounting/index.html, which has concepts like

Wow, that still looks ridiculously complicated. Do we seriously expect devs to specify these things??

Does [deferred] mean: We keep it in the language under the assumption that we will eventually (maybe post-launch) get support for them?

Yes. Hope dies last. :)

Local (anonymous) shared functions [deferred]

I think this also needs seals (or some other capability-like mechanism):

Yeah, I wasn't sure how exactly it differs from the item on passing function references.

[nomeata]

Wow, that still looks ridiculously complicated. Do we seriously expect devs to specify these things??

I keep telling people that this is unrealistc, but I am not sure about how convincing I am…

Yeah, I wasn't sure how exactly it differs from the item on passing function references.

We could have function references that exclusively reference public functions; (maybe not very useful without anonymous shared functions). Also, you could have anonymous shared functions without being able to pass function references, i.e. for self-calls to implement async {…}. Or, even useful: To put “commit points” into your code where you commit the state but then keep executing.

[rossberg]

We could have function references that exclusively reference public functions

Right.

Also, you could have anonymous shared functions without being able to pass function references

Makes sense, these cases are reminiscent of having private actor methods.

[nomeata]

As per meeting with Dom, adding

• (Statically) importing canisters
• (Dynamically) turning canister ids into actorref
• Access control

[rossberg]

Thanks. Wouldn't the 2nd item need some system support as well? To acquire the IDL type at runtime or something? (Not sure such a mechanism is MVP material.)

[nomeata]

No, on the system level there is no IDL, and a canister can of course just send some bytes to some other canister. So the system supports everything what we need here.

And on the ActorScript level, I think it is reasonable to write code that takes a (dynamic) canister id and then treats it as an actorref of some (static) type. We don't need the actual IDL at runtime, but of course this degrated to gradual typing, so to say: If the user gives us a canister id of a canister whose type is not a subtype of the statically used interface, then some calls will fail with IDL errors.

A use-case might be a messaging server canister that a user can send the id of a canister that implements your chatbot. The messaging server knows the interface that it expects from the chatbot canisters, the assumption being that they all implement this interface. So it doesn’t need to lookup their actual interface (which may provide other messages, for example) and can still usefully talk to them.

[nomeata]

The discussion about dynamic use of canister ids is now at https://github.com/dfinity-lab/actorscript/issues/667

[nomeata]

Passing actor references via method calls [deferred]

The IDL kinda mandates the ability to put canister references in messages. Should we put the IDL through the design approval process, to get clarity from the org if we want that, and so that we can make it a requirement on the System API?

[nomeata]

This discussion seems to be moved into the “Investigate boundaries between Language and Execution” meetings.

[nomeata]

I’ll still leave this open, it is a useful laundry list for things from our side of things.

[nomeata]

Updated the description of this. looks a bit nicer already. Look at the “edited” drop down for a diff.

[nomeata]

Updated the list. Looking better now.