Data and Typeable instances
ashley at semantic.org
Sun Apr 19 16:58:03 EDT 2009
I will not expose any private structure of types via instances of the
Data class. I can't see what benefits SYB brings that it outweighs such
loss of abstraction. And if someone else wants to shoot themselves in
the foot by using standalone deriving, that's their problem.
However, this might not be an issue, as I believe all the constructors
of all or almost all types in time are public. If it is possible for a
user of time to hand-write instances of Data using only what time
exposes, then it is safe to include those instances in the package.
Sterling Clover wrote:
> Am I to take it that you will not be providing Data instances because
> you find them "unhaskellish"? The time package is a core part of Haskell
> functionality, and those Data instances are sorely missed by a wide
> range of libraries. As the maintainer of a key part of the Haskell
> ecosystem, I think you are obligated to take into account not only what
> you find to be the "good bits," but also to provide instances such as
> Data that, even if you find them "unhaskellish" allow the library to
> better integrate into the Haskell package ecosystem as it now stands.
> Furthermore, if such instances are not provided, they will be created
> with standalone deriving. The instances created by standalone deriving,
> unlike instances which can be partially hand-written, will provide even
> less in the way of preservation of the abstract nature of certain data
> types. In the end, you may only be cutting off your nose to spite your
> On Apr 18, 2009, at 8:26 PM, Ashley Yakeley wrote:
>> Jeremy Shaw wrote:
>>> At Fri, 17 Apr 2009 11:55:51 -0700,
>>> Ashley Yakeley wrote:
>>>> Instances of Typeable have been requested for various types. I'll
>>>> add these for 1.1.3.
>>> Sweet! Data as well? Happstack uses Data and Typeable for
>>> serialization. It would be nice to be able to use Data.Time instead of
>> I'm not sure. I find the whole SYB approach unhaskellish, as it treats
>> values based on their internal structure rather than their types. But
>> perhaps serialisation is a harmless use of the Data class.
>> Typeable is also rather unhaskellish. A haskellish approach would be
>> to use type witnesses, but it requires open witness declarations as a
>> language extension. So, Typeable it is.
>> Ashley Yakeley
>> Seattle, WA
>> Libraries mailing list
>> Libraries at haskell.org
More information about the Libraries