VarName and VarNamedTuple are currently owned by AbstractPPL and DynamicPPL respectively. These types are designed and implemented quite nicely (I admit I am biased here) but they should probably be in their own package, as I don't want to have to pull in DPPL to use VNT-related functionality (for example, the code to handle VNT-based structures is frustratingly scattered between the main codebase and the DPPL extension). Pulling in APPL used to be fine as it used to be only empty interfaces + VarName, but now it has a bunch of extra AD code and extensions, part of me wonders whether it is worth pulling that in as well as this just causes extra precompilation for people who don't want or need to use that.
In particular, it might be worth forking the types to a separate package and making that the primary key type of FlexiChains (i.e., just pretty much go all in on it instead of having SymChain as a backup, since all Symbols can be trivially promoted to a VarName). The old code for VNChain, which would essentially be a duplicate of the new code, can be kept in an AbstractPPL extension in order to not break any functionality with Turing (or anything else that uses it). New features (if any) can be kept in sync quite easily.
VarName and VarNamedTuple are currently owned by AbstractPPL and DynamicPPL respectively. These types are designed and implemented quite nicely (I admit I am biased here) but they should probably be in their own package, as I don't want to have to pull in DPPL to use VNT-related functionality (for example, the code to handle VNT-based structures is frustratingly scattered between the main codebase and the DPPL extension). Pulling in APPL used to be fine as it used to be only empty interfaces + VarName, but now it has a bunch of extra AD code and extensions, part of me wonders whether it is worth pulling that in as well as this just causes extra precompilation for people who don't want or need to use that.
In particular, it might be worth forking the types to a separate package and making that the primary key type of FlexiChains (i.e., just pretty much go all in on it instead of having
SymChainas a backup, since all Symbols can be trivially promoted to a VarName). The old code forVNChain, which would essentially be a duplicate of the new code, can be kept in an AbstractPPL extension in order to not break any functionality with Turing (or anything else that uses it). New features (if any) can be kept in sync quite easily.