Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
promises-spec
An open standard for sound, interoperable JavaScript promises—by implementers, for implementers.
No, it's "shell" as in "shell of the code". The idea is that the imperative bits of the language, the bits that do the mutation of state and the IO, can can call lovely pure referentially transparent functions. But functions can't call commands (otherwise by definition they wouldn't be pure). So all your imperative-ness is reduced to about 1% of your code which lives right at the top of your call stack --- the "imperative shell" of your code. See [here](https://github.com/tim-hardcastle/Charm/blob/main/examples/adv.ch) for an example. The "imperative shell" is the main function --- all 13 lines of it --- and everything everywhere else is pure and immutable.
I like it. Modern languages that distinguish between pure and impure programs like Flix, Koka, and Effekt do so on the type level instead of syntactically. This has three advantages:
I like it. Modern languages that distinguish between pure and impure programs like Flix, Koka, and Effekt do so on the type level instead of syntactically. This has three advantages:
Advantage 1, nesting, is the most important here, and it's often the most-overlooked advantage. Overlooking nesting is how Promises in Javascript got to be fundamentally broken.
Related posts
- Algebraic Effects: Another mistake carried through to perfection?
- Is continuation passing style conversion still used as an intermediate language?
- The Registers of Rust - Without boats, dreams dry up
- An approach to manual memory management and side effect handling system, feedback, ideas and thoughts requested
- Is there a garbage collected, statically typed language, that has null safety, and doesn't use exceptions?