>> Would it be possible to get a Data instance for Data.Text.Text?
> From the last time this came up, I gather that the correctish thing to do
> (for reasons too obscure to me) is to teach SYB and its many cousins about
> Text, or else there'll be some sort of disturbance in the Force.
No, that's definitely not correct, or even remotely scalable as we
increase the number of abstract types in disparate packages. If
someone suggests it's necessary for their generics library, I suggest
you use Uniplate ;-)
There are two options, both listed in the above email.
1) Use string conversion in the instance. This is morally correct, and
works perfectly. However, as mentioned, it's not great performing. The
Map/Set instances both do a similar trick.
2) Just add deriving on the Data type, and hope no one abuses the
internals. This is what ByteString does, it works great, it's fast,
but you are violating some amount of abstraction. You have to trust
people not to break that abstraction, but it's not a simple
abstraction to break - it's the moral equivalent of pointer prodding
in a std::string, no one breaks it accidentally.
> If that feels too arduous, I'd consider adding your suggested instance of
> Data until such time as the One True Generics Package emerges to walk the
> earth. But please give it a think first.
Data.Data is the one true runtime reflection package, so Data
instances are strongly advised, totally ignoring Generics stuff. I
would pick option 2, but a Data instance really is useful.
Haskell-Cafe mailing list