Second question - I’d like to enforce, at compile ...

# announcements

[Rob Elliot]

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.

[Marc Knaup]

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

[Rob Elliot]

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

[Marc Knaup]

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.

[Rob Elliot]

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?

[Marc Knaup]

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.

[Marc Knaup]

And Kotlin/JVM libraries could import other pure Java libraries that in turn use I/O or do dynamic stuff.

[Rob Elliot]

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.

[Marc Knaup]

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.

[Marc Knaup]

There’s a YouTrack issue for pure functions. If your libraries only contain pure functions they’d basically be pure libraries, wouldn’t they?

[Marc Knaup]

hmm no, that would make it difficult to maintain internal state

[Rob Elliot]

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.

[Marc Knaup]

https://youtrack.jetbrains.com/issue/KT-22507

[Rob Elliot]

Thanks, commented and voted

[Rob Elliot]

Managed to get a SecurityManager working with only the permissions necessary to evaluate a script that creates a data class instance:

https://gist.github.com/Mahoney/8979e520b7477c9a9771fe3e1da3472a

[Youssef Shoaib [MOD]]

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