eschew

I admit I don't have ground truth here, but the whole thing reads to me as very clearly AI generated. For what it's worth, Pangram agrees. In my view, this style of blog post does not "prioritise people and community" as "Generated text should not be relayed as a substitute for the contributor’s own judgement".

When the content is AI-generated, it's very hard to suss out what, if any, human judgement was involved.

Seems ironic that a blog post describing GHC's AI policy, from a contributor to GHC, which expresses agreement with GHC's AI policy, itself directly violates GHC's AI policy (points P1 and P4)!

Here is a public report from the TRACTOR evaluation team: https://github.com/DARPA-TRACTOR-Program/Reports/blob/main/F...

There are also some papers being published that were funded by TRACTOR, such as https://homes.cs.washington.edu/~mernst/pubs/c-rust-macros-p...

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)

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

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.

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?

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