> A kernel spends most of it's time managing mutable state.

Why do you think that FP doesn't have tools for this? Do you genuinely think that in 20+ years of research no one has thought of this? Have you investigated it?

I don't know. If you think that things like ST aren't suitable please say why (other than the larger problems with monad transformers, of course).

I know that FP has tools for that. But if the problem is primarily managing mutable state, isn't a tools that lets you directly see what you're doing a better fit?

Are the FP tools as efficient as the direct, C-style approach? For an OS, that matters.

Are the FP tools as easy to reason about correctly (especially in a section you're not familiar with)? For an OS that's worked on by thousands of people, that matters.

In this context, what is "ST"? And, what are the larger problems with monad transformers?

What's most frustrating about these conversations is what I've noted in another thread: people feel really comfortable talking about what FP can and can't do without even acquainting themselves with 10+ year old techniques in the field.

I'm sorry, I decline to continue this conversation further.

How do you think Xerox PARC, Genera and TI managed to write Lisp based OSes?

By using all the imperative, procedural and object-oriented features of Lisp.

In many ways the early MIT Lisp Machine morphed into a Flavors Machine in the early 80s.

Remember, Lisp is a multi-paradigm language.

But that is the thing, none of the successful FP languages in the industry are pure FP, rather multi-paradigm, even if functional first.

> Here's a table of processes. We want it to be an array, rather than a linked list, for efficiency reasons.

At least in Linux, the table of processes is implemented as a (doubly) linked list.

I wasn't going to say anything but...

TIL.