Having the same interface means there are some things you can do to monads without caring which monad, which turns out to be useful.
Pure basic programming language code#
Monads in general are just generalisation - they have the same interface, but implement the abstract operations differently, so instead of evaluating to a description of imperative code they evaluate to something else instead. Many expressions and functions can be evaluated during the "code generation", but those that depend on I/O side-effects must have evaluation delayed until run-time - not by any special rule, but as a natural consequence of the data dependencies in expressions. This is pretty much what the IO monad does - the bind operator is a way of composing "actions" to form programs. In fact, discard the idea of AST nodes as a special kind of data altogether - don't have "literal value" AST nodes, just have values etc. Further, discard all looping construct AST nodes in favor of recursion. So, for phase 3, make the two the same - the same function with the same syntax may be partially evaluated during the "code generation", or fully evaluated, or not evaluated at all. It's a bit like the distinction between functions and templates in C++. For example you have two distinct kinds of functions - those evaluated during the code-generating phase and those executed when the generated program is run. This is a lot closer to what Haskell does.
Your imperative-language compiler is absorbed into your "higher level" compiler, and accepts the AST directly as source code. Phase two - rather than generating textual source code, you generate a strongly-typed abstract syntax tree. You can then build a "higher level" compiler that runs your code generator, then automatically feeds that generated code into the imperative language compiler. This big string can be the source code of an imperative program, derived in a pure functional way from some requirement-specifying parameters. Phase one - a pure functional language can easily return a big string value as its result. However, for imperative programmers, I think a backwards way of arriving at monads makes more sense. The Haskell IO monad is derived from the mathematical theory of (of course) monads. Whether you count Haskell as pure, or count the IO monad as impurity, Haskell style is an extreme form of this style and well worth learning. What's different is the style - how you solve problems. Impure languages don't really differ in principle from the more familiar imperative languages, especially now that many functional tricks have been copied.
0 kommentar(er)
