there is one type family (ChalkIr) that all other crates are currently using

the Fold and Zip traits are also generic over the type family

I started working on the main goal here, which is to make clause generic generic over the "output" type family. It seems to be working "ok" but I decided I wanted to step back a bit from that and first do some other refactorings to that code to clean it up

On the other hand, it doesn't yet reach a "useful" end-goal

Do you have something in mind already, or is it more a matter of seeing how it will turn out?

actually, @detrumi, that's a good point; at some point I introducd the HasTypeFamily trait and we could potentially use that instead of having Zip<TF> -- however, it is also useful to sometimes have types (e.g., usize or whatever) that do not belong to any particular type family

The F corresponds to the G: HasTypeFamily in the struct definition, right? I guess this'll require merging extra generic parameters in, instead of just replacing them like the cases where a non-generic struct had to be impl'd with Fold<ChalkIr>

For the simpler cases I opted for a #[fold_family(ChalkIr)] attribute on the fold-deriving struct. Not sure if that's the best way, but it seems to work fine

enum_macro actually was easier to replace (unless I broke something, but the tests are green). Void folding was an edge case but didn't seem to be used, and I don't think the "Hacky variant for use in slg::context::implementation" part of enum_fold was being used either