deriving...

[Claus Reinke]

>* I'd be happy to add the ability to separate a 'deriving' clause
>   from its data type declaration, if we can agree syntax
>   (see below).  It's fairly easy to do; it makes the language more
>   orthogonal; it's useful.
>
>   But in fact I think only Martin Sjögren has explicitly said that
>   the feature would be useful.... and every feature has a cost.

when you said people had asked for this before, I assumed you
didn't need further pro arguments, and I didn't want to argue against
a feature that would make recursive modules in Haskell less problematic.

but here are two examples from the answer I didn't send:

- library providers sometimes "forget" to provide useful instances,
    and "remote deriving" would permit programmers and their users
    to work around this without waiting for the next release (examples:
    points were not Show-able in earlier versions of wxHaskell, instances
    of Data/Typable were missing for the Haskell-AST in earlier versions
    of ghc&libs, ..). mostly interesting because so many ghc libs these
    days come as binary distributions, without source.

- library users sometimes need instances that library providers don't
    need (example: HaRe uses Programatica for its Haskell frontend, but
    uses Strafunski instead of Programatica's built-in generic programming
    support; for that, we needed the various AST types to be instances
    of the Data/Typable-equivalents, but we didn't want to change all the
    Programatica sources involved, which kept evolving independently;
    DrIFT allowed us to do this, but the recent DrIFT-less support for
    scrap your boilerplates doesn't provide an equivalent without
    "remote deriving". mostly interesting to improve modularity, and
    to avoid changes in externally-maintained code (a form of aspects?-).

I guess all DrIFT users would jump on the train if this was combined
with user-definable deriving.

>  deriving( Typeable (T a) )
>-- (B) Re-use 'deriving' keyword

avoiding new keywords seems preferable, but don't you need something
to attach this to? perhaps the import statement (if you don't define or import
it, you can't derive anything)?

    import Language.Haskell deriving (Typable HsExp, ..)

>The trouble with (B) is that the thing inside the parens is different in this
>situation than in a data type declaration.

depending on syntax, one might also be able to write things that are
currently not possible:

    module M where
    ..
    class Odd m b where ..
    data T a b c = ..

    import M deriving (Odd (T a Int) Zero,Odd (T Bool b) (Succ Zero))

without support for user-defined derive, the whole idea is a lot less
interesting, though Data/Typable and Read/Show probably account
for two major application areas.

still, will non-variable parameters be permitted, and do we know
what that means?

cheers,
claus