Inputs in a purely functional world are limited to things that you can serialize and deserialize, which does not include functions or types. If you ingest values via imports instead of via traditional I/O then you can transmit any language feature

You're right that I didn't get to output at all. That's my mistake since I wrote the post in a hurry. The idea is that the interpreter of this language is not a general purpose compiler but is a specialized application with a built-in output. For example, one such interpreter might be a browser that just displays the result to the user.

Using Chrome as an example, the Chrome executable would be an interpreter. Chrome itself would be compiled. For simplicity I'll assume that we browse static HTML pages. Your URL bar would be replaced with a code bar that accepts any arbitrary Dhall expression that builds a DOM. However, since Dhall accepts URLs in place of expressions it is still a URL bar (as long as the URL you input refers to an expression that assembles a DOM). The browser would then interpret that expression to build the DOM and render it as a web page

There are several ways you could configure preferences but I'll throw out a simple idea just to convey the point. Chrome itself could be configured via a Dhall expression that assembles a giant record of user settings. Since a Dhall expression can also be a file you can configure user settings via a path to a file (as long as that file you refer to contains an expression for building that record). That file could itself contain references to other files in order to delegate the configuration of certain options.

That's not the only way you could do it, though. Web pages could be pure functions of user settings, too. CSS would just becomes a special case of treating a DOM as a pure function of style settings.

UI or network input is trickier, not because it's hard to model UI or network input in a purely functional setting but rather because you want to do it in a different way on a case-by-case basis. For example, some types of UIs are unchangeable requirements that you have to adapt to (like a game: the UI is the requirement). However, other forms of UIs or network input are just work-arounds for inability to compose code effectively. For example, batch network input can be replaced by just importing URLs as code. Similarly, batch user input can be replaced by just importing files as code.

All inputs are serializable, including functions and types. We can already transmit language features without imports.

If you compile your inputs into your program, what you're left with is a fancy constant. You might as well let the compiler take the final step of running the program for you and printing the output.

If you think Dhall is great and more people should use it as their I/O library, that's awesome, maybe show some of the cool things it does. Motivating it's usage by trying to make I/O a functional vs imperative issue just seems really contrived, and mostly wrong and prone to argument. I/O isn't a functional issue, and it is one of the main reasons to write a program: to do some work parameterized over different inputs.

Your program can be a pure function which somebody else can invoke, so it's not necessarily a constant

However, Dhall does have the ability to normalize under lambda when possible so it will actually do this for you if it can! For example, if you try to interpret this program, which is a function:

        let replicate = https://ipfs.io/ipfs/QmQ8w5PLcsNz56dMvRtq54vbuPe9cNnCCUXAQp6xLc6Ccx/Prelude/List/replicate
    
    in  let exclaim = λ(t : Text) → t ++ "!"

    in  λ(x : Text) → replicate +3 Text (exclaim x)

The interpreter will simplify that down to:

    λ(x : Text) → [x ++ "!", x ++ "!", x ++ "!"] : List Text

... although it can't do anything else until somebody else comes along later and calls the function on a specific input

Chrome already ships a compiler today. Why wouldn't it continue to do so in your hypothetical?

Are you referring to the JavaScript compiler? I don't understand your point, would you elaborate? The article is about factoring out all inputs from a program. Chrome's compiler is used to compile new inputs on the fly, it's reason for existence doesn't seem to mesh with the author's goal.

FWIW, I'm trying to imagine the author's hypothetical. If you think I'm imagining something other than what he proposed, I'm all ears!

> 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.

Chrome IS the compiler. Your preferences are a program provided as input. Websites are programs provided as input. You wouldn't need to rebuild Chrome to change things.

Can you elaborate on what you mean?

How would I save my preferences?

Do all websites have to be compiled as programs first, so they can be input as programs into new Chrome?

If my websites were provided as input and compiled into Chrome, how do I avoid rebuilding Chrome when the websites are updated?

If Chrome is the compiler, then Chrome is allowed to do all the I/O it wants, just like it does right now?

I mean, at some point you're just asking me to implement it for real, but I'll give you some hand-wavy answers:

You save your preferences the same way you might save `jquery.js` on your computer.

Chrome IS the compiler, you don't need to compile them first to give them to Chrome.

I'm not sure what you mean by "compiled into Chrome". Since when you do compile a program "into" the compiler? Look, your browser probably JIT compiled a dozen programs just for you to be able to view this page and comment. Did you need to rebuild Chrome?

Yes, Chrome is doing the IO. Importantly, the page is NOT doing the IO. So, there's no XMLHttpRequest, for example.

To make an analogy to Python: you don't need to recompile Python to interpret new Python programs. Chrome would be like Python: Chrome is itself a compiled program, but it interprets user settings and web pages.

Chrome is allowed to do whatever I/O it wants, but the programs it interprets (like user settings and web pages) are not allowed to do any I/O at all. These interpreted programs are sandboxed.

This isn't really surprising if you think about it. Chrome is already an interpreter for a sandboxed language (JavaScript)

A closer analogy to Dhall would be if web pages were assembled entirely from JavaScript instead of HTML, URLs were just pointers to Javascript expressions, and JavaScript code could refer to other JavaScript code anywhere within the syntax tree just by URL (instead of out-of-band via a <script> directive)

I don't know Dhall, but that sounds like what we already have. URLs are already pointers to JavaScript expressions, and many websites are already JS that constructs HTML... that's the main direction React is going, for example. The script directives are irrelevant, it'd be easy to show equivalence without them. And I don't see what any of this has to do with writing programs that don't read inputs or write outputs.

Right, and where I'm going with this is that we should take the JavaScript model to its natural conclusion and use it more pervasively in other domains. In other words, more applications and domains should be configured via sandboxed and interpreted programs that can easily reference other programs

However, the difference is that I don't think we should use an untyped and Turing-complete language for doing this (which is my primary objection to JavaScript). Also, I think the mechanism for referring to other programs should be more lightweight (i.e. just dump the path and URL into your code and you're done)