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?
Conversation
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
What do you mean by best effort?
2
As in: only when the compiler can infer that it's permitted to do so. I don't think this generalises very well because the compiler needs to keep track of the entire call stack, even in the presence of callbacks and conditionals and other weirdness like like that
2
Is this like… binding time analysis? Sorry not really great at back-end stuff. If so, have you looked at stuff like staging? There are a few approaches you can do, for this, but it amounts to being able to statically analyse when code is partially evaluated.
1
I'll do some reading, although from a cursory look I don't *think* staging really addresses this (at least, not in the general case).
2
Yeah, my understanding is that it's more about knowing when to generate code - what is statically known vs. what is dynamic at a specific point in time.
1
1
Can be useful for getting control over either offline (compile time) or online (runtime) partial evaluation. But might not really be what you're after. Sounds like you want to generalise over an unknown call stack?
2
Sounds *potentially* it might be like contextual types but I dunno. I could be misunderstanding again (I often do as I often misread stuff 😵💫). Moebius is a recent example of this:
1
1
Although I hear you can really just use functions for this if you don't need the pattern matching.