Stand-alone deriving declarations added

[Bulat Ziganshin]

Hello Simon,

Friday, October 6, 2006, 11:41:21 AM, you wrote:
> | declarations. The basic reason for maintaining a syntactic
> | distinction between instance declarations and deriving declarations
> | is to make the programmer aware of the restrictions of the deriving
> | mechanism.

unfortunately i don't see this whole message. but i disagree with this
statement - imho, using several different mechanisms for deriving
built-in classes, defining default instances, automatic generation of
instances by TH, generic class definitions and automatic deriving for
newtypes just confuse programmers and force to change code when one
mechanism is replaced with another (say, when Typeable becomes
built-in class instead of TH-generated one). so, i propose to leave
only two forms of automatic instance definitions:

- bundled with type definition: 'data ... deriving' clause
- decoupled from type definition: 'instance Class Type' clause

both forms should be allowed to be used with any class that may be
automatically derived:

1) built-in classes Eq, Ord...
2) any class derived for newtype
3) class that has default definitions for all its methods:
class (Enum a) => SuperEnum a where
    fromSuperEnum :: a -> Integer
    fromSuperEnum = toInteger . fromEnum

4) class that was defined using generics (currently GHC-only but i hope
   that future Haskell standards will support some form of Generic Haskell):
class Generic a where
  f :: a -> a
  f (x :+: y) = ...
  f (x :*: y) = ...

5) i propose to extend GHC to allow TH generate default instance
declarations. when one tries to derive XXX class, compiler should look
up derivingXXX TH function and if it is defined, use this function to
derive instance. so, the following:

data A = B | C  deriving(Binary)

should be translated into

data A = B | C
$(derivingBinary 'A)



Haskell is known as polymorphic language, but not generic one. It
still lacks simple and powerful mechanism to generate class instances.
Why i can't solve this problem completely, i hope that proposed
extension may build some bridge to generic Haskell future, allowing at
least GHC users to imagine that they work with compiler supporting
user-controlled deriving mechanism

imagine, for example, that you wrote serialization library with a
Binary class. in first version, you have defined default Binary
instance using generic classes:

class Binary a where
  put (x :+: y) = ...
  put (x :*: y) = ...

in the next version you have developed much more complex but efficient
TH-based instance generation code:

derivingBinary t = [| .... |]

in third version, GHC comes with built-in Binary class support.
and in the fourth version GHC includes Generic Haskell support so you
can define default instance using GH.

but independent of all these internal changes your clients continue to
use the same deriving mechanism:

data A = B | C  deriving(Binary)

is it not beautiful? :)


| b) For deriving declarations, the compiler figures out the
| constraints, whereas the programmer writes them for instance
| declarations.

it's real problem. in light of this i propose to extend 'deriving'
mechanism so that it can derive in all the above-mentioned ways. plus,
as Simon suggests, make the stand-alone 'deriving' clause the same
syntax as 'instance' without constraints:

data A = B | C  deriving(Binary)
data T a = T a

deriving Binary (T a)

where Binary deriving mechanism should by itself generate/check all
necessary constraints



-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com