3 ms·
Wow I’ve been thinking of something exactly like this! Sort of a super charged, statically typed version of Go’s context.Context. It would allow you to describe
by et1337 2y ago
Wow I’ve been thinking of something exactly like this! Sort of a super charged, statically typed version of Go’s context.Context. It would allow you to describe the capabilities (or effects) of every function, including IO, memory allocation, cancellation, deadlines, concurrency, and whatever application-specific stuff you need on there (like logging).
Then you could implement something like Google capslock [0] just by looking at type signatures.
0. https://github.com/google/capslock https://github.com/google/capslock
- ordinaryradical 2y agoDo itttttt :)
- wahern 2y agoSee also aspect-oriented programming (AoP): https://en.wikipedia.org/wiki/Aspect-oriented_programming https://en.wikipedia.org/wiki/Aspect-oriented_programming Algebraic effects might be a little too strict and narrowly defined for something as generic as, e.g., injecting ad hoc logging. With algebraic effects you need to reify in the type system the specific control flow behaviors you care about, and then get code to use those types and operators accordingly. AoP seems like a higher-level (if looser) concept that isn't necessarily specifically bound to the particular details of the type system. That modeling freedom seems necessary unless you're creating a language from scratch or confining yourself to a very limited set of control effects that can be shoe-horned into the existing type system and control flow operators.
- valcron1000 2y agoYou already have something like this (production ready) through effect systems in Haskell (ex. https://hackage.haskell.org/package/effectful https://hackage.haskell.org/package/effectful)
- bandrami 2y agoLike clockwork, every few years, smart people will re-invent introspection.