To my
>> And I do not understand, why Haskell does not support `deriving'
>> for all the instances (user's too), at least, for newtype.
Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> writes
> It could be a good idea. But what about deriving Show and Read
> (should derived Show instance for newtype N = N Int produce "N 5" or
> "5" for show (N 5)?). I can see arguments for both choices.
I meant - to derive all the instances the user listed in the
declaration
newtype ... deriving( class1, class2 ... ),
and enabling the user to include in this list the user classes, not
only the standard ones.
If say, the standard Show shows with "N 5" and the user does not
like this, one can define one's own Show and skip it in the
`deriving' list.
>> When the user writes
>> class C a where c :: a -> a
>> instance C Int where c = (+2)
>> newtype Int1 = Int1 Int deriving(Eq,Ord,Num,C),
>>
>> is not it clear automatically how Num, C are defined?
> For newtypes it usually is, but not always.
>
> import AnotherModule (
> Bar, -- Abstract type.
> reverseBarInt) -- :: Bar [Int] -> Bar [Int]
> where
> class Foo a where
> reverseFoo :: Bar [a] -> Bar [a]
> instance Foo Int where
> reverseFoo = reverseBarInt
>
> What does it mean to derive Foo Int1 from Foo Int?
Maybe, indeed, the subject is not so simple.
Generally, the compiler occurs in a situation like
T <--> N T -- new type over T
class C a where c :: E1<a> -> E2<a>
instance C T where c = ...
with E1<a>, E2<a> some type expressions, like, for example,
(a,[(a,Char)]).
The automatic creation of instance C (N T) where c x = ...
requires to derive the casts cast1 from E1<N T> to E1<T>
and cast2 from E2<T> to E2<N T>,
and to compose c = c2 . (c of C T) . c1
I am not sure now, that this can be automatically arranged.
Maybe, this is why Simon P.Jones suggested to introduce the
explicit `cast' in the language (for the user to define it?).
>> Further, for data D a = D ...
>> if the user had defined for a <--> D a the castings
>> f :: a -> D a,
>> f' :: D a -> a
>> (reciprocally inverse ones),
>> could the compiler understand what does this mean
>> ...= D...deriving ((C by maps (f,f')),...)
>>
> IMHO such complication is definitely not needed. It's ugly.
It may occur hardly implementable, for the reasons mentioned above.
But being ugly - I do not agree.
To say "port the operations op1,op2,op3 via the isomorphism f"
is very nice. It saves the code. And is just a part of culture.
It is good for any programming language to introduce it, if
possible.
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
