Parametric polymorphism and async

Is it possible to write a function whose type is <A> (A) -> async A?

At the moment I get errors like type error, async has non-shared content type A/52

This makes me think there’s a way to say that A must be constrained to the set of values that are shared but I haven’t been able to figure out how to do that.

1 Like

We don’t support polymorphism for async functions. It has to be a concrete sharable type. There is no notion of type class, so we cannot constrain the type variable.

1 Like

Thanks Yan.

I think you’re saying this is a limitation of Motoko and not the IDL (probably because things will need to be specialized by then anyway)

Is that right?

I would say it’s the limitation of both. We need to extend both type systems to support this. It’s theoretically possible to transmit polymorphic values over the wire, but not a very high priority.

This was mentioned here:

and previously here:

You’ll have a hard time to get such a thing working with inter-canister messaging. While messages carry a self-describing type table, there is currently no mechanism to capture it in raw form and interpret it.

For strictly self-sends (i.e. private) such a signature would be simpler to implement in the compiler, since it can generate both sides of marshalling simultaneously. But what would be the utility to it?

@ggreif I think at the time I was attempting to write something akin to do notation in user space for monadic values, and this came up.

I think the gist of it was to force unwrap optional values and short circuit by catching them and returning.

I think Motoko has a version of this built in now, but only for optional values. what I was attempting would have potentially worked for Result and others.

1 Like