Request for feedback: deriving strategies syntax

[Kosyrev Serge]

Ryan Scott <ryan.gl.scott at gmail.com> writes:
> 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.