ANN: time-extras 1.1.4 - Libraries - Haskell.org

newer
template haskell (Debian & chart)

ANN: time-extras 1.1.4

older
darcs patch: lower base...

Ashley Yakeley

23 Dec 2009 23 Dec '09

3:45 a.m.

time-extras 1.1.4 contains Data instances for types defined in time-1.1.4. They are in a separate package because they require RankNTypes, which is not Haskell 2010. Get it from Hackage. http://hackage.haskell.org/package/time-extras -- Ashley Yakeley

Reply

Sign in to reply online Use email software

Show replies by date

Yitzchak Gale

27 Dec 27 Dec

4:43 p.m.

On Wed, Dec 23, 2009 at 10:45 AM, Ashley Yakeley wrote:

time-extras 1.1.4 contains Data instances for types defined in time-1.1.4. They are in a separate package because they require RankNTypes, which is not Haskell 2010.

Nice! It may be a bit late, but in my opinion you might consider changing the package name for future versions. Time is fundamental, ubiquitous, and yet quite complex. There are innumerable ways in which the time package is likely to be extended. Personally, I almost never use syb. Data instances are probably the last thing I would expect to find in a package called "time-extras". So to me this seems like a rather peculiar way to use up such a generic name. Thanks, Yitz

Reply

Sign in to reply online Use email software

Ashley Yakeley

5:02 p.m.

On Sun, 2009-12-27 at 23:43 +0200, Yitzchak Gale wrote:

It may be a bit late, but in my opinion you might consider changing the package name for future versions. Time is fundamental, ubiquitous, and yet quite complex. There are innumerable ways in which the time package is likely to be extended. Personally, I almost never use syb. Data instances are probably the last thing I would expect to find in a package called "time-extras". So to me this seems like a rather peculiar way to use up such a generic name.

It really means "stuff that ought to be in time, but can't be due to language compatibility reasons". The time-extras package should probably be in the Haskell Platform, and it may eventually get merged into the time package. -- Ashley Yakeley

Reply

Sign in to reply online Use email software

Lennart Augustsson

28 Dec 28 Dec

7:57 a.m.

Data instances are not just there for syb. There are needed for many kinds of generic programming. For instance, the generic JSON serializer uses Data, and it's nice to be able to serialize even time related things. Another example (which I use a lot) is Uniplate. I see Typeable and Data as a way to provide a certain amount of reflection, and I think they should be derived wherever possible. Using them is a different matter; I think they should be used sparingly. But when you need them, they are very useful. -- Lennart On Sun, Dec 27, 2009 at 9:43 PM, Yitzchak Gale wrote:

On Wed, Dec 23, 2009 at 10:45 AM, Ashley Yakeley wrote:

...
time-extras 1.1.4 contains Data instances for types defined in time-1.1.4. They are in a separate package because they require RankNTypes, which is not Haskell 2010.

Nice!

It may be a bit late, but in my opinion you might consider changing the package name for future versions. Time is fundamental, ubiquitous, and yet quite complex. There are innumerable ways in which the time package is likely to be extended. Personally, I almost never use syb. Data instances are probably the last thing I would expect to find in a package called "time-extras". So to me this seems like a rather peculiar way to use up such a generic name.

Thanks, Yitz _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Reply

Sign in to reply online Use email software

Yitzchak Gale

8:08 a.m.

I wrote:

...
...
It may be a bit late, but in my opinion you might consider changing the package name for future versions.

Ashley Yakeley wrote:

...
It really means "stuff that ought to be in time, but can't be due to language compatibility reasons". The time-extras package should probably be in the Haskell Platform, and it may eventually get merged into the time package.

Lennart Augustsson wrote:

Data instances are not just there for syb... I think they should be derived wherever possible. Using them is a different matter; I think they should be used sparingly. But when you need them, they are very useful.

OK, thanks Ashley and Lennart for the explanations. Still - something more descriptive of the content, like time-generic or time-reflection or time-data-instances, might have been more informative. Hackage is quickly becoming an unnavigable tangled jungle. Thanks, Yitz

Reply

Sign in to reply online Use email software

Duncan Coutts

9:42 p.m.

On Wed, 2009-12-23 at 00:45 -0800, Ashley Yakeley wrote:

time-extras 1.1.4 contains Data instances for types defined in time-1.1.4. They are in a separate package because they require RankNTypes, which is not Haskell 2010.

Can you remind us why it's not reasonable to have the time package (conditionally) provide Data instances? I don't think we can say that we must restrict ourselves to the Haskell 2010 language extensions when the base package is using Rank2Types in its public API. We clearly need a general solution. It's silly to have every package have a separate companion that provides Data instances. In this instance, CPP doesn't seem like too bad a solution. The people who want to use the Data class are clearly not using compilers that do not support Rank2Types. Duncan

Reply

Sign in to reply online Use email software

Bulat Ziganshin

29 Dec 29 Dec

2:50 a.m.

New subject: Re[2]: ANN: time-extras 1.1.4

Hello Duncan, Tuesday, December 29, 2009, 5:42:49 AM, you wrote:

Can you remind us why it's not reasonable to have the time package (conditionally) provide Data instances?

I don't think we can say that we must restrict ourselves to the Haskell 2010 language extensions when the base package is using Rank2Types in its public API.

may be because this make time package compatible with hugs/nhc (if it makes)? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Reply

Sign in to reply online Use email software

Malcolm Wallace

6:03 a.m.

I don't think we can say that we must restrict ourselves to the Haskell 2010 language extensions when the base package is using Rank2Types in its public API.

... and this is one of the great flaws of the base package. Because of such non-standard extensions, the 'base' package API is _not_ universally available across all compilers. I strongly believe that 'base' is a misnomer, and we should consider hiding 'base' altogether, and creating a 'real-base' package that is (a) compliant to the language standards, (b) contains no compiler-specific modules or functions. Regards, Malcolm

Reply

Sign in to reply online Use email software

Ian Lynagh

6:30 a.m.

On Tue, Dec 29, 2009 at 11:03:02AM +0000, Malcolm Wallace wrote:

...
I don't think we can say that we must restrict ourselves to the Haskell 2010 language extensions when the base package is using Rank2Types in its public API.

... and this is one of the great flaws of the base package.

Because of such non-standard extensions, the 'base' package API is _not_ universally available across all compilers. I strongly believe that 'base' is a misnomer, and we should consider hiding 'base' altogether, and creating a 'real-base' package that is (a) compliant to the language standards,

I think it would be more efficient to achieve this by working on standardising the necesary extensions for H'2011. Thanks Ian

Reply

Sign in to reply online Use email software

Duncan Coutts

12:39 p.m.

On Tue, 2009-12-29 at 11:03 +0000, Malcolm Wallace wrote:

...
I don't think we can say that we must restrict ourselves to the Haskell 2010 language extensions when the base package is using Rank2Types in its public API.

... and this is one of the great flaws of the base package.

Because of such non-standard extensions, the 'base' package API is _not_ universally available across all compilers. I strongly believe that 'base' is a misnomer, and we should consider hiding 'base' altogether, and creating a 'real-base' package that is (a) compliant to the language standards, (b) contains no compiler-specific modules or functions.

Sure, that'd also be a good solution. I do in principle support making base more portable and exporting the same API for all compilers. (I had to modify zlib the other day because of some ForeignPtr function which seems needlessly to be ghc-only.) In the mean time I don't see that it makes sense to do it using CPP for most core/platform packages and completely differently for the time package. Duncan

Reply

Sign in to reply online Use email software

5623

Age (days ago)

5629

Last active (days ago)

Download

9 comments

7 participants

tags

participants (7)

Ashley Yakeley
Bulat Ziganshin
Duncan Coutts
Ian Lynagh
Lennart Augustsson
Malcolm Wallace
Yitzchak Gale