Haskell platform proposal: time-extras package

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Haskell platform proposal: time-extras package

Ashley Yakeley
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

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Haskell platform proposal: time-extras package

Ian Lynagh
On Sat, Mar 20, 2010 at 01:37:35AM -0700, Ashley Yakeley wrote:
>
> The "time-extras" package contains functionality that would be in "time"  
> were it not for the 98 restriction.

Personally, I would prefer the restriction were lifted instead.


Thanks
Ian

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Haskell platform proposal: time-extras package

Malcolm Wallace
In reply to this post by 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

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Haskell platform proposal: time-extras package

Ashley Yakeley
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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Haskell platform proposal: time-extras package

Malcolm Wallace
>
>> 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

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Haskell platform proposal: time-extras package

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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Haskell platform proposal: time-extras package

Simon Michael
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!

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Haskell platform proposal: time-extras package

Simon Michael
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.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Haskell platform proposal: time-extras package

Edward Kmett-2
In reply to this post by Ashley Yakeley
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 <[hidden email]> wrote:
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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Haskell platform proposal: time-extras package

Ashley Yakeley
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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries