
From Monads to Machine Code - mrkgnao
http://www.stephendiehl.com/posts/monads_machine_code.html
======
tomcam
This is a gentle introduction to Haskell and also a brilliant tutorial on x86
assembly language – bonuses for anyone interested in compiler implementation.
Exceptionally well written and clearly illustrated.

------
evincarofautumn
Man, I always love how cleanly EDSLs come together in Haskell. If you’re a fan
of “language-oriented programming” (e.g., in Lisps and Forths) but you want
static types, Haskell is for you.

~~~
shakna
My problem with Haskell, coming from the ease of Lisp, is that so much of the
syntax is symbolic!

I know mathematicians might love it, but forgetting a symbol can mean I don't
understand an entire block of code. Whereas it could have been made so much
clearer with one word.

~~~
runeks
Could you give an example of this? I don't quite follow what you mean by
"symbolic syntax". Do you mean infix functions like _> >=_ and _< $>_?

~~~
shakna
Syntax where symbols are used in leiu of words.

For example, I have no clue what >>= and <$> mean from a glance.

I have to look it up to get Monad and Functor. Why not use the word?

~~~
moomin
Well, because it's pretty obvious after you've spent a week with Haskell. With
that said, one thing the Haskell creators seem to regret is not requiring
every operator to also have a name. (In the case of <$> it does: fmap)

------
briansteffens
It's so cool how similar the contents of the arith function are to actual x86
code. The relative offsets were also handled really cleanly.

------
mrkgnao
(With a short detour through writing a JIT in LLVM, of course, but I didn't
want to edit the title. Sadly, I accidentally added the "from" at the
beginning.)

------
lacampbell
I got lost at the monads bit. Where's the best place to learn about them? I
did basic Abstract Algebra in university, and I understand how to use the
Maybe/Option/Optional monad.

~~~
moomin
Do this course:
[http://www.cis.upenn.edu/~cis194/spring13/lectures.html](http://www.cis.upenn.edu/~cis194/spring13/lectures.html)

I know it sounds ridiculous but a) it took me about seven evenings b) it's a
lot of fun and c) I guarantee you'll get some proper programming insight,
whatever language you use for a day job.

~~~
BoiledCabbage
I second this, it's a great course.

------
gue5t

        pflags = protRead <> protWrite
        mflags = mapAnon .|. mapPrivate
    

What's the difference between these two operators?

~~~
evincarofautumn
There’s no difference in this case—looks like an oversight. “<>” is the Monoid
“append” operator (e.g., concat lists, union sets, compose functions). If you
look in JIT.hs[1], you’ll see that there’s an instance of Monoid that just
calls “.|.” (bitwise OR):

    
    
        instance Monoid ProtOption where
          mempty = protNone
          mappend (ProtOption a) (ProtOption b) = ProtOption (a .|. b)
    

[1]:
[https://github.com/sdiehl/tinyjit/blob/master/src/JIT.hs](https://github.com/sdiehl/tinyjit/blob/master/src/JIT.hs)

~~~
mrkgnao
There _is_ no canonical monoidal operation on booleans (just as the case is in
any arbitrary ring), so I'd guess using the bitwise operators explicitly is
good for disambiguation.

~~~
evincarofautumn
Yes and no—in practice in Haskell we tend to choose the most convenient
instance and wrap things in newtypes to get at other instances. Writing code
using generic operations (Monoid, Functor, Foldable) makes it easier to
refactor datatypes later—coding to the interface and not the implementation,
and all that. The bitwise OR operation makes sense for ProtOption because it’s
basically a set.

~~~
mrkgnao
That's true, for bitflag-like things OR does make sense.

