Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On 03/01/2012 16:54, Tristan Ravitch wrote: This might be the expected behavior but I'll ask anyway. I have what seems to be a legitimate stack overflow (due to excessive recursion and not the evaluation of a big thunk). The stack trace from -xc only shows about 13 calls on the stack (with each function that is called only appearing once). Is it by design that functions only appear once? Yes, and this is the area where things might change. We have to somehow make the stack finite, otherwise the data structure storing the stack would fill up the memory. Here are a few options: A) On a recursive call, truncate the stack to the previous instance of the call B) On a recursive call, do not push anything on the stack C) On a recursive call, elide some previous entries in the stack (e.g. replacing them with ...) Currently we're doing a variant of A, which is good for profiling because it means that the cost of a function call is always attributed to a stack with that function at the top. However, A doesn't satisfy all the properties we need, so certain compiler transformations aren't valid. The only option that has the right properties is B, but that isn't so useful for profiling. C is more useful for stack traces, because there is more information towards the top of the stack - the last few calls are correct, but information deeper down the stack is lost. This is what Tristan Allwood used in his Finding the Needle paper. Unfortunately C doesn't have the right transformational properties either. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On 21/12/2011 22:36, Roman Cheplyaka wrote:
* Ian Lynaghig...@earth.li [2011-12-21 18:29:21+]
* The profiling and hpc implementations have been merged and overhauled.
Visible changes include renaming of profiling flags:
http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/flag-reference.html#id589412
and the cost-centre stacks have a new semantics, which should in most
cases result in more useful and intuitive profiles. The +RTS -xc flag
now also gives a stack trace.
Where can we learn more about the new semantics?
I haven't writtne down the semantics formally yet, I'm afraid, and it
may yet change. However, you should find that the changes give more
intuitive results, and profiling is now more robust to compiler
optimisations.
There are a few visible changes. One is that -auto-all will label
nested functions by default now (but you can revert to the previous
behaviour of labelling only top-level functions with -fprof-auto-top).
Another visible change is that higher-order functions are now pushed on
the stack when they are called, not when they are referenced. For
example, in map f xs you will see that map calls f, whereas previously
f would be shown as a child of the function containing the call to map
(sometimes!).
This also means that the costs of a calling a higher-order function are
always part of the aggregate costs of the caller, rather than being
attributed to the higher-order function itself. For example, if you have
f xs ys = {-# SCC map1 #-} map g xs ++ {-# SCC map2 #-} map g ys
where g = ...
then you'll see that map1 calls g and map2 calls g, and the costs of
calling g on the elements of xs are recorded separately from the costs
of calling g on the elements of ys. Previously all the costs of g would
be attributed to g itself, which is much less useful.
I'd be interested in hearing feedback, particularly if you find a case
where costs are attributed somewhere that you didn't expect, or the
stack looks wrong.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On Tue, Jan 03, 2012 at 11:00:58AM +, Simon Marlow wrote:
On 21/12/2011 22:36, Roman Cheplyaka wrote:
* Ian Lynaghig...@earth.li [2011-12-21 18:29:21+]
* The profiling and hpc implementations have been merged and overhauled.
Visible changes include renaming of profiling flags:
http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/flag-reference.html#id589412
and the cost-centre stacks have a new semantics, which should in most
cases result in more useful and intuitive profiles. The +RTS -xc flag
now also gives a stack trace.
Where can we learn more about the new semantics?
I haven't writtne down the semantics formally yet, I'm afraid, and
it may yet change. However, you should find that the changes give
more intuitive results, and profiling is now more robust to compiler
optimisations.
There are a few visible changes. One is that -auto-all will label
nested functions by default now (but you can revert to the previous
behaviour of labelling only top-level functions with
-fprof-auto-top).
The labeling of nested functions has been very convenient for me. It
has made tracking down stack overflows due to the evaluation of large
thunk chains much easier - I don't have to manually add SCCs
everywhere.
I can't even imagine how many hours this combined with stack traces
has saved me compared to the debugging/profiling tools available in
7.0.x
Another visible change is that higher-order functions are now pushed
on the stack when they are called, not when they are referenced.
For example, in map f xs you will see that map calls f, whereas
previously f would be shown as a child of the function containing
the call to map (sometimes!).
This also means that the costs of a calling a higher-order function
are always part of the aggregate costs of the caller, rather than
being attributed to the higher-order function itself. For example,
if you have
f xs ys = {-# SCC map1 #-} map g xs ++ {-# SCC map2 #-} map g ys
where g = ...
then you'll see that map1 calls g and map2 calls g, and the costs of
calling g on the elements of xs are recorded separately from the
costs of calling g on the elements of ys. Previously all the costs
of g would be attributed to g itself, which is much less useful.
I noticed this in my profiles and it has also been really helpful.
I'd be interested in hearing feedback, particularly if you find a
case where costs are attributed somewhere that you didn't expect, or
the stack looks wrong.
This might be the expected behavior but I'll ask anyway. I have what
seems to be a legitimate stack overflow (due to excessive recursion
and not the evaluation of a big thunk). The stack trace from -xc only
shows about 13 calls on the stack (with each function that is called
only appearing once).
Is it by design that functions only appear once?
pgpYpi1kLDBpx.pgp
Description: PGP signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Unregistered builds broken? (Was: ANNOUNCE: GHC 7.4.1 Release Candidate 1)
Dear GHC team, I tried to fix these problems myself, and three of the bugs had more or less trivial solutions (that hopefully are right): http://hackage.haskell.org/trac/ghc/ticket/5733 http://hackage.haskell.org/trac/ghc/ticket/5735 http://hackage.haskell.org/trac/ghc/ticket/5734 However, this makes this build failure appear on those arches as well: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.4.0.20111219 for sparc-unknown-linux): pprGlobalReg: Unsupported register: CCCS http://hackage.haskell.org/trac/ghc/ticket/5732 It seems that unregistered builds are generally broken, and that this is not specific to exotic architectures. Are unregistered builds still supported? Is this likely to be fixed for 7.4.1? Please note that support for non-x86-arches is not just an academic exercise: For example, I have a NAS device with an arm CPU (a NSLU2) that happily runs git-annex¹, which is written in Haskell. I wonder if we can help you in general with keeping these arches supported, e.g. by setting up build bots for GHC. Would that be possible? What would need to be done for that? Would a virtual machine on (some of) these arches that you can manage yourself be helpful? I’m not sure what Debian can do here, but if I know the requirements, I can talk to the right people. Greetings, Joachim ¹ http://git-annex.branchable.com/ -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
Dear GHC team,
for your convenience, I have filed individual bugs about the build
errors:
Am Freitag, den 23.12.2011, 14:54 +0100 schrieb Joachim Breitner:
the build system seems to be quite confused on arch/os-combinations
besides {i386,amd64}/linux. All these worked fine with 7.2.2:
https://buildd.debian.org/status/package.php?p=ghcsuite=experimental
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.4.0.20111219 for x86_64-unknown-kfreebsdgnu):
Don't know if OSUnknown is elf
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.4.0.20111219 for i386-unknown-kfreebsdgnu):
Don't know if OSUnknown is elf
http://hackage.haskell.org/trac/ghc/ticket/5733
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.4.0.20111219 for powerpc-unknown-linux):
Cant do annotations without GHCi
{libraries/vector/Data/Vector/Fusion/Stream/Monadic.hs:104:19-33}
base:GHC.Exts.ForceSpecConstr{d rbL}
Should disappear when vector is not shipped with GHC, but a fix to
http://hackage.haskell.org/trac/ghc/ticket/4268 (ignore Annotations on
architectures without GHCi support) would be appreciated.
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.4.0.20111219 for s390-ibm-linux):
Don't know if ArchUnknown is 32bit
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.4.0.20111219 for s390x-ibm-linux):
Don't know if ArchUnknown is 32bit
http://hackage.haskell.org/trac/ghc/ticket/5735
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.4.0.20111219 for sparc-unknown-linux):
pprGlobalReg: Unsupported register: CCCS
http://hackage.haskell.org/trac/ghc/ticket/5732
And another failure has manifested itself on mips/mipsell:
http://hackage.haskell.org/trac/ghc/ticket/5734
Thanks,
Joachim
--
Joachim nomeata Breitner
Debian Developer
nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata
signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
Lauri wrote: Sorts are typically constants, and there are usually a finite amount of them, each presenting a level of the type system. Indeed. The literature on generic programming sometimes uses the term superkind to refer to the sort of BOX; see, for example, Ralf Hinze and Johan Jeuring. Generic Haskell: Applications. In Roland Carl Backhouse and Jeremy Gibbons, editors, Generic Programming: Advanced Lectures, volume 2793 of Lecture Notes in Computer Science, pages 57–96. Springer-Verlag, 2003. Cheers, Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
Am Donnerstag, den 22.12.2011, 00:02 +0100 schrieb Bas van Dijk:
On 21 December 2011 19:29, Ian Lynagh ig...@earth.li wrote:
* There is a new feature constraint kinds (-XConstraintKinds):
http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/constraint-kind.html
I'm trying to run the ConstraintKinds example from the documentation:
{-# LANGUAGE ConstraintKinds, TypeFamilies #-}
type family Typ a b :: Constraint
type instance Typ Int b = Show b
type instance Typ Bool b = Num b
But GHC complains:
Not in scope: type constructor or class `Constraint'
By the way, is there a reason behind the fact that “Constraint” uses the
ordinary case, while “BOX” has all three letters capitalized? Wouldn’t
it be more sensible if it were “Box” instead of “BOX”?
Things like capitalization might not seem very important first, but
unfortunately, decisions about them seem to persist.
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: GHC 7.4.1 Release Candidate 1
| By the way, is there a reason behind the fact that “Constraint” uses the | ordinary case, while “BOX” has all three letters capitalized? Wouldn’t | it be more sensible if it were “Box” instead of “BOX”? Only that BOX is a sort (currently the one and only sort), whereas Constraint is a kind. I'm not sure that BOX should ever be displayed to users. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
Hi Wolfgang, On Wed, Dec 28, 2011 at 13:51, Wolfgang Jeltsch g9ks1...@acme.softbase.orgwrote: Am Mittwoch, den 28.12.2011, 12:48 + schrieb Simon Peyton-Jones: | By the way, is there a reason behind the fact that “Constraint” uses the | ordinary case, while “BOX” has all three letters capitalized? Wouldn’t | it be more sensible if it were “Box” instead of “BOX”? Only that BOX is a sort (currently the one and only sort), whereas Constraint is a kind. I'm not sure that BOX should ever be displayed to users. Okay, this makes sense then. However, note that the GHC User’s manual mixes the terminology (“kind” vs. “sort”) at one point: Note that List, for instance, does not get kind BOX - BOX, because we do not further classify kinds; all kinds have sort BOX. http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/kind-polymorphism-and-promotion.html I think, it should say “sort BOX - BOX”. Yes, it should indeed say sort, not kind. If you know of any other places in the documentation with this type/kind/sort of inconsistency, please let me know :-) Cheers, Pedro Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: GHC 7.4.1 Release Candidate 1
I've pushed a patch to the docs. Thanks S From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of José Pedro Magalhães Sent: 28 December 2011 15:08 To: Wolfgang Jeltsch Cc: glasgow-haskell-users@haskell.org Subject: Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1 Hi Wolfgang, On Wed, Dec 28, 2011 at 13:51, Wolfgang Jeltsch g9ks1...@acme.softbase.orgmailto:g9ks1...@acme.softbase.org wrote: Am Mittwoch, den 28.12.2011, 12:48 + schrieb Simon Peyton-Jones: | By the way, is there a reason behind the fact that Constraint uses the | ordinary case, while BOX has all three letters capitalized? Wouldn't | it be more sensible if it were Box instead of BOX? Only that BOX is a sort (currently the one and only sort), whereas Constraint is a kind. I'm not sure that BOX should ever be displayed to users. Okay, this makes sense then. However, note that the GHC User's manual mixes the terminology (kind vs. sort) at one point: Note that List, for instance, does not get kind BOX - BOX, because we do not further classify kinds; all kinds have sort BOX. http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/kind-polymorphism-and-promotion.html I think, it should say sort BOX - BOX. Yes, it should indeed say sort, not kind. If you know of any other places in the documentation with this type/kind/sort of inconsistency, please let me know :-) Cheers, Pedro Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.orgmailto:Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: GHC 7.4.1 Release Candidate 1
Quoting Wolfgang Jeltsch g9ks1...@acme.softbase.org: Am Mittwoch, den 28.12.2011, 12:48 + schrieb Simon Peyton-Jones: Only that BOX is a sort (currently the one and only sort), whereas Constraint is a kind. I'm not sure that BOX should ever be displayed to users. Okay, this makes sense then. However, note that the GHC User’s manual mixes the terminology (“kind” vs. “sort”) at one point: Note that List, for instance, does not get kind BOX - BOX, because we do not further classify kinds; all kinds have sort BOX. I think, it should say “sort BOX - BOX”. I don't think that would be quite correct. Sorts are typically constants, and there are usually a finite amount of them, each presenting a level of the type system. For instance, * and BOX are both sorts, even though we also have * :: BOX. In a system where BOX - BOX would be well-formed, it should probably be called something else, maybe kind-classifying term (whose sort would be something new, maybe TRIANGLE). But it seems a bit funny to spend a lot of time thinking about what to call things that don't exist in GHC. Maybe it'd be easiest to just drop that awkward hypothetical BOX - BOX altogether from the manual. Lauri ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: GHC 7.4.1 Release Candidate 1
Yes, it's expected; it's also the behaviour of GHC 6.12 etc.
Here what is happening. You define
result = undefined
What type does it get? In 6.12, and 7.4, it gets type
result :: forall b. b
So the two uses of 'result' in the two branches of the case have no effect on
each other.
But in 7.2 it was *not generalised*, so we got
result :: f2 a
And now the two uses *do* affect each other.
Why the change. You'll remember that over the last year GHC has changed not to
generalise local lets:
http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7
I relaxed the rule in 7.2, as discussed in Which bindings are affected? in
that post. For reasons I have not investigated, 7.2 *still* doesn't generalise
'result'; but 7.4 correctly does.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Antoine Latter
| Sent: 23 December 2011 04:21
| To: glasgow-haskell-users@haskell.org
| Subject: Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
|
| On Wed, Dec 21, 2011 at 1:29 PM, Ian Lynagh ig...@earth.li wrote:
|
| We are pleased to announce the first release candidate for GHC 7.4.1:
|
| http://www.haskell.org/ghc/dist/7.4.1-rc1/
|
| This includes the source tarball, installers for OS X and Windows, and
| bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD.
|
| Please test as much as possible; bugs are much cheaper if we find them
| before the release!
|
|
| Hurrah!
|
| The following used to compile with GHC 7.2.1:
|
|
| {-# LANGUAGE RankNTypes, TypeFamilies, GADTs #-}
|
| import Data.Typeable ( Typeable1, gcast1, typeOf1 )
|
| cast1 :: (Typeable1 f1, Typeable1 f2) = f1 a - f2 a
| cast1 val
| = case gcast1 (Just val) of
| Just (Just typed_val) - typed_val `asTypeOf` result
| Nothing - error $ Invalid cast: ++ tag ++ - ++ show
| (typeOf1 result)
| where result = undefined
| tag = show (typeOf1 val)
|
| main = putStrLn Hello, world!
|
|
| But with GHC 7.4.1 RC 1 I get the error:
|
|
| BugDowncast.hs:9:69:
| Ambiguous type variable `t0' in the constraint:
| (Typeable1 t0) arising from a use of `typeOf1'
| Probable fix: add a type signature that fixes these type variable(s)
| In the first argument of `show', namely `(typeOf1 result)'
| In the second argument of `(++)', namely `show (typeOf1 result)'
| In the second argument of `(++)', namely
| ` - ++ show (typeOf1 result)'
|
|
| Is this an expected change, or should I create a ticket?
|
| Thanks,
| Antoine
|
|
| The release notes are not yet available, but here are some of the
| highlights of the 7.4 branch since 7.2 and 7.0:
|
| * There is a new feature Safe Haskell (-XSafe, -XTrustworthy, -XUnsafe):
| http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/safe-
| haskell.html
| The design has changed since 7.2.
|
| * There is a new feature kind polymorphism (-XPolyKinds):
| http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/kind-
| polymorphism-and-promotion.html
| A side-effect of this is that, when the extension is not enabled, in
| certain circumstances kinds are now defaulted to * rather than being
| inferred.
|
| * There is a new feature constraint kinds (-XConstraintKinds):
|
| http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/constraint-
| kind.html
|
| * It is now possible to give any sort of declaration at the ghci prompt:
|
| http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/interactive-
| evaluation.html#ghci-decls
| For example, you can now declare datatypes within ghci.
|
| * The profiling and hpc implementations have been merged and overhauled.
| Visible changes include renaming of profiling flags:
| http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/flag-
| reference.html#id589412
| and the cost-centre stacks have a new semantics, which should in most
| cases result in more useful and intuitive profiles. The +RTS -xc flag
| now also gives a stack trace.
|
| * It is now possible to write compiler plugins:
| http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/compiler-
| plugins.html
|
| * DPH support has been significantly improved.
|
| * There is now preliminary support for registerised compilation using
| LLVM on the ARM platform.
|
|
| Note: The release candidate accidentally includes the random, primitive,
| vector and dph libraries. The final release will not include them.
|
|
| Thanks
| Ian, on behalf of the GHC team
|
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
Hi,
Am Mittwoch, den 21.12.2011, 18:29 + schrieb Ian Lynagh:
Please test as much as possible; bugs are much cheaper if we find them
before the release!
the build system seems to be quite confused on arch/os-combinations
besides {i386,amd64}/linux. All these worked fine with 7.2.2:
https://buildd.debian.org/status/package.php?p=ghcsuite=experimental
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.4.0.20111219 for x86_64-unknown-kfreebsdgnu):
Don't know if OSUnknown is elf
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.4.0.20111219 for i386-unknown-kfreebsdgnu):
Don't know if OSUnknown is elf
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.4.0.20111219 for powerpc-unknown-linux):
Cant do annotations without GHCi
{libraries/vector/Data/Vector/Fusion/Stream/Monadic.hs:104:19-33}
base:GHC.Exts.ForceSpecConstr{d rbL}
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.4.0.20111219 for s390-ibm-linux):
Don't know if ArchUnknown is 32bit
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.4.0.20111219 for s390x-ibm-linux):
Don't know if ArchUnknown is 32bit
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.4.0.20111219 for sparc-unknown-linux):
pprGlobalReg: Unsupported register: CCCS
Do you think you can fix these for the next release release candidate?
About the powerpc problem: GHCi has been broken on powerpc for quite
some time, so we disabled it:
http://patch-tracker.debian.org/patch/series/view/ghc/7.4.0.20111219-1/no_ghci_on_powerpc
Maybe you also want to do that in your config.mk.in.
I guess the build failure above will go away with the next release
candidate, as vector was included by accident?
Greetings and thanks,
Joachim
--
Joachim nomeata Breitner
Debian Developer
nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata
signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On Fri, Dec 23, 2011 at 3:04 AM, Simon Peyton-Jones simo...@microsoft.com wrote: Yes, it's expected; it's also the behaviour of GHC 6.12 etc. Here what is happening. You define result = undefined What type does it get? In 6.12, and 7.4, it gets type result :: forall b. b So the two uses of 'result' in the two branches of the case have no effect on each other. But in 7.2 it was *not generalised*, so we got result :: f2 a And now the two uses *do* affect each other. Thanks for the explanation. So the 'where' binding in the following does not get generalized because it could not have been written at the top level, correct? cast :: (Typeable a, Typeable b) = a - Maybe b cast x = r where r = if typeOf x == typeOf (fromJust r) then Just $ unsafeCoerce x else Nothing Why the change. You'll remember that over the last year GHC has changed not to generalise local lets: http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 I relaxed the rule in 7.2, as discussed in Which bindings are affected? in that post. For reasons I have not investigated, 7.2 *still* doesn't generalise 'result'; but 7.4 correctly does. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: GHC 7.4.1 Release Candidate 1
| So the 'where' binding in the following does not get generalized | because it could not have been written at the top level, correct? The other way round. 'where' bindings that could have been written at top level *are* generalised; ones that could not are *not* generalised. See Which bindings are affected? in http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7, which tries to be precise. If it's hard to understand can I make it easier? Simon | | | cast :: (Typeable a, Typeable b) = a - Maybe b | cast x = r |where | r = if typeOf x == typeOf (fromJust r) |then Just $ unsafeCoerce x |else Nothing | | | Why the change. You'll remember that over the last year GHC has changed not | to generalise local lets: | http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 | | I relaxed the rule in 7.2, as discussed in Which bindings are affected? | in that post. For reasons I have not investigated, 7.2 *still* doesn't | generalise 'result'; but 7.4 correctly does. | | Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On Fri, Dec 23, 2011 at 12:33 PM, Simon Peyton-Jones simo...@microsoft.com wrote: | So the 'where' binding in the following does not get generalized | because it could not have been written at the top level, correct? The other way round. 'where' bindings that could have been written at top level *are* generalised; ones that could not are *not* generalised. See Which bindings are affected? in http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7, which tries to be precise. If it's hard to understand can I make it easier? For me it seems that both of you, gentlemen, are saying the same thing =). Cheers, -- Felipe. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
One more code sample which compiled with GHC 7.2.1 and does not with the new RC:
{-# LANGUAGE FlexibleContexts, FlexibleInstances,
FunctionalDependencies, MultiParamTypeClasses, RankNTypes,
UndecidableInstances, TypeFamilies #-}
newtype MyMonadT m a = MyMonadT (m a)
class MyClass b m | m - b where
data StM m :: * - *
myFunc :: b a - m a
instance MyClass b m = MyClass b (MyMonadT m) where
newtype StM (MyMonadT m) b = StMMine [b]
myFunc = undefined
In the instance, in GHC 7.2 the 'b' on the LHS of the newtype
introduces a fresh type binding. In the RC I get a kind error, because
the compiler seems to be trying to make all of the 'b' labeled types
the same type.
Since the 'b' isn't an indexing parameter, it doesn't make since for
it to not introduce a new binding.
This seems like an odd UI corner case, so I'm not sure what the
correct answer is. But it is a regression, so I thought I would ask
and make sure it was on purpose.
Antoine
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
Hi On 21 Dec 2011, at 22:41, Johan Tibell wrote: Built a bunch of packages using the 64-bit compiler on OS X Lion. Works fine. I'm a bit of a numpty when it comes to this sort of thing. I tried to install this version ghc-7.4.0.20111219-i386-apple-darwin.tar.bz2 under Leopard, and got this far bash-3.2$ sudo ./configure Password: checking for path to top of build tree... dyld: unknown required load command 0x8022 configure: error: cannot determine current directory I don't really know what this means. I'm kind of expecting that I have *no chance* of getting this to work on Leopard and should pop out for some other big cat. Is it worth trying harder just now, or should I lose the spots? Cheers Conor ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On Thu, Dec 22, 2011 at 05:44, Conor McBride co...@strictlypositive.orgwrote: under Leopard, and got this far bash-3.2$ sudo ./configure Password: checking for path to top of build tree... dyld: unknown required load command 0x8022 configure: error: cannot determine current directory I'd expect that on Leopard. Unless someone does a Leopard-specific build, I suspect you're out of luck. I don't really know what this means. I'm kind of expecting that I have Apple adds new stuff to its dynamic loader in every OS release, and the result usually isn't compatible with earlier releases by default, in my experience (that'd be from Tiger through Lion at this point). You need to specify an ABI compatibility level to build stuff that will run on older releases, including just being understood by dyld. Part of the problem here is that a default Xcode 4.x install only includes the 10.6 and 10.7 SDKs. I'm not seeing any way to customize the install, so it looks like Xcode 4 cannot be used to build for Leopard; someone will have to do the Leopard-compatible build on Leopard or on Snow Leopard with Xcode 3.6. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On Thu, Dec 22, 2011 at 16:19, Brandon Allbery wrote: On Thu, Dec 22, 2011 at 05:44, Conor McBride wrote: under Leopard, and got this far bash-3.2$ sudo ./configure Password: checking for path to top of build tree... dyld: unknown required load command 0x8022 configure: error: cannot determine current directory Same thing here. I think it can be misleading to call the release i386-apple-darwin. Perhaps a more specific name is in order? I'd expect that on Leopard. Unless someone does a Leopard-specific build, I suspect you're out of luck. I don't really know what this means. I'm kind of expecting that I have Apple adds new stuff to its dynamic loader in every OS release, and the result usually isn't compatible with earlier releases by default, in my experience (that'd be from Tiger through Lion at this point). You need to specify an ABI compatibility level to build stuff that will run on older releases, including just being understood by dyld. Part of the problem here is that a default Xcode 4.x install only includes the 10.6 and 10.7 SDKs. I'm not seeing any way to customize the install, so it looks like Xcode 4 cannot be used to build for Leopard; someone will have to do the Leopard-compatible build on Leopard or on Snow Leopard with Xcode 3.6. I've built it from source (ghc-7.4.0.20111219-src.tar.bz2) on Leopard. I'd be happy to contribute my build if somebody tells me what to do. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On 22 Dec 2011, at 16:08, Sean Leather wrote: I've built it from source (ghc-7.4.0.20111219-src.tar.bz2) on Leopard. I'd be happy to contribute my build if somebody tells me what to do. I hope somebody who knows does just that. Meanwhile, that sounds good to try for myself. My flat's a bit on the chilly side... Cheers Conor ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On 22 Dec 2011, at 16:08, Sean Leather wrote: I've built it from source (ghc-7.4.0.20111219-src.tar.bz2) on Leopard. I'd be happy to contribute my build if somebody tells me what to do. I had a crack at this and got quite warm, literally and metaphorically. But, no, I didn't quite get there. And yes, it's some sort of libraries issue. Here's the barf... make -r --no-print-directory -f ghc.mk phase=final all inplace/bin/ghc-stage1 -fPIC -dynamic -H32m -O-package-name integer-gmp-0.4.0.0 -hide-all-packages -i -ilibraries/integer-gmp/. - ilibraries/integer-gmp/dist-install/build -ilibraries/integer-gmp/dist- install/build/autogen -Ilibraries/integer-gmp/dist-install/build - Ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer- gmp/.-optP-include -optPlibraries/integer-gmp/dist-install/build/ autogen/cabal_macros.h -package ghc-prim-0.2.0.0 -package-name integer-gmp -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples - XNoImplicitPrelude -XForeignFunctionInterface -XUnliftedFFITypes -O2 - no-user-package-conf -rtsopts -odir libraries/integer-gmp/dist- install/build -hidir libraries/integer-gmp/dist-install/build -stubdir libraries/integer-gmp/dist-install/build -hisuf dyn_hi -osuf dyn_o - hcsuf dyn_hc libraries/integer-gmp/dist-install/build/GHC/ Integer.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/ Internals.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/ GMP/Prim.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/ Logarithms.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/ Logarithms/Internals.dyn_o libraries/integer-gmp/dist-install/build/ GHC/Integer/Type.dyn_o libraries/integer-gmp/dist-install/build/cbits/ gmp-wrappers.dyn_o libraries/integer-gmp/dist-install/build/cbits/ cbits.dyn_o libraries/integer-gmp/gmp/objs/*.o -shared -dynamic - dynload deploy -dylib-install-name /usr/local/lib/ghc-7.4.0.20111219/ `basename libraries/integer-gmp/dist-install/build/libHSinteger- gmp-0.4.0.0-ghc7.4.0.20111219.dylib | sed 's/^libHS//;s/[-]ghc.*//'`/ `basename libraries/integer-gmp/dist-install/build/libHSinteger- gmp-0.4.0.0-ghc7.4.0.20111219.dylib` -no-auto-link-packages -o libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.4.0.0- ghc7.4.0.20111219.dylib ld: duplicate symbol ___gmpz_abs in libraries/integer-gmp/gmp/objs/ add.o and libraries/integer-gmp/gmp/objs/abs.o collect2: ld returned 1 exit status make[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger- gmp-0.4.0.0-ghc7.4.0.20111219.dylib] Error 1 make: *** [all] Error 2 ...which makes me wonder just what I need to delete. This sort of issue is beyond my ken, but I'm willing to learn. I also have no especial attachment to Leopard. Clues appreciated Conor ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On Thu, Dec 22, 2011 at 22:25, Conor McBride wrote: On 22 Dec 2011, at 16:08, Sean Leather wrote: I've built it from source (ghc-7.4.0.20111219-src.tar.**bz2) on Leopard. I'd be happy to contribute my build if somebody tells me what to do. I had a crack at this and got quite warm, literally and metaphorically. But, no, I didn't quite get there. And yes, it's some sort of libraries issue. Here's the barf... make -r --no-print-directory -f ghc.mk phase=final all inplace/bin/ghc-stage1 -fPIC -dynamic -H32m -O-package-name integer-gmp-0.4.0.0 -hide-all-packages -i -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist-**install/build -ilibraries/integer-gmp/dist- **install/build/autogen -Ilibraries/integer-gmp/dist-**install/build -Ilibraries/integer-gmp/dist-**install/build/autogen -Ilibraries/integer-gmp/.-optP-include -optPlibraries/integer-gmp/** dist-install/build/autogen/**cabal_macros.h -package ghc-prim-0.2.0.0 -package-name integer-gmp -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XNoImplicitPrelude -XForeignFunctionInterface -XUnliftedFFITypes -O2 -no-user-package-conf -rtsopts -odir libraries/integer-gmp/dist-**install/build -hidir libraries/integer-gmp/dist-**install/build -stubdir libraries/integer-gmp/dist-**install/build -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc libraries/integer-gmp/dist-**install/build/GHC/Integer.dyn_* *o libraries/integer-gmp/dist-**install/build/GHC/Integer/GMP/**Internals.dyn_o libraries/integer-gmp/dist-**install/build/GHC/Integer/GMP/**Prim.dyn_o libraries/integer-gmp/dist-**install/build/GHC/Integer/**Logarithms.dyn_o libraries/integer-gmp/dist-**install/build/GHC/Integer/**Logarithms/Internals.dyn_o libraries/integer-gmp/dist-**install/build/GHC/Integer/**Type.dyn_o libraries/integer-gmp/dist-**install/build/cbits/gmp-**wrappers.dyn_o libraries/integer-gmp/dist-**install/build/cbits/cbits.dyn_**o libraries/integer-gmp/gmp/**objs/*.o -shared -dynamic -dynload deploy -dylib-install-name /usr/local/lib/ghc-7.4.0.**20111219/`basename libraries/integer-gmp/dist-**install/build/libHSinteger-** gmp-0.4.0.0-ghc7.4.0.20111219.**dylib | sed 's/^libHS//;s/[-]ghc.*//'`/`* *basename libraries/integer-gmp/dist-**install/build/libHSinteger-** gmp-0.4.0.0-ghc7.4.0.20111219.**dylib` -no-auto-link-packages -o libraries/integer-gmp/dist-**install/build/libHSinteger-** gmp-0.4.0.0-ghc7.4.0.20111219.**dylib ld: duplicate symbol ___gmpz_abs in libraries/integer-gmp/gmp/**objs/add.o and libraries/integer-gmp/gmp/**objs/abs.o collect2: ld returned 1 exit status make[1]: *** [libraries/integer-gmp/dist-**install/build/libHSinteger-** gmp-0.4.0.0-ghc7.4.0.20111219.**dylib] Error 1 make: *** [all] Error 2 ...which makes me wonder just what I need to delete. I'm not sure, but gmp is often a problem. You can try using my configure arguments. I create a script configure.mine that calls configure with my preferred prefix and gmp library. $ cat configure.mine VERSION=7.4.0.20111219 ./configure \ --prefix=/Library/Frameworks/GHC.framework/Versions/$VERSION/usr \ --with-gmp-libraries=/Library/Frameworks/GMP.framework\ --with-gmp-includes=/Library/Frameworks/GMP.framework/Headers I use the GMP.framework that is installed with the Haskell Platform. The prefix is just a convenient location that allows me to change a symlink to switch between GHC versions. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On Wed, Dec 21, 2011 at 1:29 PM, Ian Lynagh ig...@earth.li wrote:
We are pleased to announce the first release candidate for GHC 7.4.1:
http://www.haskell.org/ghc/dist/7.4.1-rc1/
This includes the source tarball, installers for OS X and Windows, and
bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD.
Please test as much as possible; bugs are much cheaper if we find them
before the release!
Hurrah!
The following used to compile with GHC 7.2.1:
{-# LANGUAGE RankNTypes, TypeFamilies, GADTs #-}
import Data.Typeable ( Typeable1, gcast1, typeOf1 )
cast1 :: (Typeable1 f1, Typeable1 f2) = f1 a - f2 a
cast1 val
= case gcast1 (Just val) of
Just (Just typed_val) - typed_val `asTypeOf` result
Nothing - error $ Invalid cast: ++ tag ++ - ++ show
(typeOf1 result)
where result = undefined
tag = show (typeOf1 val)
main = putStrLn Hello, world!
But with GHC 7.4.1 RC 1 I get the error:
BugDowncast.hs:9:69:
Ambiguous type variable `t0' in the constraint:
(Typeable1 t0) arising from a use of `typeOf1'
Probable fix: add a type signature that fixes these type variable(s)
In the first argument of `show', namely `(typeOf1 result)'
In the second argument of `(++)', namely `show (typeOf1 result)'
In the second argument of `(++)', namely
` - ++ show (typeOf1 result)'
Is this an expected change, or should I create a ticket?
Thanks,
Antoine
The release notes are not yet available, but here are some of the
highlights of the 7.4 branch since 7.2 and 7.0:
* There is a new feature Safe Haskell (-XSafe, -XTrustworthy, -XUnsafe):
http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/safe-haskell.html
The design has changed since 7.2.
* There is a new feature kind polymorphism (-XPolyKinds):
http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/kind-polymorphism-and-promotion.html
A side-effect of this is that, when the extension is not enabled, in
certain circumstances kinds are now defaulted to * rather than being
inferred.
* There is a new feature constraint kinds (-XConstraintKinds):
http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/constraint-kind.html
* It is now possible to give any sort of declaration at the ghci prompt:
http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/interactive-evaluation.html#ghci-decls
For example, you can now declare datatypes within ghci.
* The profiling and hpc implementations have been merged and overhauled.
Visible changes include renaming of profiling flags:
http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/flag-reference.html#id589412
and the cost-centre stacks have a new semantics, which should in most
cases result in more useful and intuitive profiles. The +RTS -xc flag
now also gives a stack trace.
* It is now possible to write compiler plugins:
http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/compiler-plugins.html
* DPH support has been significantly improved.
* There is now preliminary support for registerised compilation using
LLVM on the ARM platform.
Note: The release candidate accidentally includes the random, primitive,
vector and dph libraries. The final release will not include them.
Thanks
Ian, on behalf of the GHC team
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
* Ian Lynagh ig...@earth.li [2011-12-21 18:29:21+] * The profiling and hpc implementations have been merged and overhauled. Visible changes include renaming of profiling flags: http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/flag-reference.html#id589412 and the cost-centre stacks have a new semantics, which should in most cases result in more useful and intuitive profiles. The +RTS -xc flag now also gives a stack trace. Where can we learn more about the new semantics? -- Roman I. Cheplyaka :: http://ro-che.info/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
Built a bunch of packages using the 64-bit compiler on OS X Lion. Works fine. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On 21 December 2011 19:29, Ian Lynagh ig...@earth.li wrote:
* There is a new feature constraint kinds (-XConstraintKinds):
http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/constraint-kind.html
I'm trying to run the ConstraintKinds example from the documentation:
{-# LANGUAGE ConstraintKinds, TypeFamilies #-}
type family Typ a b :: Constraint
type instance Typ Int b = Show b
type instance Typ Bool b = Num b
But GHC complains:
Not in scope: type constructor or class `Constraint'
Do I have to import some GHC module for this?
Cheers,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
Hi Bas,
On Wed, Dec 21, 2011 at 23:02, Bas van Dijk v.dijk@gmail.com wrote:
On 21 December 2011 19:29, Ian Lynagh ig...@earth.li wrote:
* There is a new feature constraint kinds (-XConstraintKinds):
http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/constraint-kind.html
I'm trying to run the ConstraintKinds example from the documentation:
{-# LANGUAGE ConstraintKinds, TypeFamilies #-}
type family Typ a b :: Constraint
type instance Typ Int b = Show b
type instance Typ Bool b = Num b
But GHC complains:
Not in scope: type constructor or class `Constraint'
Do I have to import some GHC module for this?
Yes: GHC.Prim.
(Which reminds me, Simon, we had agreed to re-export Constraint from
GHC.Exts, but it wasn't clear to me how to do this, since Constraint is a
kind, not a type, so it can't just go on the export list of the module...)
Cheers,
Pedro
Cheers,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On 22 December 2011 00:10, José Pedro Magalhães j...@cs.uu.nl wrote:
Hi Bas,
On Wed, Dec 21, 2011 at 23:02, Bas van Dijk v.dijk@gmail.com wrote:
On 21 December 2011 19:29, Ian Lynagh ig...@earth.li wrote:
* There is a new feature constraint kinds (-XConstraintKinds):
http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/constraint-kind.html
I'm trying to run the ConstraintKinds example from the documentation:
{-# LANGUAGE ConstraintKinds, TypeFamilies #-}
type family Typ a b :: Constraint
type instance Typ Int b = Show b
type instance Typ Bool b = Num b
But GHC complains:
Not in scope: type constructor or class `Constraint'
Do I have to import some GHC module for this?
Yes: GHC.Prim.
(Which reminds me, Simon, we had agreed to re-export Constraint from
GHC.Exts, but it wasn't clear to me how to do this, since Constraint is a
kind, not a type, so it can't just go on the export list of the module...)
Cheers,
Pedro
Cheers,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Thanks Pedro, that works. I already read through the docs of GHC.Prim
but could not find it:
http://www.haskell.org/ghc/dist/stable/docs/html/libraries/ghc-prim-0.2.0.0/GHC-Prim.html
I guess haddock is not smart enough to understand kinds yet...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
