3 ms·
Yes, I think so. In fact Haskell "effect systems" are a lot like "capability languages" in the sense that the restrict in a fine-grained way which parts of your
by tome 1y ago
Yes, I think so. In fact Haskell "effect systems" are a lot like "capability languages" in the sense that the restrict in a fine-grained way which parts of your codebase can perform which sorts of actions. My library Bluefin[1] takes this a step further and represents capabilities as value-level entities which you pass around to whoever needs the capability (and correspondingly, not to whoever doesn't need it). Bluefin calls capabilities "handles" (though I have wondered about renaming).
In fact, this passage from the article describes very closely what it is like to use Bluefin, yet I bet the author doesn't even know of Bluefin's existence! That makes me think I am on the right lines with my design.
> The first is that if you want the entire application to be written in an object-capability style then its main() method must be given a “god object” exposing all the ambient authorities the app begins with. You then have to write proxy objects that restrict access to this god object whilst implementing standard interfaces.
This part is too pessimistic, however:
> No language has such an object or such interfaces in its standard library, and in fact “god objects” are viewed as violating good object oriented design.
As you correctly point out, cryptonector, Haskell's IO is the "god object". It allows you to do roughly anything. And indeed Bluefin's runEff[2] gives you access to the god object (which is IO wrapped up in an effect (or "capability") called IOE). The rest of the program runs by "peeling parts off" this god object so it only uses the parts that it needs.
I have found this a very satisfactory way to program.
[1] https://hackage.haskell.org/package/bluefin https://hackage.haskell.org/package/bluefin
[2] https://hackage-content.haskell.org/package/bluefin-0.0.15.0/docs/Bluefin-IO.html#v:runEff https://hackage-content.haskell.org/package/bluefin-0.0.15.0...
- cryptonector 1y agoThank you. It's cool how the Java dev community keeps finding programming language theory in Haskell and folding it into Java.
- mike_hearn 1y agoI thought Haskell has unsafePerformIO? It's been twenty years since I learned any Haskell though! Bluefin looks cool but seems like by itself it's not a sandboxing system? Or where do you specify fine grained permissions with it?
- tome 1y agoYes, Bluefin is not a "high assurance system" in that regard. However, there is "Safe Haskell" which provides something along those lines. It is not widely used though. https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/safe_haskell.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/safe...
- cryptonector 1y agoSure, remove unsafePerformIO and you have a sandboxable language. THe point isn't that Haskell doesn't have an escape hatch. The point is that -as usual :)- Java is borrowing Haskell's best ideas [decades later :)]. It's a good thing.
- dllthomas 1y agoNit, but you also have to remove unsafeCoerce, some pointer stuff, and possibly a few other things.