2 ms·
> And I'm also unsure whether he needs to build the list of include statements like I do or whether that's somehow captured in the annotation itself. > the wor
by e12e 7y ago
> And I'm also unsure whether he needs to build the list of include statements like I do or whether that's somehow captured in the annotation itself.
> the workflow could be better. In the example above, we had to define the function body, prelude, if statement, else statement and both if/else blocks.
> It would be much better if we could inverse this: defining the whole function block with holes for the if/else blocks that the code generation would put in.
The original CWEB and newer NOWEB do handle these things a bit better - sections can be defined and included in any order, and sections can define which file their in.
It lends itself particularly well to laying out a program "top down", ie:
We define the utility ctof as consisting of a c file: ctof.c.
It has the following structure:
standard header includes
defining constants for conversion
defining the function ctof that converts a float value of degrees Celsius to Fahrenheit, returning a float
A help procedure that prints help
A main function that parses command line parameters, and conditionally call the help procedure or ctof function... Etc
Then can go on to define the inner bit of ctof first (the calculation).
In general literate programming is very nice. It can be a bit of a challenge when breaking out small sections (we define a loop that iterates over an array like so...) - because of scoping issues - if the programming language discourages many small (max 10 lines) functions/procedures.
At that point the literate system itself takes on the role of a macro assembler of sorts - which can work with old school "structured programming" - short programs, well defined global state (a few array/lists, a few "in" and "out" global variables).
See eg: http://literateprogramming.com/cweb_download.html http://literateprogramming.com/cweb_download.html (historic relevance)
http://leoeditor.com/ http://leoeditor.com/ (not sure if it's alive - an interesting idea in "all literate, all the time"
https://www.cs.tufts.edu/~nr/noweb/ https://www.cs.tufts.edu/~nr/noweb/ modern-ish take on literate programming - if you want LaTeX for the document part
Finally, the most pragmatic variant I'm aware of - literate markdown tangle - which might be close enough to what's in op to encourage a port:
https://github.com/driusan/lmt/blob/master/README.md https://github.com/driusan/lmt/blob/master/README.md
- TomasSedovic 7y agoThanks for this! I want to check the WEB-inspired approaches at some point, this is super useful. The Markdown one seems interesting too. I'll probably stick with this for stuff where there's some expectation of drive-by contributions (the tutorial has seen a bunch, it was one of the motivations behind this) because requiring additional tooling can often be a bar that's too high. Agreed on the general literate programming note. I'm not sure I'll ever pick it up for something that doesn't have an obvious accompanying article/book to come with it, but if I ever write another tutorial or something, I'll definitely use it from the beginning. But knowing what's out there is definitely important (and AsciiDoctor is extensible so these things could probably be added as plugins).