Worth noting that the ASM monad is “just” WriterT [Word8] ◦ StateT Loc which provides the functor instance, the applicative instance, the monad instance, the MonadWriter instance, the MonadState instance, the MonadFix instance, a MonadTrans instance if the author is interested, and even an Alternative/MonadPlus instance (e.g., the ability to have branching, non-deterministic computation in assembly if we adjoin a failing monad into the stack).
This is not a critique of anything in the post—it’s just a note that monads (and monad transformers) are really cool! If you know how to recognize monad decompositions like I just did then you can exploit it to read off whole lists of properties and implementations of functions.
I find it interesting seeing the comparison between a post on lobste.rs to a post on hackernews. I kind of like lobste.rs more than hackernews, since it's more programmer-centric. But Obviously hackernews gets a lot more traffic so there's always some interesting comments to be gained -- I didn't know the original author of that blog article was Larry Wall's son, and I also didn't know there were already similar implementations in F# (makes me want to check out F#) and coq.
Maybe it would be fruitful to re-post the best articles on lobste.rs on to hackernews -- for the comment/information gain....
There's nothing wrong with that...per se. But pop programming tends to be more flavor-of-the-month/bikeshedding oriented, so there's more to wade through. I'm worried lobste.rs will end up the same way.
The composition operator ◦ there is only conceptually correct up to Applicative instances. Monad Transformers rely on very specifically tailored composition, and not a generic Type-Compose. Otherwise we could just type-compose Writer, State, etc and wouldn't need WriterT, StateT, ...
True and important, though honestly I just think of it (very loosely) as a functor composition operator and note that the composition happens to be a monad as well.
Thanks for the plug. While it's probably not clear from those two links, the IL builder actually tries to use the type system to enforce much more rigid correctness rules. For example, removing any of the opcodes in this example will result in a compile-time error because the IL would become invalid:
The 'compilation state' was wrapped up in a State monad which held a list of emitted instruction blocks, free registers, and so on. I didn't go as far as to wrap each of the instructions in their own functions to get an assembly-like DSL, but you can imagine defining functions like `add = emit $ ADD` for each instruction to get the same effect.
Mhm. My thoughts on this are aplit. On one hand having written assembly (x86) myself, I often find myself looking for ways to simplify development and what not. However, on the other hand this defeats the purpose of assembly I think. Ideally you should only write small snippets in asm and leave the rest to C/C++. In fact by slapping enough features onto the macroassembler you'll pretty much get C, so the question is why won't I just you use C?
Worth noting that the ASM monad is “just” WriterT [Word8] ◦ StateT Loc which provides the functor instance, the applicative instance, the monad instance, the MonadWriter instance, the MonadState instance, the MonadFix instance, a MonadTrans instance if the author is interested, and even an Alternative/MonadPlus instance (e.g., the ability to have branching, non-deterministic computation in assembly if we adjoin a failing monad into the stack).
This is not a critique of anything in the post—it’s just a note that monads (and monad transformers) are really cool! If you know how to recognize monad decompositions like I just did then you can exploit it to read off whole lists of properties and implementations of functions.