> 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 (historic relevance)
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/ 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
> 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 (historic relevance)
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/ 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