On 23/10/12 09:50, I wrote:
Sorry, you're right. It means "I require at most rank-2 types"
Program A is marked "Rank2Types" and not "RankNTypes" and uses only
rank-1 types.
Program B is marked "Rank2Types" and not "RankNTypes" and uses only
rank-1 & rank-2 types.
Program C is marked "Rank2Type
On 23/10/12 02:36, Simon Marlow wrote:
I think it means "I require at least rank-2 types".
To clarify, I think it's OK if a compiler accepts a program marked
"Rank2Types" and incorrectly not marked "RankNTypes" when it actually
requires rank-n types.
I don't think I understand why you would wa
On 22.10.2012 11:05, Johan Tibell wrote:
I think it's OK if a compiler accepts a program incorrectly marked
"Rank2Types" when it actually requires rank-n types?
It's an interesting question: does Rank2Types mean "I require at
least
rank-2 types" or "I only use rank-2 types"?
I think it mea
On 22.10.2012 09:52, Simon Peyton-Jones wrote:
The trouble is that it's painful to check that a program uses rank-2
*only*, which is what you might naively think of the flag. So rather
than
fiddle about with distinctions that no one really cares about, the
idea
is to abolish the distinction.
I thought the point of these extension flags was to be cross-compiler?
So it seems a bit odd to make a change for the benefit of one compiler.
Here's my interpretation: Rank2Types is not a synonym for RankNTypes.
It's a specific requirement the source file has. When GHC comes to
compile it, it
patibility.
Could you clarify? What should be used instead? The "time" package
depends on old-locale.
--
Ashley Yakeley
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
on to old-time: shouldn't System.Time
> have a DEPRECATED pragma, pointing to time? The comments
> and package name say old-time is deprecated in favour of time.
Probably. I've never touched old-time.
--
Ashley Yakeley
___
Cvs-ghc
nstance. I believe this is the concern that
Henning Thielemann raised.
--
Ashley Yakeley
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
d for option a. It's better structuring, as b
would involve moving more code from Gregorian.hs to Days.hs.
The concern Henning raised shouldn't apply, as both modules are hidden
and re-exported by Data.Time.Calendar. I've also fixed two other modules
with the same issue (again
ather than
later. Though putting it in the .cabal file or wherever might be better.
It makes sense for Hackage to reject packages that use -Wall -Werror,
but for that I use a Makefile that calls cabal passing them in.
--
Ashley Yakeley
___
Cvs-ghc mailin
Simon Peyton-Jones wrote:
> Who is responsible for the time/ library?
I am.
Now that orphan warnings are "proper warnings" as Duncan requested,
What is an orphan instance, and why do we care about them?
Since they weren't proper warnings before, I always assumed they were
some weird GHC th
Mon Oct 29 11:35:14 PDT 2007 Ashley Yakeley <[EMAIL PROTECTED]>
* correct code for typecheck/should_compile/tc192.hs
M ./tests/ghc-regress/typecheck/should_compile/tc192.hs +2
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haske
12 matches
Mail list logo
