Syb Renovations? Issues with Data.Generics

[Ian Lynagh]

On Thu, Jul 31, 2008 at 12:11:28AM +0100, Claus Reinke wrote:
> >On Tue, Jul 29, 2008 at 08:27:00PM +0100, Claus Reinke wrote:
> >>>>   My suggestion is to split this module into two, and stop the implicit
> >>>>   import/export of the incomplete instances from Data.Generics.
> >>>I don't think that this is a good idea.
> >>Could you please elaborate on your reasons?
> >That's what the rest of that e-mail was supposed to be.
> 
> You explained why the change would not give as much flexibility as
> one might think, or at least not as easily, but you didn't explain why
> you think it is a bad idea to gain at least the flexibility to choose
> between instance and no instance for the problematic cases.

Ah, I see.

There are two reasons why one might not want to have, e.g., an IO
instance. The first one is to help the programmer find errors: if your
program relies on having the instance then it's probably buggy (modulo
the deriving instances thing).

I've done a bit of generic programming (although doubtless not as much
as others on this list) and haven't found this to be an issue.

Note that if you took a correct program without the instance, and added
the instance, then the program would still compile.


The other one is because you want to define your own instance. Hopefully
your instance differs from the existing one in some way (but if it's
moved into a different module then it's likely that people will recreate
the same empty instance because they don't realise that one already
exists).

If people start doing this then we will get libraries which cannot be
used in the same project. I therefore don't think that we should make it
possible for people to do this.

> >By the way, is there something somewhere describing the alternate
> >instance that you want to define?
> 
> That is the whole point, isn't it? The Data framework isn't designed
> to cope with things like (a->b) or (IO a), so there are no good instances 
> one could define for these types

OK, I think I've missed your point then. I've just reread the message
you started this thread with, and you say this:

>     Pro: - the instances are still available, and only one explicit import
>                 away, so 'deriving instance Data' for types containing
>                 uninteresting functions is still convenient
> 
>             - the problematic instances are no longer implicitly imported,
>                 so applications that don't want these instances can now
>                 avoid them completely, or define their own instances
> 
>             - these convenience instances are not just inconvenient for
>                 some applications, due to the way intances are handled
>                 in Haskell; they actually violate some "natural" invariants
>                 like "everything queries every substructure of the specified
>                 type", "everywhere applies a transformation at every
>                 substructure of matching type"
> 
>             - the situation is similar to Text.Show.Functions, as the
>                 convenience instances don't provide the full expected
>                 functionality, just barely enough for deriving to get by
> 
>     Cons: - due to the implicit import and use of these instances,
>                     there is no obvious transition scheme; it seems that
>                     the least painful process would be to make the change
>                     without transition/deprecation period and to document
>                     the explicit import option
> 
>                 [it would be useful to have a way of deprecating instance
>                 imports, so that any deriving scheme depending on imports
>                 from a deprecated location would trigger a warning, in this
>                 case suggesting the new import location]

These are supposed to be pros and cons of moving the instances into
their own module, as opposed to the status quo, right?

If so, the first "pro" isn't a pro at all. Debatably it's a con - it
would make it less convenient to derive instance Data for types
containing IO etc.

For the second one, not having an instance doesn't help a program
(although it may help a programmer find his errors, which I agree is a
pro), and you say that you can't think what an alternative instance
would be. Even if you could, I still think that you shouldn't be able to
define an alternative instance, as I said above, so I think that that is
a con.

The third one is more-or-less "help a programmer find his errors" again,
I think?

And the fourth one is just an observation, neither a pro or a con.

Incidentally, another con is that it means the instances have to be
orphan instances.


I don't see a benefit to moving the instances to their own module, which
outweighs the downsides, in my opinion.

> Scenario 2:
> 
>    Any attempt to use Data (a->b) or Data (IO a) indicates an
>    error. If we want to derive Data for complex structures containing 
>    those types, we need to define Data instances for the immediately
>    enclosing structures, or wrap those types in newtypes and define
>    Data instances for those. This is the case for which the incomplete
>    instances get in the way.

How do they "get in the way"? Do you mean the typechecker doesn't tell
you which instances you need to define by hand, because deriving worked?

> PS. The situation is not improved by the current reexports of 
>    Data.Generics.Instances from unexpected places.

Instances are not reexported, instances are global. Not even just within
a project, but between every single library on hackage; pick any two
libraries, and eventually someone is going to want them in the same
program.

(That module also contains things like "instance Data Int", so it's not
surprising that lots of things need it)


Thanks
Ian