By saosebastiao
Have you ever used F#’s type providers? The idea of an external environment (for example, a Web API or a specific SQL database and schema) lifted directly into the type system is pretty powerful. I’m familiar with Slick’s typed SQL statements (currently using them in a project) which use a hefty dose of implicits and macros, and it kinda approaches the power of the SQL type provider, but its still incredibly clunky and trying to debug anything is a huge PITA.
A co-effect system is like a type provider on steroids: any aspect of the environment in which a system executes can be lifted onto the type system. This could be anything from GPU or specialty sensor availability to data security requirements.
It would allow for things like code sharing between a scala & scalajs without needing to set up complicated SBT code sharing projects. You would have a scalajs main, and a scala main, and any piece of code whose type is permissible in both scalajs and scala is automatically shareable. It would also allow for cross-executable optimization. There is often a lot of code that could be optimized away from current executables if the compiler only knew more about side effects. You could eliminate dead code that goes across a wire between client and server because knowing exactly what the client/server interactions are, the compiler can know what is actually dead code.
Maybe it is possible to do some of the above with some implicit wizardry that I’m just not familiar with, and maybe it could be done with compiler and build system tricks without modifying the base language, but honestly even if it could I would still prefer co-effects. It took me one read of a blog post to really grok co-effects, whereas I’ve been using Scala for well over two years now and still have trouble understanding how implicits are working in the code I’m using.
[1] http://tomasp.net/blog/2014/why-coeffects-matter/
Read more here: https://news.ycombinator.com/item?id=10720652
saosebastiao comments on "Why ML/OCaml are good for writing compilers (1998)"
No comments:
Post a Comment