Second question - I’d like to enforce, at compile time, that some compiled code does no I/O. Obviously I can control what dependencies are available to it, but is there a relatively easy way to (comprehensively!) exclude all Java & Kotlin stdlib classes that do I/O, directly or transitively, from compilation? I suspect no, but I do feel that being able to enforce at compile time a strong separation of concerns between code that does and does not do I/O would be useful.

No, you can’t. Only at runtime with either sandboxing or a Java

SecurityManager

Thanks. How does the client side javascript compiler do it? Code running in the browser only has access to very limited I/O.

Most I/O functions simply aren’t defined for browser target because there’s no way to implement them anyway. That’s at compiler-level. But any Kotlin/JS app or library could use any browser API that in turn allows I/O. No way to prevent that.

Do you think it would be possible to somehow combine the two approaches? Have a target which doesn’t define any I/O functions, but also not provide the browser APIs, and compiles to JVM bytecode?

You’d have to block way more than just I/O. You’d have to prevent the code from using lost of Java APIs to dynamically load code, create more classes, use native libraries, etc. If that’s supposed to be a safety feature then it’s probably a very risky approach. Sandboxing is way more reliable.

They could, it was more an architectural feature I was looking for - the ability to mark a library as entirely pure, and therefore any library that is itself pure and only depends on other pure libraries as pure, and have it verified by the compiler. Probably a pipe dream.

Probably doable. But you’d have to disallow lots of API for these libraries. May even be possible with a compiler plugin. But I don’t know enough about that.

For my purposes it would be fine for it not to allow mutable in memory state either. Immutable data classes would be pure too. I’m imagining a ports and adapters architecture where the compiler could prove that the core & the ports are all pure and I/O only happens in the adapters.

Thanks, commented and voted

Maybe also take a look at arrow-fx-continuations which basically allows you to mark IO functions as suspend and so any non-IO functions are just normal functions. It should hopefully at the very least provide that level of purity that you need, but obviously a huge part of it comes down to self-discipline