Support incremental mode
gampleman opened this issue · comments
Since elm-review --fix keeps re-rerunning rules until nothing changes, we could support another mode, which whenever an auxiliary definition should be generated generates the signature with another Debug.todo. The user can then either let elm-review interactively fix that definition or gets an opportunity to abort and implement the auxiliary definition by themself.
In this mode it should probably also generate Debug.todos instead whenever it encounters an error.
This mode would be much slower for generating larger amounts of code, but would perhaps be more interactive allowing authors to understand the process and intervene in it manually more easily (for instance at the moment you sometimes get huge amounts of code generated in a runaway process when the generator doesn't quite understand how to incorporate some already implemented function. In this interactive mode you would see that it's generating some nonsense and would abort, implement the bit that it doesn't understand, then resume generation for the rest of the data structure).
Technically this is fairly straightforward, we would need to get the flag down to the function that generates external definitions and emit Debug.todo instead. There is some further complications, since at the moment we don't pick up functions that contain Debug.todo as viable definitions, so there are some issues of generating duplicate auxiliary definitions. However, that could be quite easily fixed.
Is elm-review --fix something you use? I personally always use --fix-all so I'm curious how many people would benefit from an increment mode.
Yeah I always use fix. The more I think about it the better idea I think this might be.
This mostly comes from using this at work on large and complex types. Typically there the first attempt will fail, typically because some deeply nested opaque type doesn’t have a decoder available. You have to then go through the iterative process of defining these before the generator even attempts to spit something out. And you might not even care about these leaf types, since you might be interested in serialising only a part of the data structure.
After that the generator might spit out a few thousand lines of code at you in one go. Again, a lot of it might be pointless, since perhaps you want to mixin a different way of serializing, such as a toString or some such.
In such a situation gradually generating top down one step at a time might be vastly preferable, where you can easily intervene at any step, since elm-review will always give you a fairly manageable diff.
Ah okay, I misunderstood the initial proposal. This sounds like a good idea when you want to intervene in the code gen for a single todo.