Hopefully the last big refactor for a while; resolves #23, and should set us up for productive feature addition into the near future.
Of note:
The optics.poly.Focus macro interface remains where it was, but is devoid of any code
All the work is done inside the optics.internal.focus package.
Uses the "cake pattern", which is pretty much the only way to do it, because we are using dependent types like TypeRepr and Term all over the place, that are dependent on a particular instance of Quotes. Cake pattern is the only way to get the compiler to unify identical Quotes instances, so it knows that all the modules talking about TypeRepr and Term are talking about the same things.
The cake pattern traditionally uses a Module or Component suffix to mark the module traits to be mixed together, but it honestly makes my eyes bleed. Everything in optics.internal.focus is cake, so there is no need to specifically identify the pattern with a suffix.
There are two axes to separate along; phase (eg code-gen vs parsing) and feature (eg field selection vs some vs at, etc). I am splitting on feature first and phase second, because we intend to add a bunch of features, and it will feel nicer this way.
The core machinery in GeneratorLoop and ParserLoop still has some feature-specific gunk in it, which will unfortunately grow. I still need to find a way to completely leech all this stuff out into the feature buckets.
Every method is private which can be private.
In some modules the public interface can be whittled down more. For instance, the FieldSelectParser module has a somewhat bloated public interface (3 things), which is exactly because the ParserLoop is handling too much of its business. I think this can be revisited once we have a second feature in, which will clarify the necessary approach.
Hopefully the last big refactor for a while; resolves #23, and should set us up for productive feature addition into the near future.
Of note:
optics.poly.Focusmacro interface remains where it was, but is devoid of any codeoptics.internal.focuspackage.TypeReprandTermall over the place, that are dependent on a particular instance ofQuotes. Cake pattern is the only way to get the compiler to unify identicalQuotesinstances, so it knows that all the modules talking aboutTypeReprandTermare talking about the same things.ModuleorComponentsuffix to mark the module traits to be mixed together, but it honestly makes my eyes bleed. Everything inoptics.internal.focusis cake, so there is no need to specifically identify the pattern with a suffix.GeneratorLoopandParserLoopstill has some feature-specific gunk in it, which will unfortunately grow. I still need to find a way to completely leech all this stuff out into the feature buckets.FieldSelectParsermodule has a somewhat bloated public interface (3 things), which is exactly because theParserLoopis handling too much of its business. I think this can be revisited once we have a second feature in, which will clarify the necessary approach.