mkPlayer can be simplified further!

  mkPlayer :: Maybe Weapon -> Class -> Either Error Player

  mkPlayer (Just Staff) Warrior = Left "A Warrior cannot equip a Staff"
  mkPlayer (Just Sword) Wizard = Left "A Wizard cannot equip a Sword"
  mkPlayer weapon klass = Right (Player weapon klass)

You lose exhaustiveness checks if new weapons or classes were added though. May or may not be worth the trade-off.

At least two of the article's statements about LLVM are false. In particular:

1) LLVM doesn't place any restrictions on how a language runtime allocates memory.

2) LLVM doesn't "expect" a stack map -- it provides infrastructure to compute them if the front end wants to, but the front end is completely free to ignore that infrastructure.

Are those corrections to the incorrect statements, or the incorrect statements themselves? It's not very clear, I'm sorry.

So I wouldnt say that LLVM places restrictions, but I will say a little of my experience doing LLVM + BoehmGC

BoehmGC uses the stack for its root set (where it starts to find live memory). With LLVM, you dont ever need to explicitly use the stack, you can use registers for everything and make LLVM figure out if it should go on the stack or not. If you want to use Boehm with LLVM, you are forced to explicitly allocate everything on the stack, and not just on a register, so that Boehm is guaranteed to find the memory.

So I wouldnt say restriction, but definitely you need to think about how LLVM operates with the GC and other runtime components of your language.

Ah, they are corrections to the article's incorrect statements! I apologize for the ambiguity.

Yeah, it was fuzzy to me too. Found this in the article though:

> First, a description of how SBCL’s generational GC works:

> ...

> Being conservative with regards to the stack. That creates a major clash with LLVM which expects a stack map. A stack map declares which data type can be found where on the stack for a function (as in every invocation of that function needs to comply to it), whereas SBCL’s compiler can and does generate code that just places anything anywhere. This makes the stack a lot more compact in some call patterns.

So those were intended as corrections.

Hmm. I looked at the list of five and thought to myself: "four legends and... who on earth is Scott Fahlman?" Turns out he invented the smiley! TIL

GHC, at least, uses the same implementation for IORef and STRef: http://hackage.haskell.org/package/base-4.3.1.0/docs/src/GHC...

Poking through GHC's runtime source, I see a writer barrier but no locking -- did I miss something?

Looking deeper you're right, it seems to use atomic CAS operations. Still mutable data is bad for GC and optimization pass (can't share expressions etc.)

He essentially retracted his original assertion eight months after it was published, see the first few "Update" sections of

http://www.philipreames.com/Blog/2014/02/21/why-not-use-gcro...

and also

http://www.philipreames.com/Blog/2014/10/21/statepoints-vs-g...

"To explicitly state this again since I screwed this up once before, both statepoints and gc.roots can correctly represent relocation semantics in the IR. In fact, the underlying reasoning about their correctness are rather similar."

Argh. I wish he'd used language like "I retract" in the more recent 10/21 post, it got into "weeds" that I was avoiding getting into until he/Team Azul finish their statepoint work. That based on his mistakes with gcroot (granted, I share his goal of high performance precise collection, which is just not in the DNA of C/C++).

And I see the first batch of patches landed today: http://www.philipreames.com/Blog/2014/12/04/statepoint-patch...