This is even true for plain Haskell functions (pattern matching handles the “parsing” step, rendering is either done by the identity (in the trivial case) or “show”). However, we can use an algebraic/category theoretic concept (“the monad”) to encapsulate the folding and unfolding of a data structure into another.

The monad defines a “bind” operator >>=, which takes a monad element and a function on the monad element’s underlying type back to the monad. The monad element is unfolded (as defined by >>=), and f is applied to refold it, perhaps in terms of a different kind of data structure.

Of course, a parser is automatically a state machine and lots of other “equivalent” things, and so by changing the emphasis of interpretation, one can construct them all using the same simple Haskell notation.

From a different point of view, a programming language’s “object system” is a specific monad operating on a tree of object-oriented classes to seek methods. “Generalized object systems” can be built, and the monads are them.

This is even true for plain Haskell functions (pattern matching handles the “parsing” step, rendering is either done by the identity (in the trivial case) or “show”). However, we can use an algebraic/category theoretic concept (“the monad”) to encapsulate the folding and unfolding of a data structure into another.

The monad defines a “bind” operator >>=, which takes a monad element and a function on the monad element’s underlying type back to the monad. The monad element is unfolded (as defined by >>=), and f is applied to refold it, perhaps in terms of a different kind of data structure.

Of course, a parser is automatically a state machine and lots of other “equivalent” things, and so by changing the emphasis of interpretation, one can construct them all using the same simple Haskell notation.

From a different point of view, a programming language’s “object system” is a specific monad operating on a tree of object-oriented classes to seek methods. “Generalized object systems” can be built, and the monads are them.

There was a month a long time ago that I spent almost all my free time trying to understand monads, and I read quite a few tutorials and found none of them helpful. I saw yours but then because it was about space suits I thought it would be a load of bollocks.

A few months passed and then I tried again, and this time I looked at your tutorial and I managed to understand it in two days. It is my opinion that your tutorial is perhaps the best on the internet but could be improved because it does require a bit of exposure to monads.

-Tahir

The prefixing workaround to get de facto namespaces (which are basically syntactic sugar for prefixing; look at the symbol names compilers generate) and the automated tools for tracking dependencies by reading source also work. I’m not trying to say that these things are insurmountable; they absolutely can be managed and mitigated. But these are problems which don’t need to exist, shouldn’t require workarounds and aren’t present in some other languages.

C also has namespaces – in the form of identifier prefixes. It’s the same thing, except unenforced and more explicit (the latter of which is a good thing).

Mark, I can’t think of any language that doesn’t allow developers to use relative paths for importing external modules. Such languages necessarily require a “path” of places where those modules might be located. This includes C, Java, Perl, Python, Ruby, …. What’s the alternative?

The problem is the language itself. I think namespaces should be introduced for header files as well. It is silly to require .h files to be put at specific paths rather than have it “register” somewhere (on a traditional system it is “registered” by being put at a specific place on a hdd, but this model is suboptimal imho)

> It’s possible to work around this problem with a build system if you track every header file dependency explicitly.

Try GNU autotools or SCons.