`acton generate`: Support pre-source stage for generating code

[plajjan]

Sometimes it can be useful to generate Acton source code from something else. For example, taking a serialization format like protobuf we can generate an Acton module for the bindings.

I'm thinking this should be invoked via like acton generate, which should read like $project/generate/foo.act and this in turn should generate a file in the project source directory like $project/src/blargh.act.

These are debatable, but my thinking is:

• acton generate is to be run by the package developer, not by users during a normal compilation (acton build)
  • it is conceivable that acton generate would rely on external tools, which should only then be run on the package developers machine
    • installing such external tools is outside the scope of acton generate, best practices for checking existence of required tools before generating empty files etc
• consider write protecting the source file? automatically or via best practice convention add a comment in the source file to say it is generated and should not be manually modified?
• longer term, it would be nice to make the generating thing be based on some common build module in the stdlib that allows us to express a build graph, rather than just directly writing some source code files
• this is similar to go generate but unlike go, which uses magic comments in the source code file to run UNIX commands, acton generate will compile and run acton programs, thus generating code is done from within a generator acton program
  • This way we leverage the full expressivity of Acton itself rather than the unix prompt
  • We can run any unix command by utilizing the acton process module
  • running yacc will be a few more lines, but given that it will be easier to compose more complex things within an Acton generator program, I think it's worth it
  • this encourages an ecosystem of Acton libraries that are meant for generating other Acton source code
• I don't think this is a replacement for other macro / metaprogramming patterns, like there would still be a benefit in having more of language oriented things, similar to Zigs comptime or Nims macros
  • such metaprogramming is focusing on generating code based on the source code in a repository, likely without the ability for the programmer to inspect the code post-macro evaluation
  • the pre-source code generation suggested in this issue is more targetting generation of Acton source code from some other source, an operation which is invariably run more seldom, when that source document changes, it is also an explicit step by the Acton project developer and will likely mean a bump in the project version
    • pre-source code generation writes the output to a file in src/, so the output is visible
• can code generating code have dependencies? like on some acton lib that should be downloaded from the internet?
  • feels like a good thing, like import protobuf & protobuf.generate(my_proto)
  • our support for dependencies is not very good / mature at this point, so it's a little hard to reason about how this would work
• how to implement? is generate just another acton project within the acton project? and acton knows that it's output can be executed? I think it would be nice to hide the generate binaries though, not supposed to be run manually, right?
  • is generate/src/foo.act nice / desirable? I feel it's a little ugly to feel that it is a nested project. I don't want to see generate/out/bin/foo really...
  • surely, generate/foo.act looks better?
• today the Acton project related paths are hard-coded in actonc as relative to the project root, like out/bin, if actonc were instead to take all these individual paths as arguments, it could prolly be used to compile the code generator and place the output elsewhere
  • generate/foo.act -> .build/genbin/foo
  • then run .build/genbin/foo with CWD set to . (project root) and let it write output to wherever