time 1.1.2.4 is available on Hackage. This version of time should compile on Windows. It's been tested on a Vista machine that didn't have cygwin, just the standard GHC install. No other changes have been made.
On Fri, 2009-04-17 at 01:10 -0700, Ashley Yakeley wrote:
time 1.1.2.4 is available on Hackage.
This version of time should compile on Windows. It's been tested on a Vista machine that didn't have cygwin, just the standard GHC install.
No other changes have been made.
We will include this version in the first platform release. Duncan
Ashley Yakeley
time 1.1.2.4 is available on Hackage.
This version of time should compile on Windows. It's been tested on a Vista machine that didn't have cygwin, just the standard GHC install.
No other changes have been made.
Actually, parsing is now case-insensitive (e.g. month and timezone names). Also, 'Day' is an instance of 'Ix'. Thanks, Bjorn
Bjorn Buckwalter wrote:
Ashley Yakeley
writes: time 1.1.2.4 is available on Hackage.
This version of time should compile on Windows. It's been tested on a Vista machine that didn't have cygwin, just the standard GHC install.
No other changes have been made.
Actually, parsing is now case-insensitive (e.g. month and timezone names). Also, 'Day' is an instance of 'Ix'.
Oops. I probably should have called it 1.1.3 then. Instances of Typeable have been requested for various types. I'll add these for 1.1.3. -- Ashley Yakeley
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 System.Time. - jeremy
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 System.Time.
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
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 face. Cheers, Sterl. 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 System.Time.
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@haskell.org http://www.haskell.org/mailman/listinfo/libraries
I agree. I'm not a great fan of Data, but I use it for various kinds
of serializations.
If a library doesn't support data, well that just means I'll try to
avoid that library.
-- Lennart
On Sun, Apr 19, 2009 at 4:39 PM, Sterling Clover
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 face.
Cheers, Sterl.
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 System.Time.
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@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Lennart Augustsson wrote:
I agree. I'm not a great fan of Data, but I use it for various kinds of serializations. If a library doesn't support data, well that just means I'll try to avoid that library.
You wouldn't write your own orphan instance? -- Ashley Yakeley
If it's easy I would.
On Sun, Apr 19, 2009 at 10:59 PM, Ashley Yakeley
Lennart Augustsson wrote:
I agree. I'm not a great fan of Data, but I use it for various kinds of serializations. If a library doesn't support data, well that just means I'll try to avoid that library.
You wouldn't write your own orphan instance?
-- Ashley Yakeley
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. -- Ashley Yakeley 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 face.
Cheers, Sterl.
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 System.Time.
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@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Sun, 2009-04-19 at 13:58 -0700, Ashley Yakeley wrote:
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.
It's ok, abstraction is preserved by standalone deriving. You can only derive for types where you can import the constructors.
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.
Right, that seems like a sensible solution, that is to include Data instances that preserve the abstraction. As you say, that can be tested by initially writing the instances outside the package so that you can be sure it's only using the public interface. Duncan
It's great if the instances preserve the abstraction.
As I said, I'm not a fan of Data, but it makes certain things very convenient.
On Sun, Apr 19, 2009 at 11:41 PM, Duncan Coutts
On Sun, 2009-04-19 at 13:58 -0700, Ashley Yakeley wrote:
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.
It's ok, abstraction is preserved by standalone deriving. You can only derive for types where you can import the constructors.
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.
Right, that seems like a sensible solution, that is to include Data instances that preserve the abstraction. As you say, that can be tested by initially writing the instances outside the package so that you can be sure it's only using the public interface.
Duncan
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
2009/4/19 Ashley Yakeley
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.
I recall trying this some time ago. I think I gave up when I decided that I also needed Data instances for Data.Fixed. I was probably doing it wrong, but it was too large a yak for me to shave. Alistair
participants (7)
-
Alistair Bayley -
Ashley Yakeley -
Bjorn Buckwalter -
Duncan Coutts -
Jeremy Shaw -
Lennart Augustsson -
Sterling Clover