An ASM Monad (2013) | Hacker News Reader

An ASM Monad (2013)

wall.org

83 pointslmm13 comments

(As I posted elsewhere...)

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

HN tends towards pop programming more.

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.

In a similar vein, x86 assembly in coq:

http://research.microsoft.com/en-us/um/people/nick/coqasm.pd...

This is written by Larry Wall's son (he of Perl fame), in case that matters to anyone (as a father myself, this fact seemed "cool" to me).

"In a move that is sure to scare off both high-level and low-level programmers..." - quite.

I saw a similar computation expression implementation in F# (for MSIL):

http://stackoverflow.com/questions/14110532/extended-computa...

https://github.com/kbattocchi/ILBuilder

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:

    il {
        ldc_i4 6
        ldc_i4_0
        ldc_i4 7
        add
        mul
        ret
    }

I used a similar technique about five years ago (!) when I wrote a toy compiler for a university class in Haskell. Here's the relevant bits:

* Expression evaluation: https://github.com/michaelmelanson/cminus-compiler/blob/mast...

* Statement compilation: https://github.com/michaelmelanson/cminus-compiler/blob/mast...

* Definition of the monad: https://github.com/michaelmelanson/cminus-compiler/blob/mast...

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?

You could use Haskell's type system to make it type safe. In fact Galois have done pretty much that in Ivory http://ivorylang.org/

The default keyword [0] would fix the extra-type-annotations issue, no?

[0] https://www.haskell.org/haskellwiki/Keywords#default

Reply on news.ycombinator.com