dfinity / sdk

IC SDK: a Software Development Kit for creating and managing canister smart contracts on the ICP blockchain.
https://internetcomputer.org/docs/current/home
Apache License 2.0
178 stars 86 forks source link

A developer can interact with their canister in a REPL #504

Closed ghost closed 3 years ago

ghost commented 4 years ago

From the JIRA ticket:

Things to consider:

  • simple syntax or full Motoko repl?
  • 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.
p-shahi commented 3 years ago

https://github.com/chenyan2002/ic-repl supports this