Conversation

I wonder whether you could do this through an effect system. You could have an 'overflow' effect that can be handled in a manner easily and cleanly chosen by the caller.

1

Brendan Zabarauskas

@brendanzab

Oh, good idea! I guess in practice you'd need an effect system lightweight enough in terms of runtime overhead… which could be a tough ask at the moment? But could be fun to experiment with?

1

So this is something I've been thinking about with my effect system which in the process of being born (preliminary codegen & typing works). Right now, I implement it as stack-walking but one of my goals is to monomorphise *everything* (no runtime HKTs) a consequence of... (1/n)

1

...this is that generic effects (i.e: where generic parameters aren't specified in an effect type, such as async/await) codegen doesn't really compose and can only be done at a best-effort level. I am very unhappy with this, so I've been thinking of changing effect types to (2/n)

1

be more akin to impl Trait / existential types, thereby statically promising that monomorphisation (& also inlining) is possible. I need to do a lot more thinking about this though because I think it's going to have far-reaching consequences for effects in general. Any thoughts?

1

Brendan Zabarauskas

@brendanzab

Hmm not sure. Pretty interested in what Effekt does with this stuff - I think they compile to a representation where handlers are injected as parameters?

2

I think a problem with this is that, again, monomorphisation can only occur on a best-effort basis (unless these 'parameters' are generic, as in Rust's Fn traits)

1

Brendan Zabarauskas

@brendanzab

What do you mean by best effort?

2

Replying to

and

Ahh I see the tweet above

Quote Tweet