Splitting SYB from the base package in GHC 6.10

[José Pedro Magalhães]

Hello,

On Mon, Sep 1, 2008 at 21:04, Claus Reinke <claus.reinke at 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.
>

By "everything" do you mean all instances or all the "dubious" ones? IIRC,
the argument for having the "standard" instances in base is that leaving
Data alone without any instances would mean that in most cases you would
have to import SYB anyway to get any functionality. Or are there other
reasons?


Thanks,
Pedro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20080901/0bb4da79/attachment.htm