Yeah, I've seen a fair bit literate code that is awkwardly structured to satisfy ordering needed by the underlying language. It works better in languages that don't care about the order of declarations, of which there are many, but usually there's something at the top to the effect of "we need to start off with a pile of imports, because compiler."

Haskell will recognize a .lhs extension and do comments by default, using > to prefix lines that are actual code (looks block-quote like).

Frankly I am something of a skeptic of literate programming. In most of the literate source code I've read, the code is clearer than the prose anyway, and having every detail in comments just makes the whys and the high level design harder to find.

My approach is to basically assume the reader is familiar with the language and the key libraries, document the whys, overall design, and the api contracts, and try to pick good variables and write clear code. This is not to say "inline comments are bad," but I find that usually when I find myself writing a lot of comments explaining the details it's because I'm writing a lot of confusing code.