3 ms·
Yeah, I should have elaborated. Like, fundamentally you want to express "caller has capability x", and coloring does that. But coloring isn't ergonomic, so some
by staticassertion 4y ago
Yeah, I should have elaborated. Like, fundamentally you want to express "caller has capability x", and coloring does that. But coloring isn't ergonomic, so some languages try to infer their way out of it or hide it. But I'd rather they instead just make these things more explicit and lean into it a bit more, like in a capabilities system.
- ghoward 4y agoI actually thought of another way to do it. In the "real code" I linked to in the post, I have a concept I call "context stacks". The idea comes from Jai, and I use to do implement things such as error handling and allocators in such a way that functions don't need to take an allocator argument. To make callees use your allocator, you push your allocator onto the allocator context stack and then call the functions you want to use that allocator. I made it useful for many more things, and users could add their own. In particular, I realized that it could be extended to where functions could get permissions (such as popping up an Admin dialog box on Windows or asking for sudo on Linux), push a capability [1] onto the capability context stack, and then call the functions that actually do the work. These functions could then grab that capability and do what they need to do. One good thing about this is that permissions don't leak up to callers that should not have them. In other words, this system keeps permissions from infecting code that really shouldn't have them, but might need them because they might call functions that do. I don't know if all of this made sense, sorry if not. I wrote it really fast. [1]: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security