Fabian Zickgraf

Thanks for the thorough explanation! Splitting `init.g` sounds nice but also quite intricate (at least for me after a quick grep). Two other thoughts just came to my mind: 1....

Thanks a lot for the fast reply and analysis of the problem! Based on your suggestion I have added a workaround to `CompilerForCAP` where we originally encountered this issue: https://github.com/homalg-project/CAP_project/pull/919....

I just came across this old issue: I have verified that the fix is now included in GAP.jl (probably for more than two years now), thanks again @fingolfin! :-)

> Any more changes required? Sorry, I wasn't aware that you already added the changes. I will have a look.

Is this related to https://github.com/homalg-project/CAP_project/pull/1501? > This is a nice example for proving using the compiler as a proof-assistant that Hom(a ⊗ b, c) → Hom(b, hom(a,c)) in the above-mentioned...

Yes, this is intended: FreydCategoriesForCAP was added as a suggested dependency of ModulePresentationsForCAP in db187f9bc0ef363f8922234c1c1d7b1873e34c71 to allow the user to create left/right presentations with "no_precompiled_code := true". But since "no_precompiled_code...

> I'm currently working through the list your code generates and several derivations are from `MonoidalCategories`. Nice :-) > Typically, both the closed and coclosed cases of a derivation are...

> So I hoped, if I add these `WithGiven`'s in the closed case, I could for now skip adding them in the coclosed case and later just generate the coclosed...

> What triggered an error is the comparison of compiled code at the end of your code (in the range case). I think because not all operations could be resolved,...

@TKuh FYI: I have removed the commit containing `CheckDerivationSourceAndRange` from my branch `math_output` and have instead created a new branch `CheckDerivationSourceAndRange` with only that commit.