Re: Request for feedback: deriving strategies syntax

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:
1. Look for a deriving strategy. If one is present, use that.
2. (a) If deriving an `Eq`, `Ord`, `Ix`, or `Bounded` instance for a
newtype, use the `GeneralizedNewtypeDeriving` strategy (even if the
language extension isn't enabled).
(b) If deriving a `Read`, `Show`, `Data`, `Generic`, `Generic1`,
`Typeable`, `Traversable`, or `Lift` instance for a newtype, go to
step 3.
(c) Otherwise, if deriving a "standard derivable class" (e.g.,
`Eq`, `Ord`, `Generic`, etc.) instance for a newtype, and
`-XGeneralizedNewtypeDeriving` is enabled, derive the class using the
`GeneralizedNewtypeDeriving` strategy.
(d) Otherwise, if deriving an instance for a newtype and both
`-XGeneralizedNewtypeDeriving` and `-XDeriveAnyClass` are enabled,
default to `DeriveAnyClass`, but emit a warning stating the ambiguity.
(e) Otherwise, if deriving an instance for a newtype, the datatype
and typeclass can be successfully used with
`GeneralizedNewtypeDeriving`, and `-XGeneralizedNewtypeDeriving` is
enabled, do so.
3. (a) If deriving a "standard derivable class" (e.g., `Eq`, `Ord`,
`Generic`, etc.) and the corresponding language extension is enabled
(if necessary), do so. If the language extension is not enabled, throw
an error.
(b) Otherwise, if `-XDeriveAnyClass` is enabled, use that.
(c) Otherwise, throw an error.
This is quite ugly, but to my knowledge this is currently what GHC
does (excluding 2(c), which is a bit that fixes a bug reported in Trac
#10598 [2]), so there shouldn't be any change in behavior from before.
This is another good reason to want deriving strategies: trying to
remember all of that is nearly impossible!
Ryan S.
-----
[1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies...
[2] https://ghc.haskell.org/trac/ghc/ticket/10598
On Wed, Aug 3, 2016 at 11:53 AM, Richard Eisenberg
On Aug 2, 2016, at 6:59 PM, Ryan Scott
wrote: Any other questions or comments? Yes, a question: What is the behavior if no keyword is given? Any change here from the status quo is quite dangerous from a backward-compatibility standpoint, but I wonder if we could start issuing warnings/errors in a few years.
Richard

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.

Kosyrev Serge <_deepfire@feelingofgreen.ru> writes:
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:
I apologize for the unfortunate metacircular logic in the below passage:
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
It should instead read as: 1. uniformity of expression of the desugaring transformation would have followed, in the following way: - the overall derivation mechanism is to become expressible through the following composition: - the separate derivation strategies are to become separate, named macro transformations, using a common library of type-level and other tools -- mostly those already in existence - this aforementioned common library is explicitly required to be sufficiently powerful to able to express the "bespoke" derivation mechanism - the combined strategy as an overarching macro tranformation The rest stands as is:
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, Косырев Сергей
participants (2)
-
Kosyrev Serge
-
Ryan Scott