Direct Observation: Reading STG

[doyougnu]

Should have:

- good patterns
- bad patterns and how to fix them
- description of all information dumped by core
- possibly description of unarisation?
- description of slow_ap and fast_ap and other machine fundamentals
- no-update or update lambda

for this and #13 make sure it connects to the user's vision of their code.

[doyougnu]

also this guidance for emitting stg for packages:

Maybe if I copy a cabal.project.freeze file from the node into the ouroboros-network repository at that commit, then compile there I should get the same results as the node does, but it seems quite fragile to rely on this

...
One way to make this easier is to locally make it a local package.
Just cabal unpack the-pkg-name which should fetch the tarball from CHAP and adjust your cabal.project to point to the local directory.

[doyougnu]

explanation of let-no-escape: https://jstolarek.github.io/posts/2013-10-06-let-no-escape.html

[doyougnu]

also this nice summary from the GRIN project: https://github.com/dmjio/ext-stg-interpreter-talk?tab=readme-ov-file

[ulidtko]

Hi... IMHO, there're 2 cornerstone papers worth referencing in the handbook, to explain STG.

• "Making a fast curry: push/enter vs. eval/apply for higher-order languages"
  https://simonmar.github.io/bib/papers/eval-apply.pdf
• "Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine"
  https://www.microsoft.com/en-us/research/wp-content/uploads/1992/04/spineless-tagless-gmachine.pdf

As an engineer, reading these gave me the concept-base to understand STG, and to gdb over Haskell assembly to an extent.

In retrospect, all the summaries & cheatsheets linked here do make sense — but only after I'd grokked the system design of GHC RTS, covered in those papers.

I understand it's not everyone's favorite mode of learning, and perhaps not a good fit for a "handbook" format — yet anyhow, I sort of wish the handbook pointed me to them up-front.

At any rate, that'd be better than a TODO stub. Just my 2 cents of feedback as a reader 🤷‍♂

[doyougnu]

I understand it's not everyone's favorite mode of learning, and perhaps not a good fit for a "handbook" format — yet anyhow, I sort of wish the handbook pointed me to them up-front.

At any rate, that'd be better than a TODO stub. Just my 2 cents of feedback as a reader 🤷‍♂

Hello and thanks for the comments. Your points are completely apt and I agree with them. Unfortunately I have had to put writing on the back burner for some time. I did have a half written chapter that implements an STG machine in Haskell to explain it, so I could resurrect that. But the next thing on my list was to make a "triage" chapter that would point readers to chapters based on their problems. I've been in the midst of interviewing which has unfortunately taken up a lot of my writing and development time.