Haskell platform proposal: time-extras package
All, I'd like to propose my "time-extras" package to be included in the next major release of the Haskell platform. The "time" package, which is already in the Haskell Platform, is currently restricted to Haskell 98. This means that it cannot, for instance, export instances of the Data class (since this requires Rank2 or RankN). The "time-extras" package contains functionality that would be in "time" were it not for the 98 restriction. Its version number matches that of "time". Currently, it consists only of Data instances. I am the author and maintainer of "time" and "time-extras". Everyone is invited to review this proposal, following the standard procedure for proposing and reviewing packages: http://trac.haskell.org/haskell-platform/wiki/AddingPackages You can always find the latest version of this proposal here: http://trac.haskell.org/haskell-platform/wiki/Proposals/time-extras Hackage link: http://hackage.haskell.org/package/time-extras -- Ashley Yakeley
The "time" package, which is already in the Haskell Platform, is currently restricted to Haskell 98. This means that it cannot, for instance, export instances of the Data class (since this requires Rank2 or RankN).
Correct me if I am wrong, but the "time" package already uses extensions beyond Haskell'98. It certainly imports the ReadP library, which requires Rank2, and so no pure Haskell'98 compiler can build the time package. Regards, Malcolm
Malcolm Wallace wrote:
Correct me if I am wrong, but the "time" package already uses extensions beyond Haskell'98. It certainly imports the ReadP library, which requires Rank2, and so no pure Haskell'98 compiler can build the time package.
Oops, my mistake, you're quite right. And I should say "time" already uses HierarchicalModules, FFI and CPP. I was originally going to put the Data instances in "time", but you objected: http://www.haskell.org/pipermail/libraries/2009-June/011791.html http://www.haskell.org/pipermail/libraries/2009-June/011796.html What do you recommend? -- Ashley Yakeley
Correct me if I am wrong, but the "time" package already uses extensions beyond Haskell'98. It certainly imports the ReadP library, which requires Rank2,
I was originally going to put the Data instances in "time", but you objected:
http://www.haskell.org/pipermail/libraries/2009-June/011791.html http://www.haskell.org/pipermail/libraries/2009-June/011796.html
What do you recommend?
At the time of that objection, I did not realise that "time" already required Rank2. My preference would be for "time"s dependency on ReadP to be removed in favour of a H'98 parsing combinator library, thus bringing "time" back to true portability. (Back in the autumn, I did spend some time attempting to re-code "time"s parsing code precisely to remove the ReadP dep, but never completed it.) However, you might consider that a step too far, in which case adding the Rank2-requiring Data instances into "time" might be the better solution for you. Regards, Malcolm
Malcolm Wallace wrote:
At the time of that objection, I did not realise that "time" already required Rank2. My preference would be for "time"s dependency on ReadP to be removed in favour of a H'98 parsing combinator library, thus bringing "time" back to true portability.
(Back in the autumn, I did spend some time attempting to re-code "time"s parsing code precisely to remove the ReadP dep, but never completed it.)
However, you might consider that a step too far, in which case adding the Rank2-requiring Data instances into "time" might be the better solution for you.
Merging the Data instances into "time" is certainly my preference. But if there were consensus for it and code for it, I would consider a solution that made "time" not require Rank2. -- Ashley Yakeley
I'm not aware of all the issues, but I recently tried and failed to store time types (UTCTime, etc.) in a happstack-state db - IIRC they can't be serialised in happstack, because you can't derive Data instances, because some low-level type does not expose it's constructors. I've had to use old-time because of this. So I believe I'd be another +1 vote for time providing Data and Typeable instances. Thanks!
Oops! You know all this. Well, count me as +1 for either the original proposal (including time-extras in HP) or for including those instances in time.
I would definitely prefer to have the Data/Typeable instances in the 'time'
package itself wrapped with the same sort of prophylactic baggage that
surrounds it in the containers, bytestring, and other haskell platform
packages. It would be far less likely to cause confusion in the future than
with the profusion of solutions we see today:
* some packages providing it
* others requiring a third-party package
* and yet others not exposing enough details for third-party support to be
written at all
Regardless, some canonical location for those instances needs to exist to
prevent people from rolling their own contradictory instances.
So I'm a strong +1 to just including the instances in an appropriate wrapper
to be extended as more compilers add support, and a reluctant but still
sturdy +1 if you really feel that those instances really can't be in good
conscience be rolled into time.
-Edward Kmett
On Mon, Mar 22, 2010 at 4:27 AM, Ashley Yakeley
Malcolm Wallace wrote:
At the time of that objection, I did not realise that "time" already required Rank2. My preference would be for "time"s dependency on ReadP to be removed in favour of a H'98 parsing combinator library, thus bringing "time" back to true portability.
(Back in the autumn, I did spend some time attempting to re-code "time"s parsing code precisely to remove the ReadP dep, but never completed it.)
However, you might consider that a step too far, in which case adding the Rank2-requiring Data instances into "time" might be the better solution for you.
Merging the Data instances into "time" is certainly my preference. But if there were consensus for it and code for it, I would consider a solution that made "time" not require Rank2.
-- Ashley Yakeley
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Edward Kmett wrote:
I would definitely prefer to have the Data/Typeable instances in the 'time' package itself wrapped with the same sort of prophylactic baggage that surrounds it in the containers, bytestring, and other haskell platform packages.
This looks like the way to go. Malcolm would get his 98-buildable "time", albeit without parsing functionality. And there would be only one package to deal with rather than two. -- Ashley Yakeley
participants (5)
-
Ashley Yakeley -
Edward Kmett -
Ian Lynagh -
Malcolm Wallace -
Simon Michael