how to permit this: "Found type classes: [(%,,,,,,,,%)]" #74
Comments
|
Glad you like it, I hope you’ll be able to use it.
This is the code: inspection-testing/src/Test/Inspection/Core.hs Lines 84 to 117 in c2bfd2d So the answer is: All local definitions involved in the definitions you ask for. So
That’s a constraint tuple, right? Yes, this could probably be filtered out in any case – if there are unwanted type classes, they will be inside.
I am not quite sure what’s best to do here. After all, the code does mention the type classes, doesn’t it?
Hmm, that's a bit odd. I wonder if it is due to inspection-testing/src/Test/Inspection/Core.hs Lines 173 to 179 in c2bfd2d Unfortunately, I don’t quite remember why I added that setting. |
"Local" meaning from the same module? So that's fully recursive, but only within the module (plus inlines). Thank you for the clarification. In that case I should start adding the
Yes, it's the constraint tuple. That would be very helpful.
Yes, it does. But the classes in the code snippet are all in type applications applied to a function from outside the module (from the
This is not a big deal for me. I need the full Core anyway. A bigger problem is that I'm still unsure how to get the Core corresponding to the output of |
If you expect your function (say
It should install itself at the very end of the core2core pipeline, according to https://hackage.haskell.org/package/inspection-testing-0.5.0.2/docs/src/Test.Inspection.Plugin.html#install. In the worst case, |
Do you want to patch it yourself for now and see if it helps, and then maybe create a PR? |
Yes,
Here you go. This made two of my tests pass, but the remaining two stumble, among other problems, over a type-level programming tilde operator (probably https://hackage.haskell.org/package/ghc-9.6.1/docs/GHC-Prelude-Basic.html#t:-126-?). No idea how it can be called. One of these: https://hackage.haskell.org/package/ghc-9.6.1/docs/GHC-Builtin-Types.html#g:20 perhaps? |
|
See This is |
Thanks, that explains things.
When I add it says "Variable not in scope: (~) :: TyCon", so the laziest approach, at least, fails. |
|
Do you want to add it to the inspection testing code, or to the list of allowed typeclasses in your own assertion? |
I did add it to the PR. I see I misunderstood your question about
Oh, but your |
Hah, |
But looking at signatures is not enough, either. I've just, thanks to your tool, tracked down a failed specialization of my function that was inlined and the inlined code was polymorphic instead of specialized and it was applied to dictionaries (which is why it was flagged). There was no type signature to inspect in this case. A general solution is harder than I thought. But your tool gives a good overestimation, which I can then refine with the list of exceptions. And scanning also type signatures would probably not catch any new failed specialization cases. Edit: actually the inlined code was not specialized, because the function calls it contained failed to specialize, so this would be visible in the signatures of the respective functions, but they are from another module and so not "local". So scanning beyond type signatures is at least a needed crutch for only having "local" visibility. |
|
I wonder, do constructors (in patterns or expressions) applied to dictionaries ever hint at a failed specialization? E.g., I'm yelled at for (note If that's never an indication of a failed specialization (perhaps on a function from another module we only see applied), it would be helpful to me to ignore such dictionary occurrences. Is it easily done? Or perhaps a general mechanism "ignore class C in context such and such" instead of the current "ignore class C". Edit: and the constructor in this example has existentially quantified variables this dictionary relates to. But perhaps this can happen without existential quantification, though I'd hope, in any case, it's never the only hint for any specific specialization failure and so can be ignored. |
|
I don't know if ”specialization works” is such a clearly defined concept, and depends more what you want to do. But if it means “this typeclass isn't mentioned anymore”, shouldn't this also apply to constructors with existentials? But it may depend on the concrete optimizations you desire. A richer API for specifying where in the AST what kind of things should or shouldn't be might be useful, but so far I didn't have a good inspiration for a good comprehensive designs. |
Yes, you are right this is ambiguous. I'm using the intuition that successful specialization of a set of functions monomorphises the types of all their calls in the whole program (this is a property only of the signatures of the specialized variants; the function bodies can have all kinds of spurious polymorphism in ignored or executed only for impure side-effects let expressions as long as the type variables don't escape to the signatures). This is extreme, but resolves a lot of the ambiguity. Existential types fit the monomorphisation intuition in that all their free type variables need to be monomorphised away, as with any other type. The bound existential variables are not free and so monomorphisation does not even see them.
Not at all. This is why I "abuse" your tool for my purpose. :) In fact, dictionaries and class overloading specialization (in the monomorphisation sense), are rather loosely related. E.g., one can add a constraint |
Hi! This is a great tool. I'm (ab)using it to find specializations that failed to fire. I have several problems (ab)using it in this way (with GHC 9.4.6):
-fexpose-all-unfoldings, so that's probably a lot of the core.2, When it says "Found type classes: [(%,,,,,,,,%)]" I don't know how to add this name to the list of exceptions for
hasNoTypeClassesExcept(see the snippet below for how that class arises). Could it perhaps be filtered out globally? That's a class that the user can add manually, is it?DynamicExistsis an existential type getting unpacked and all the constraints are normally hidden inside it (and additionally hidden as superclasses of aGoodScalarclass). butsameTypeRepdecides to uncover them all, leading to many exceptions forhasNoTypeClassesExcept:-ddump-stranal(e.g., it lacks some of the made-up identifier suffixes, e.g,. aboverandr_ikSLare bothr_ikSLin-ddump-stranaloutput). An extra problem with-ddump-stranalis that the option dumps Core twice. What else should I be using?The text was updated successfully, but these errors were encountered: