What's the appeal of taking pure functional all the way to an executable tautology? Inputs can be passed around in a pure FP world without reducing purity, so why remove them?<p>We never got around to output at all. Assuming the compiler can't write the output file before the program runs, how would you see the result of any program run in this world?<p>What about UI or network input?<p>I'm imagining that if only the compiler were allowed to do I/O, I'd have to rebuild Chrome whenever I wanted to see a new site, or even see an update to a site, or change my preferences. Wait, scratch that, I can't change preferences, because it can't save. Is the shell allowed to do I/O? What about output to the monitor, does that count? It's not a file, but it's Turing equivalent to an output file.
I don't understand the article. It's still input and output but in a more convoluted way and therefore better? Reminds me a little of articles you see from time to time like "if-less programming".
So, I am missing how this would work.
Let me pick 2 examples.<p>The first is about networking. How would I build, say, an http server in this thing? From the rest of this thread, it seems like you would advocate essentially a separate compiler for networking, and to 'read' from a socket, you just import. That seems like you are moving a lot of complexity to the world of compilers.<p>Moreover, I don't see any way to then 'write' to that socket. Does the compiler essentially take a return value of main and then say 'well, guess this is what I want to send back'. That would suggest you can't do something like 'recieve handshake' 'send handshake' 'receive request' 'respond to request'. It seems to block interspersing input with output.<p>My second example is a gui. It feels to me like your program couldn't in any way define the interface layout. All it could do is 'receive' and 'issue' events. It would take a specialized compiler, and a whole separate mark-up language to actually define the interface. How do you change the interface in response to input?<p>I love pure code, and see the value in pushing the boundary of pure code as close to the edges as possible. However, code still needs side-effects to be useful, and I'd like to specify those side-effects in the same language as I specify my pure code. I'd like to decide for myself how far out to push the boundary of purity.
Like others i do not understand this article.<p>It seem to propose an abstraction where we separate the I/O part from the "elaboration" part of a programs, so that our programs are entirely pure.
But i don't understand why the import system and why only the compiler can read and write?<p>Why can't we have the same benefits by using multi-threading/process? we can have "pure" thread and "i/o" thread that communicate with message passing? i feel like I'm missing something from the article.
Perhaps I simply didn't understand the argument, but doesn't this simply move reading and writing to a different abstraction? Perhaps someone can reword the author's point, I feel like I'm missing something here.
Excellent, I've actually been working on something similar and I'm glad to see it validated.<p>As I expected though, most people in this thread don't get it, which is understandable since it's pretty out there compared to the mainstream. I think they will once larger, "real" programs are written.<p>I don't think I'm gonna be able to "reword" this for people here so it suddenly clicks, you're probably just going to need to see it in action to understand it.
Dismissing inputs for the moment: if you cannot write or transmit outputs, how does your program actually perform anything. If your answer is "side effects", you've merely redefined the term "outputs".<p>As I see it, you'd have to have a program which was supplied its input, by the compiler, was evaluated by the compilier, and had its output imputed, by the compiler. You've only shifted the problem of input and output sanitisation elsewhere.