Yes, it may seem more logical to just have nif-sem without the possibility of
reversing changes, but this very much limits the possibilities to simplify each
individual NIF module in sem, for example you can't remove typeof to the top
level as in the example, you can't remove using after sem, and otherwise macro
won't work properly, especially getImpl called from another module. For a
normal nif-sem the resulting ast should be very similar to the original.
Another option (not info), without limitation is to use just memorized
implementations of procedures, but this requires extra memory, and generation
via info saves memory, but has disadvantages when you need to frequently access
different nodes with info (the same ones can be cached), and different ones
need to be generated. Speaking of mental burning, it seems to me that this is
the opposite way to reduce it. It will allow to make much simpler modules in
NIF, without unnecessary things that do not affect the meaning of the code.
