IDL resolution to know if a call is a query or an update
utility functions?
debugging features?
Comments from @chenyan-dfinity:
I would prefer we narrow the scope to just define the interface for calling/querying canisters, not going for REPL. Note that in this REPL, the only thing you can do is to make function calls to canisters. There is no notion of environment, no stateful computation. Everything can be done as a one-liner in CLI command.
For 2, IDL already supports this, e.g.
service s {
f: (nat) -> (nat) query;
g: (nat) -> (nat);
}
f is a query function and g is an update.
Definitely no for 1,3,4. I think we are conflating two different concepts here: CLI and the Motoko language.
Motoko already has REPL, stdlib and debugging support. It’s fair to ask for more features, but I don’t see any features that are not possible at the language level, and requires CLI support.
CLI should be language neutral. We are going to support Rust soon. Making a repl or query syntax similar to Motoko is not friendly to Rust developers. That’s exactly why we design the IDL syntax to be different from Motoko.
To be language neutral, CLI should only understand IDL, and treat Motoko and Rust as blackbox. The only thing IDL allows is to send/recv messages. Having a REPL is not going to buy us more features. We can of course send different messages to the canister to debug for decoding, encoding, and subtyping, but that’s all handled in IDL, and CLI should not worry about these things neither.
From the JIRA ticket:
Comments from @chenyan-dfinity: