Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

As a library programmer, I want to pass type arguments so that I can write more generic/reusable libraries #53

Closed
matthewhammer opened this issue Jul 6, 2020 · 4 comments
Labels
enhancement New feature or request Spec

Comments

@matthewhammer
Copy link
Contributor

matthewhammer commented Jul 6, 2020

Is your feature request related to a problem? Please describe.

I want to write an actor/service like this in Motoko, with a corresponding Candid service type:

actor MapThing<X,Y> {
  put : (X, ?Y) -> async ();
  get : X -> async ?Y;
}

Leaving out some inessential details, this MapThing actor provides a service whose API is parametric in two types, X and Y, for a generic key and value type, respectively. It stores a dynamic map from Xs to Ys.

More generally, I want to author Candid services that use generic type arguments, and as a user, instantiate services by providing these types over the network.

Describe the solution you'd like

The solution here involves extending Candid, Motoko, as well as (perhaps) the Internet Computer itself.

Describe alternatives you've considered

Many systems and languages lack polymorphic types. The usual workarounds map a polymorphic design into a monomorphic one, somehow. For instance, we could assume a single choice of type for X and Y above, and try to provide a way to map into and out of these single choices (e.g., use [nat8] for all types and do extra layers of serialization, the current solution).

Additional context

None.

@chenyan-dfinity
Copy link
Contributor

This feels more like a service factory, rather than an actual service.

From MapThing<X,Y>, you can create canister MapThing<Int, Int> and canister MapThing<Text, Blob>, and they each can dynamically create sharded canisters of the same type. But you cannot put an arbitrary type X into a particular canister. In this sense, the actor factory is polymorphic, but the actual actor stays monomorphic. Or you have something more general in mind?

@matthewhammer
Copy link
Contributor Author

I think this stance makes sense, but I'm not certain that I agree (yet). Just to clarify, are you saying that type arguments are never an issue for Candid, and only ever for a language using Candid, like Motoko?

@chenyan-dfinity
Copy link
Contributor

I think it's still nice for Candid to support type arguments, but I'm not sure how useful it is for a container canister. Even for a local function, I don't know what to do with a generic HashMap<K, V>. Because you don't know the concrete type of K, you cannot put any real value into HashMap<K, V>.

@matthewhammer
Copy link
Contributor Author

#245 subsumes this discussion.

ninegua pushed a commit to ninegua/candid that referenced this issue Apr 22, 2022
Also include some cleanup of the scripts that arent used, and add a diagram for the
bootstrapping process.

This does not affect the worker yet. Only the first retrieve of the index.js on
localhost.

BREAKING CHANGE

If a canister has a retrieve() method that relies on Principal, the principal used
will change.

Co-authored-by: Benjamin Goering <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Spec
Projects
None yet
Development

No branches or pull requests

2 participants