On Mon, Sep 1, 2008 at 21:04, Claus Reinke
<claus.reinke@talk21.com> wrote:
"no other possible implementation" is an overstatement, though an easy
one to make: those 'Data' instances are incomplete because better instances
are hard to come by. One can perhaps do little improvements, like replace
the effective 'gmapT = id' for 'IO a' and 'b -> a' with something like[1]:
gmapT f fun = f . fun
-- instead of gmapT f fun = fun
gmapT f io = (return . f) =<< io
-- instead of gmapT f io = io
But wouldn't these introduce additional inconsistencies? At least if introduced in the library itself. I am used to think that gmapT is implemented using gfoldl, and is only inside the Data class to allow for more efficient implementations, and not for alternative implementations...
Another way to look at it:
'Data' tries to do too much in a single class, and the consequence
are all those half-implemented 'Data' instances. The probable
long-term solution is to split 'Data' into 2 or 3 classes,
so that we know that
a any type instantiating 'DataGfoldl' really supports 'gfoldl'
b any type instantiating 'DataGunfold' really supports 'gunfold'
c any type instantiating 'DataReflect' really supports 'Data' reflection
Currently, too many types instantiate 'Data' without supporting b
or c (-> runtime errors), and a few instances don't even support a.
All of which suggests that 'Data' should probably leave 'base',
as it needs to evolve further?
Just for my understanding, can you give me an example of a datatype which currently has (b) but not (c) and vice-versa?
Anyway, I guess keeping Data inside base does not preclude such splitting of Data: for backward compatibility the original Data would have to remain available, right?
|Claus argued that -> and the monads could be treated by analogy
|with Show for these types.
I had mentioned 'Text.Show.Functions' as an example of "improper"
instances provided for optional import to support 'deriving Show'.
But when I read your sentence, my first thought was: perhaps there's
also a way to apply the showList trick? That would neatly avoid either
changing the 'deriving' mechanism or having dummy instances.
More reason for moving everything to 'syb', keeping it flexible
for a while.