Ryan Scott
That is a good question. Weirdly enough, the current behavior for how a deriving strategy is resolved (without explicit keywords) isn't really documented anywhere, so I attempted to figure out what GHC currently does and documented it here [1]. I'll reproduce the algorithm (including deriving strategies) below:
<tough list snipped> How much of this derivation machinery could NOT be implemented by means of some kind of a (hypothetical) type-backed metaprogramming facility? The beauty of an open implementation[1] allowed by such a thing is that: 1. uniformity of definition of the desugaring transformation would have followed, and from that: - the "bespoke" derivation mechanism will suddenly become explainable in a language shared by all derivation mechanisms: - the separate derivation strategies as separate, named macro transformations, using a common library of type-level and other tools -- mostly those already in existence - the combined strategy as an overarching macro tranformation - therefore, users would have been empowered to easily provide derivation mechanisms of the same power as "bespoke", plugging into the aforementioned scheme 2. because of above, we get a starting point from which we can evolve something that can be meaningfully standartized, without a feeling of shame or guilt -- we now have a language describing the problem domain, that can be un-tied from a particular implementation 3. in-editor macroexpansion is a proven, working concept in the realm of Proper Metaprogramming (viz. Common Lisp etc.), and it would basically eliminate guesswork from user workflows ..or is this all a violent pipe dream? -- с уважениeм / respectfully, Косырев Сергей -- 1. The concept of an "open implementation" comes from a paper by Kiczales and Paepcke. Although the concept comes from the context of metaobject protocols the core idea seems universally applicable -- careful exposure and reification of implementation machinery can be beneficial.