3 ms·
> This means you either have to pass around permission-to-sleep or you need additional function colors I wonder if it's possible to do this better. Somehow ap
by eqvinox 4y ago
> This means you either have to pass around permission-to-sleep or you need additional function colors
I wonder if it's possible to do this better. Somehow applying the type system onto the "execution context" feels like it would be the "ideal" solution here. From just 2 minutes of superficial thought, it would really be quite similar to permission-to-something tokens. Just a bunch of syntactic sugar on how it's done, plus making it easier to extend for additional tokens/colors/...?
- ameliaquining 4y agoI think you want something like https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capabilities/ https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capa.... The Rust maintainers have expressed interest in this possibility, but I don't think there's anything concrete yet.
- JonChesterfield 4y agoThat ^ is interesting in that it's (a syntax heavy version of) dynamic scoping with an implicit restriction that the call graph must be static. I.e. as described that does not work with function pointers (there is a todo reference to 'dyn', which looks like it means vtable dispatch, i.e. a special case of a function pointer call). This suggests a general pattern given the above on memory allocation - some things are expressible on static call graphs. On dynamic call graphs, they need to either fail (could be at compile time) or induce a runtime cost.