Pure-functional terminal I/O provides 4 instructions:
1) Write (Out)
2) Write (Err)
3) Read [single character from standard input]
4) ReadLine [line from standard input]

Terminal programs are constructed using LINQ syntax.

For example, the previous program (not pure-functional):

    var x = Console.ReadLine();
    Console.Write(f(x));
    var y = Console.Read();
    var z = Console.Error.Write(y > 10 ? "hi" : "bye");

can be transformed mechanically to the following pure-functional program:

    from x in Terminal.ReadLine
    from _ in Terminal.WriteOut(f(x))
    from y in Terminal.Read
    from z in Terminal.WriteErr(y > 10 ? "hi" : "bye")
    select z

The general rule is that a function that previously returned type T, now returns type Terminal<T>, which can be composed with LINQ. However, critical in this implementation is that *equational reasoning is preserved*. In other words, it is _in fact_ a pure-functional program in that it is as pure-functional as any other pure-functional program.

This implementation has been achieved by using the free monad to encode the effect. This means that this kind of effect environment is incompatible with "the built-in C# modus operandi." Therefore, we introduce a single unsafe function (Terminal#Run) to essentially "fire the missiles." Ideally, a main method would have the type Terminal<Unit>, however, this unsafe interpreter function is provided only for compatibility with a more typical .NET environment. The existence of this function does not falsify the existence of pure-functional Terminal I/O as has been implemented. Indeed, it is a very valuable experiment to attempt to deconstruct a Terminal program in such a way to demonstrate that it violates referential transparency (this will ultimately fail, but the reasons are often highlighted in this exercise).

Issue #4