Code Generation, Macros etc.

[frnco]

Using Mint has mostly been very easy, straight-forward and hassle-free, but one issue that keeps turning up time and time again, and which actually deserves some attention, is validating data with complex structures. Over-generalizing or even completely dropping the structure means substantially increasing the number of manual checks and cases and things like that. Trying to properly codify the structure in Mint, on the other hand, can be a pain in some situations, namely those where the structure may change over time and/or those where the structure is, in itself, part of the data. A couple examples of that are:

1. Internationalization, where it'd be reasonable to use fields of a record or an enum to identify the translated strings, language codes;
2. Icon libraries, where having the icon names as, again, fields of a record or enum makes sense (I actually wrote a ruby script to generate one for Feather Icons, here's the resulting Mint file: https://gist.github.com/frnco/3026691c0d955333a46ea8b0a368367e ).

While writing some script that generates valid mint code and putting it into a file solves this problem, it's far from an ideal solution. Being able to load some JSON or YAML or text files and/or running some commands in the system at compile time, either from within a mint file or from some other file format that the mint compiler automatically deals with, and have the results of those used to dynamically generate the relevant mint structures, such as enums or records or whatever, would be a lot more desirable, allowing anyone to, say, use an icon library which is not MintUi's, while still having the type-checker ensure their code only uses valid icons, or maybe do internationalization by loading files with the definitions for each language where they can simply add a new field to the translation and use it in the code, while Mint works out which fields the translation files actually include and reports to the dev in case some language is missing some field or if they try to access a field that doesn't exist.

Now, that's obviously not trivial since mint would have to work through this stuff not only when building the dist version but also when developing, and there are many ways to go about that, but the benefits of having such powers are so large and there are so many situations where this could simplify the code that I think it's worth discussing this, whether it's feasible to implement, how it might be done etc.

I'm also interested in any other possible ways to deal with this, Mint features I may have overlooked etc.