wishlist: use a template language for code generation

[jameysharp]

I find files like src/lx/print/c.c difficult to read and maintain due to complicated sequences of fprintf calls which obscure the structure of the code that's being generated. I speculate that using a simple templating language would make the code generation process easier to understand. Perhaps the templates would even be a useful public interface to lx, so users could write their own templates without having to recompile lx.

Although I haven't used it, there is a C implementation of the Mustache templating language that looks to me like it might work perfectly here. For Mustache syntax see https://mustache.github.io/ and for the C implementation check out https://gitlab.com/jobol/mustach.

[jameysharp]

I guess I should mention why I thought that particular implementation might be a good fit. The Mustache documentation is all written with the assumption that you'll pass JSON to your template processor, which isn't really what I'd want for this. But the mustach C library looks like it allows you to walk over whatever in-memory data structure you want, such as the internal representation that lx uses, which I think is a fine match for requirements here. Again, though, I haven't actually tried it, so who knows, it might be garbage.

[katef]

Jamey and I chatted briefly about this. The main points were:

• Knowledge of a particular output language belongs to a template (and therefore presumably not also elsewhere)
• and therefore so should escaping strings
• If a template is the only place with knowledge of an output language, they could be passed at runtime
• Output probably ought to handle pretty-printing. But I'd also want to be able to control whitespace.
• If a template's IR is some kind of abstract representation, why not also optimisations?
• All these things feel so over-engineered just for the sake of printing code. I don't use graphviz's libraries to print .dot by constructing it graph as a datastructure! Nor do I want a DOM when outputting XML.

Taking on this area is something I had a previous go at, but decided to leave. I was thinking about code generation for TenDRA's lexi at the time. If I do revisit considering tempting, it's definitely a system I'd want to apply for all my code generation in various projects, which is all quite similar to in this repository.

Meanwhile the printfing is cumbersome, but isn't actually much trouble for maintenance. So that's why it's here. I'm closing this ticket because it's discussion that applies to many projects - and because it's something I can't figure out how to do without it being an unwieldy project in itself.

[jameysharp]

For future reference in case anyone else stumbles across this, I agree with Kate's summary, but I would like to add a couple more comments.

I literally had a nightmare just last night about getting the spaces right in these printfs—so I do consider this kind of important from a code maintenance perspective. (When I'm emitting XML, I absolutely use an API like DOM, or more often, SAX.) But that wasn't the core reason I proposed this; it was more of a bonus.

My primary interest in this issue is that there's no way lx can ever generate the right code for all users. So really I wanted to give people a way to generate code themselves from the FSM that lx computes, without having to hack up and recompile libfsm.

With that in mind, and considering Kate's quite solid points about the difficulty of providing a usable templating language for this purpose... Probably what I really want is an interchange file format that people can consume from their language of choice and do their own codegen however they prefer to do it. Pretty-printing libraries and ASTs are a lot easier to manipulate in languages with automatic memory management, anyway. So I agree with closing this issue, in favor of exploring #118 more.