Re: time library dependencies
If you care at all about Haskell 98 compatibility, now would be a really good time to speak up. Remember, silence implies consent. -- Ashley Ashley Yakeley wrote:
I'm looking to update the time library in response to various requests. Right now it has some weird split-base 2/3 dependency thing going on, and uses only FFI and CPP language extensions.
Will it cause anyone any problems if
* it depends >=base-4.1? * it requires GeneralizedNewtypeDeriving and DeriveDataTypeable to build?
The Haskell language is kind of a moving target right now.
From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Ashley Yakeley
If you care at all about Haskell 98 compatibility, now would be a really good time to speak up. Remember, silence implies consent.
Ashley Yakeley wrote:
Will it cause anyone any problems if
* it depends >=base-4.1? * it requires GeneralizedNewtypeDeriving and DeriveDataTypeable to build?
Without wanting to sound like I'm telling you to suck eggs... What are the code standards for the HP libs? I was under the impression that it was best to maintain H98 compatibility where possible, especially so for libraries in the old standard libs distribution. I did a quick search for platform standards but didn't find anything relevant. For H98 compatibility, is it not too onerous to have generated or hand-written Data & Typeable instances in the source? I'm guessing that the library is fairly stable, so I'd expect that it would add little to the maintenance costs (but then I'm not maintaining time, so that's a fairly glib claim). Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************
On Tue, 2009-06-02 at 09:08 +0100, Bayley, Alistair wrote:
For H98 compatibility, is it not too onerous to have generated or hand-written Data & Typeable instances in the source?
It's not clear to me that I can even write Data instances without Rank-2 or Rank-N types. However, I am willing to forgo Data instances to preserve H98 compatibility, if people think that is worthwhile. -- Ashley
Hello Alistair, Tuesday, June 2, 2009, 12:08:11 PM, you wrote:
What are the code standards for the HP libs? I was under the impression that it was best to maintain H98 compatibility where possible, especially so for libraries in the old standard libs distribution. I did a quick search for platform standards but didn't find anything relevant.
how about using common subset of current Hugs, GHC and Haskell'? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Tue, 2009-06-02 at 09:08 +0100, Bayley, Alistair wrote:
What are the code standards for the HP libs? I was under the impression that it was best to maintain H98 compatibility where possible, especially so for libraries in the old standard libs distribution. I did a quick search for platform standards but didn't find anything relevant.
It's yet to be discussed on this list. Perhaps this is a good opportunity to start that discussion. Do you want to draft a reasonable starting position? Duncan
From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Duncan Coutts
What are the code standards for the HP libs? I was under the impression that it was best to maintain H98 compatibility where possible, especially so for libraries in the old standard libs distribution. I did a quick search for platform standards but didn't find anything relevant.
It's yet to be discussed on this list. Perhaps this is a good opportunity to start that discussion. Do you want to draft a reasonable starting position?
Maybe, maybe not... I might make better progress with some more questions. What are the long-term goals of the HP? Do you want to be able to bundle compilers other than ghc? At present the HP is ghc+extralibs, so we could say that anything that ghc will compile is acceptable. This does seem to preclude the possibility of bundling alternative compilers in the future, though. So what is a reasonable common subset? Malcolm suggested: H98 + HierarchicalModules + FFI + CPP + ExistentialTypes Do we care about compilers that are stable but not (actively) maintained? Without wanting to offend anyone here, Hugs, hbc, and nhc seem to be pretty much "feature stable". Would we rather look to the future; to compilers that support a wider range of extensions? (Rank-2 or rank-n types spring to mind, esp. in the context of the time library. That would eliminate nhc, but I think Hugs is still in the running.) MPTCs? MPTCs + fundeps? What external tools can library authors assume are available? hsc2hs? c2hs? cpphs? I see that alex and happy are specified in the haskell-platform.cabal as being present. And then there's other possible code standards... - Layout and indentation: do we run everything through a pretty printer to standardise layout? - Test coverage: should we require a minimum coverage threshold from HPC? - lint-style checks: ghc -Wall? Catch? - any more? ... Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************
On Thu, 4 Jun 2009, Bayley, Alistair wrote:
From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Duncan Coutts
What are the code standards for the HP libs? I was under the impression that it was best to maintain H98 compatibility where possible, especially so for libraries in the old standard libs distribution. I did a quick search for platform standards but didn't find anything relevant.
It's yet to be discussed on this list. Perhaps this is a good opportunity to start that discussion. Do you want to draft a reasonable starting position?
In the HTTP-4000 library there are uses of TypeSynonymInstances which are not necessary. They can be avoided by known idioms: http://haskell.org/haskellwiki/List_instance
Given the angst that seems to be going on in the time dependency discussion, I thought I would take a look in the other packages in the Haskell Platform and see what extensions are present in the current platform. I figured other people might find this list useful for the sake of this discussion. I found the following dependencies: CPP: GLUT, haskell-src, HUnit, network, OpenGL, parallel, QuickCheck, time, regex-posix, stm, zlib, array#, bytestring#, Cabal#, containers#, directory#, filepath#, hpc#, old-time#, packedstring#, process#, random#, syb#, unix# ForeignFunctionInterface: editline, GLUT, OpenGL, regex-posix*, time, zlib, array#***, bytestring#, directory#, old-time#, unix#, Win32# MultiParamTypeClasses: cgi, mtl, fgl, regex-base, regex-compat, regex-posix, array#** FunctionalDependencies: mtl, regex-base, regex-compat, regex-posix FlexibleInstances: fgl, mtl, regex-base*, regex-posix*, array#** ScopedTypeVariables: fgl, bytestring***, syb# TypeSynonymInstances: mtl, regex-base*, regex-posix*, array#**, template-haskell# ExistentialQuantification: parsec OverlappingInstances: fgl GeneralizedNewtypeDeriving: regex-posix* FlexibleContexts: regex-base*, regex-posix*, array#** MagicHash: array***, bytestring***, containers***, template-haskell# DeriveDataTypeable: bytestring***, containers***, template-haskell# Rank2Types: array***, containers***, syb# UnboxedTuples: array***, bytestring*** UnliftedFFITypes: array***, bytestring*** PatternSignatures: syb#**** PatternGuards: template-haskell# PolymorphicComponents: template-haskell# EmptyDataDecls: unix# ???: ghc-prim#, integer# * w/ split base ** except on nhc-98 *** only for ghc **** only for old versions of ghc < 6.10 # ghc 6.10.3 core library, not included directly, but implied On Thu, Jun 4, 2009 at 11:13 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Thu, 4 Jun 2009, Bayley, Alistair wrote:
From: libraries-bounces@haskell.org
[mailto:libraries-bounces@haskell.org] On Behalf Of Duncan Coutts
What are the code standards for the HP libs? I was under
the impression
that it was best to maintain H98 compatibility where possible, especially so for libraries in the old standard libs
distribution. I did
a quick search for platform standards but didn't find
anything relevant.
It's yet to be discussed on this list. Perhaps this is a good opportunity to start that discussion. Do you want to draft a reasonable starting position?
In the HTTP-4000 library there are uses of TypeSynonymInstances which are not necessary. They can be avoided by known idioms: http://haskell.org/haskellwiki/List_instance _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Er.. I missed annotating some of the array and bytestring entries with an
appropriate #.
On Thu, Jun 4, 2009 at 1:38 PM, Edward Kmett
Given the angst that seems to be going on in the time dependency discussion, I thought I would take a look in the other packages in the Haskell Platform and see what extensions are present in the current platform. I figured other people might find this list useful for the sake of this discussion. I found the following dependencies:
CPP: GLUT, haskell-src, HUnit, network, OpenGL, parallel, QuickCheck, time, regex-posix, stm, zlib, array#, bytestring#, Cabal#, containers#, directory#, filepath#, hpc#, old-time#, packedstring#, process#, random#, syb#, unix#
ForeignFunctionInterface: editline, GLUT, OpenGL, regex-posix*, time, zlib, array#***, bytestring#, directory#, old-time#, unix#, Win32#
MultiParamTypeClasses: cgi, mtl, fgl, regex-base, regex-compat, regex-posix, array#**
FunctionalDependencies: mtl, regex-base, regex-compat, regex-posix
FlexibleInstances: fgl, mtl, regex-base*, regex-posix*, array#**
ScopedTypeVariables: fgl, bytestring***, syb#
TypeSynonymInstances: mtl, regex-base*, regex-posix*, array#**, template-haskell#
ExistentialQuantification: parsec
OverlappingInstances: fgl
GeneralizedNewtypeDeriving: regex-posix*
FlexibleContexts: regex-base*, regex-posix*, array#**
MagicHash: array***, bytestring***, containers***, template-haskell#
DeriveDataTypeable: bytestring***, containers***, template-haskell#
Rank2Types: array***, containers***, syb#
UnboxedTuples: array***, bytestring***
UnliftedFFITypes: array***, bytestring***
PatternSignatures: syb#****
PatternGuards: template-haskell#
PolymorphicComponents: template-haskell#
EmptyDataDecls: unix#
???: ghc-prim#, integer#
* w/ split base ** except on nhc-98 *** only for ghc **** only for old versions of ghc < 6.10 # ghc 6.10.3 core library, not included directly, but implied
On Thu, Jun 4, 2009 at 11:13 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Thu, 4 Jun 2009, Bayley, Alistair wrote:
From: libraries-bounces@haskell.org
[mailto:libraries-bounces@haskell.org] On Behalf Of Duncan Coutts
What are the code standards for the HP libs? I was under
the impression
that it was best to maintain H98 compatibility where possible, especially so for libraries in the old standard libs
distribution. I did
a quick search for platform standards but didn't find
anything relevant.
It's yet to be discussed on this list. Perhaps this is a good opportunity to start that discussion. Do you want to draft a reasonable starting position?
In the HTTP-4000 library there are uses of TypeSynonymInstances which are not necessary. They can be avoided by known idioms: http://haskell.org/haskellwiki/List_instance _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Thu, 2009-06-04 at 16:02 +0100, Bayley, Alistair wrote:
From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Duncan Coutts
What are the code standards for the HP libs? I was under the impression that it was best to maintain H98 compatibility where possible, especially so for libraries in the old standard libs distribution. I did a quick search for platform standards but didn't find anything relevant.
It's yet to be discussed on this list. Perhaps this is a good opportunity to start that discussion. Do you want to draft a reasonable starting position?
Maybe, maybe not... I might make better progress with some more questions.
What are the long-term goals of the HP? Do you want to be able to bundle compilers other than ghc?
That's an interesting question and one I do not have a firm position on myself. The HP is supposed to be practical so I don't think we want to hold things back unduly. However if we can stick to a reasonable subset of language features then it is at least possible for other compilers to have a target. It gets harder and harder however as GHC adds more. So this is yet another question where we want to look for community discussion and try and get consensus.
At present the HP is ghc+extralibs, so we could say that anything that ghc will compile is acceptable. This does seem to preclude the possibility of bundling alternative compilers in the future, though.
So what is a reasonable common subset? Malcolm suggested: H98 + HierarchicalModules + FFI + CPP + ExistentialTypes
The subset is certainly ok. There are a number of others that are more controversial, especially the ones needed for typing the ST monad and some of the generics packages.
Do we care about compilers that are stable but not (actively) maintained? Without wanting to offend anyone here, Hugs, hbc, and nhc seem to be pretty much "feature stable". Would we rather look to the future; to compilers that support a wider range of extensions? (Rank-2 or rank-n types spring to mind, esp. in the context of the time library. That would eliminate nhc, but I think Hugs is still in the running.) MPTCs? MPTCs + fundeps?
I don't know. I'd like an answer too.
What external tools can library authors assume are available? hsc2hs? c2hs? cpphs? I see that alex and happy are specified in the haskell-platform.cabal as being present.
They can assume precisely those available in the platform. If we add cpphs and c2hs, then libs can use those.
And then there's other possible code standards...
Yep, that's a fun topic though fortunately mostly orthogonal to the issue of language extensions. Coding standards tend not to impose dependencies.
- Layout and indentation: do we run everything through a pretty printer to standardise layout?
That seems extreme to me.
- Test coverage: should we require a minimum coverage threshold from HPC?
I hope we can move in this direction.
- lint-style checks: ghc -Wall? Catch?
There's at least some subset of -Wall we can probably agree on.
- any more? ...
We've got a list of suggestions here: http://trac.haskell.org/haskell-platform/wiki/AddingPackages currently: * Does it meet a stated end-user need? * Do similar systems include such a library (e.g. Python)? * Is it portable? * Does it add additional C libraries? * Does it follow the package versioning system? * Is the code of good quality? * Does it have history? * Is it on hackage? * Does it provide haddocks? * Does it have a test suite? * Does it have a maintainer? * Does it require new Haskell dependencies? (invariant: the platform must be closed wrt. deps) * Does it have a simple/configure-based Cabal build? * Does it conflict/compete with existing functionality? * Does it reuse existing types? * Does it follow the hierarchical naming conventions? * Is it -Wall clean? * Does it have demonstrated users? * Have declared correctness or performance statements? * Is it BSD licensed? * Will the maintainer continue to maintain it, as demand grows ? * Is it thread-safe? Duncan
On Jun 2, 2009, at 4:08 AM, Bayley, Alistair wrote:
Without wanting to sound like I'm telling you to suck eggs...
What are the code standards for the HP libs? I was under the impression that it was best to maintain H98 compatibility where possible, especially so for libraries in the old standard libs distribution. I did a quick search for platform standards but didn't find anything relevant.
For H98 compatibility, is it not too onerous to have generated or hand-written Data & Typeable instances in the source? I'm guessing that the library is fairly stable, so I'd expect that it would add little to the maintenance costs (but then I'm not maintaining time, so that's a fairly glib claim).
It seems to me that the sane and simple thing to do would just be to make the problematic parts of the code conditional using cpp, as is done for, e.g., Data.Map: http://www.haskell.org/ghc/docs/latest/html/libraries/containers/src/ Data-Map.html Cheers, S.
Ashley Yakeley
Will it cause anyone any problems if
* it requires GeneralizedNewtypeDeriving and DeriveDataTypeable to build?
If you care at all about Haskell 98 compatibility, now would be a really good time to speak up. Remember, silence implies consent.
OK, I object to the proposed change. The time library is pretty core, and should continue to be buildable by compilers and interpreters other than GHC. This does not necessarily mean it must be strictly H'98 compliant, but that would be a good approximation of the common language. Regards, Malcolm
Malcolm Wallace wrote:
OK, I object to the proposed change. The time library is pretty core, and should continue to be buildable by compilers and interpreters other than GHC. This does not necessarily mean it must be strictly H'98 compliant, but that would be a good approximation of the common language.
What is that "good approximation"? These are the options: 1. time to require Haskell 98 + FFI + Rank2Types, include Data instances 2. time to require Haskell 98 + FFI + CPP, content depends on compiler 3. time to require Haskell 98 + FFI, a time-extras package with orphan Data instances -- Ashley Yakeley
Ashley Yakeley wrote:
Malcolm Wallace wrote:
OK, I object to the proposed change. The time library is pretty core, and should continue to be buildable by compilers and interpreters other than GHC. This does not necessarily mean it must be strictly H'98 compliant, but that would be a good approximation of the common language.
What is that "good approximation"?
These are the options:
I forgot, time already requires CPP... 1. time to require Haskell 98 + FFI + CPP + Rank2Types, include Data instances 2. time to require Haskell 98 + FFI + CPP, content depends on compiler 3. time to require Haskell 98 + FFI + CPP, a time-extras package with orphan Data instances -- Ashley Yakeley
This does not necessarily mean it must be strictly H'98 compliant, but that would be a good approximation of the common language. What is that "good approximation"?
Haskell'98 + HierarchicalModules + FFI + CPP + ExistentialTypes is pretty well supported across all implementations as far as I know.
These are the options:
I forgot, time already requires CPP... 1. time to require Haskell 98 + FFI + CPP + Rank2Types, include Data instances
Rank-2 is not yet universal.
2. time to require Haskell 98 + FFI + CPP, content depends on compiler 3. time to require Haskell 98 + FFI + CPP, a time-extras package with orphan Data instances
Of these two options, I don't mind, but many people express an anti- preference for orphan instances. Regards, Malcolm
Malcolm Wallace wrote:
This does not necessarily mean it must be strictly H'98 compliant, but that would be a good approximation of the common language. What is that "good approximation"?
Haskell'98 + HierarchicalModules + FFI + CPP + ExistentialTypes is pretty well supported across all implementations as far as I know.
I think this is a decent approximation. The H98 + HierarchicalModules + FFI combination tends to be what most people actually mean when they say "Haskell 98", since both of those addenda were made shortly after H98 was finalized. Omitting CPP would impose a severe burden on anyone doing anything remotely interesting. "Interesting" doesn't just mean language extensions or instances for the latest typeclass, it can also include such mundane things as backporting Prelude patches. For example, my logfloat package has patches to correct Hugs Sept2006's definitions of isInfinite and isNaN for RealFloat Double and RealFloat Float. It's a very mundane patch, but Hugs seems sufficiently moribund that I don't expect a new version in the near future. I don't have any particular stance on ExistentialTypes. Another extension I think should be included in "a good approximation of the common language" is MPTCs (not including related features like fundeps and associated types). These are approved for haskell' and they're neigh ubiquitous in modern Haskell code. This does, however, surpass the limitations of most non-GHC/non-Hugs compilers. Which raises the question of whether our definition of "the common language" comes from Haskell users or compiler writers. I'm not sure how best to reconcile that, but MPTCs do seem crucial. At the risk of burdening the HP team, perhaps it would be worth separating the platform into two products. A "98plus" metapackage that only allows the commonly supported core language (H98+HM+FFI+CPP+?); and a "prime" metapackage for additional libraries that allow ubiquitous features which are supported by GHC, Hugs, and haskell'. Even if they haven't gotten there yet, most of the alternative compilers seem to already have the goal of implementing these "prime" features, so it doesn't make sense to disparage them from the platform project IMO.
2. time to require Haskell 98 + FFI + CPP, content depends on compiler 3. time to require Haskell 98 + FFI + CPP, a time-extras package with orphan Data instances
Of these two options, I don't mind, but many people express an anti-preference for orphan instances.
Yeah, orphan instances are bad. I'm with Edward Kmett here, for the time package, having compiler-dependent instances seems like the least evil. (For other packages, it depends on the classes and on how easy it would be to avoid the problem.) -- Live well, ~wren
wren ng thornton wrote:
Yeah, orphan instances are bad.
Why? I already use private orphan modules within the package, though the package does not externally expose any orphan instances.
I'm with Edward Kmett here, for the time package, having compiler-dependent instances seems like the least evil. (For other packages, it depends on the classes and on how easy it would be to avoid the problem.)
The downside is that the package has to know, and fossilize, information about compilers. Though I will go this way if orphan instances are shown to be sufficiently problematic. -- Ashley
On Wed, Jun 3, 2009 at 3:33 AM, Ashley Yakeley
wren ng thornton wrote:
Yeah, orphan instances are bad.
Why?
I already use private orphan modules within the package, though the package does not externally expose any orphan instances.
They are fine if they aren't exposed, right up until the package with their definition decides to provide the instance themselves, at which point your orphan violates encapsulation. It is of course worse if they are exposed then you can wind up with incoherent dictionaries floating around for the same type.
I'm with Edward Kmett here, for the time package, having
compiler-dependent instances seems like the least evil. (For other packages, it depends on the classes and on how easy it would be to avoid the problem.)
The downside is that the package has to know, and fossilize, information about compilers. Though I will go this way if orphan instances are shown to be sufficiently problematic.
That said, the only knowledge it is fossilizing is the existence of a single language feature, DeriveDataTypeable or Rank2Types. On further reflection, using Rank2Types is probably a better way to go than DeriveDataTypeable, if somewhat more effort, if only because Hugs can support the former, but not the latter. -Edward Kmett
-- Ashley
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Edward Kmett wrote:
They are fine if they aren't exposed, right up until the package with their definition decides to provide the instance themselves, at which point your orphan violates encapsulation.
In this case the package with the types and the package with the instances will have the same maintainer.
It is of course worse if they are exposed then you can wind up with incoherent dictionaries floating around for the same type.
Incoherent instances can only happen if someone else makes their own orphan instances. If they do that, they'll get a compiler warning, which should be sufficient.
That said, the only knowledge it is fossilizing is the existence of a single language feature, DeriveDataTypeable or Rank2Types.
The thing is, we have this excellent build system that abstracts language features from compilers, but we then go along and hack it up because people want both Data instances and Haskell 98 compatibility in the same package. It seems like the Right Thing in this case is to put the extra functionality in a separate package.
On further reflection, using Rank2Types is probably a better way to go than DeriveDataTypeable, if somewhat more effort, if only because Hugs can support the former, but not the latter.
Yes, I'm leaning towards hand-writing the instances so that Hugs might use them. -- Ashley
On 03/06/2009 08:33, Ashley Yakeley wrote:
wren ng thornton wrote:
Yeah, orphan instances are bad.
Why?
I already use private orphan modules within the package, though the package does not externally expose any orphan instances.
How can you have private orphan instances? The only "private" orphan instances are those where the type or class is also private, is that what you mean? Cheers, Simon
On Wed, 2009-06-03 at 11:26 +0100, Simon Marlow wrote:
On 03/06/2009 08:33, Ashley Yakeley wrote:
wren ng thornton wrote:
Yeah, orphan instances are bad.
Why?
I already use private orphan modules within the package, though the package does not externally expose any orphan instances.
How can you have private orphan instances? The only "private" orphan instances are those where the type or class is also private, is that what you mean?
I don't have any private orphan instances. However I have orphan modules (as defined in http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation...) that are private. -- Ashley Yakeley
On 03/06/2009 16:48, Ashley Yakeley wrote:
On Wed, 2009-06-03 at 11:26 +0100, Simon Marlow wrote:
On 03/06/2009 08:33, Ashley Yakeley wrote:
wren ng thornton wrote:
Yeah, orphan instances are bad. Why?
I already use private orphan modules within the package, though the package does not externally expose any orphan instances. How can you have private orphan instances? The only "private" orphan instances are those where the type or class is also private, is that what you mean?
I don't have any private orphan instances. However I have orphan modules
Sorry, misread "modules" as "instances"! Cheers, Simon
I would personally would argue that solution 2 (content depends on compiler)
is the least offensive solution. Just incorporate any Typeable and Data
derivings behind CPP guards, and just set a flag in the cabal file that
defaults to true, which adds the existing DeriveDataTypeable language
feature. Its self-contained and exists precisely for this purpose, and
doesn't require all of the power of Rank2Types or
GeneralizedNewtypeDeriving.
Admittedly with 2, you get different contents on different platforms, but
the only content you are missing in a minimalist "Haskell 98 + addenda +
CPP"-only environment is instances that probably can't exist on that
platform anyways, since Data.Data.Data is full of Rank-2 types.
One could argue that a hand-implemented rank 2 Data.Data.Data instance is
more portable than a DeriveDataTypeable provided Data.Data.Data instance,
but at that point I think maintainability becomes a factor, plus you can
further counter-argue that you don't actually need Rank-2 types to define a
Data.Data.Data instance, merely to define the class, and the arguments could
go back and forth for days.
Heck the existing containers library is so gauche about this as to just
guard its definitions for Data behind an #if __GLASGOW_HASKELL__ block, so
by comparison the DerivingDataTypeable approach is fairly compassionate to
third party distributions and provides a clear path for them to belly up to
the bar if they want the instances. =)
-Edward Kmett
On Tue, Jun 2, 2009 at 1:42 PM, Ashley Yakeley
Ashley Yakeley wrote:
Malcolm Wallace wrote:
OK, I object to the proposed change. The time library is pretty core, and should continue to be buildable by compilers and interpreters other than GHC. This does not necessarily mean it must be strictly H'98 compliant, but that would be a good approximation of the common language.
What is that "good approximation"?
These are the options:
I forgot, time already requires CPP...
1. time to require Haskell 98 + FFI + CPP + Rank2Types, include Data instances
2. time to require Haskell 98 + FFI + CPP, content depends on compiler
3. time to require Haskell 98 + FFI + CPP, a time-extras package with orphan Data instances
-- Ashley Yakeley _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Malcolm Wallace wrote:
OK, I object to the proposed change. The time library is pretty core, and should continue to be buildable by compilers and interpreters other than GHC. This does not necessarily mean it must be strictly H'98 compliant, but that would be a good approximation of the common language.
Can I switch it to base 4.1, or will that also cause problems? -- Ashley
I wrote:
Can I switch it to base 4.1, or will that also cause problems?
The current dependency is base >= 2, but I'm not testing it with earlier versions. Perhaps the best course is to simply leave it as-is until someone complains about it not working with some earlier base. -- Ashley Yakeley
Ashley Yakeley wrote:
Can I switch it to base 4.1, or will that also cause problems?
The current dependency is base >= 2, but I'm not testing it with earlier versions.
As far as I am aware, versioning of the base package is not currently problematic for any compiler except GHC. Regards, Malcolm
Malcolm Wallace wrote:
Can I switch it to base 4.1, or will that also cause problems?
The current dependency is base >= 2, but I'm not testing it with earlier versions.
As far as I am aware, versioning of the base package is not currently problematic for any compiler except GHC.
OK, in line with Duncan's Notice, I'll go for build-depends: base == 4.* -- Ashley
On Wed, 2009-06-03 at 17:53 +0200, Henning Thielemann wrote:
Ashley Yakeley wrote:
If you care at all about Haskell 98 compatibility, now would be a really good time to speak up. Remember, silence implies consent.
Of course, a basic library like 'time' should be Haskell-98.
So it should not have Data instances? -- Ashley
Ashley Yakeley schrieb:
On Wed, 2009-06-03 at 17:53 +0200, Henning Thielemann wrote:
Ashley Yakeley wrote:
If you care at all about Haskell 98 compatibility, now would be a really good time to speak up. Remember, silence implies consent. Of course, a basic library like 'time' should be Haskell-98.
So it should not have Data instances?
Difficult. If they are defined elsewhere, they are orphan. Remains resorting to CPP, which is also ugly.
participants (10)
-
Ashley Yakeley -
Bayley, Alistair -
Bulat Ziganshin -
Duncan Coutts -
Edward Kmett -
Henning Thielemann -
Malcolm Wallace -
Simon Marlow -
Sterling Clover -
wren ng thornton