Sorry I am a bit late to this: it appears to work fine on all my platforms:
el5, el6, fc16, fc17 (justhub.org/catalogue).
I haven't tested it thoroughly yet.
Chris
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
hscolour also fails to build out of the box.This is the Prelude.catch issue.Regards,
Malcolm
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Ian Lynagh wrote:
We are pleased to announce the first release candidate for GHC 7.6.1:
http://www.haskell.org/ghc/dist/7.6.1-rc1/
This includes the source tarball, installers for 32bit and 64bit
Windows, and bindists for amd64/Linux, i386/Linux, amd64/OSX and
i386/OSX.
Please
I tried this with the release candidate. I can go pull a more recent
version and try again.
On Thu, Aug 30, 2012 at 11:04 PM, Richard Eisenberg e...@cis.upenn.eduwrote:
This looks related to bug #7128. In the response to that (fixed, closed)
bug report, Simon PJ said that functional
On 30/08/2012 12:29, Joachim Breitner wrote:
Hi,
I am preparing a talk about the details of how data and programs look in
memory in Haskell (well, GHC). When explaining the memory consumption of
a large String, I wanted to show the effect of short-int-replacement
that happens in
Hrmm. This seems to render product kinds rather useless, as there is no way
to refine the code to reflect the knowledge that they are inhabited by a
single constructor. =(
For instance, there doesn't even seem to be a way to make the following
code compile, either.
{-# LANGUAGE PolyKinds,
This works, though it'll be all sorts of fun to try to scale up.
{-# LANGUAGE FunctionalDependencies, GADTs, KindSignatures,
MultiParamTypeClasses, PolyKinds, RankNTypes, TypeOperators,
DefaultSignatures, DataKinds, FlexibleInstances, UndecidableInstances,
TypeFamilies #-}
module Indexed.Test
On Fri, Aug 31, 2012 at 9:06 AM, Edward Kmett ekm...@gmail.com wrote:
I know Agda has to jump through some hoops to make the refinement work on
pairs when they do eta expansion. I wonder if this could be made less
painful.
To flesh this out slightly, there are two options for defining pairs in
I ran into this same issue in my own experimentation: if a type variable x has
a kind with only one constructor K, GHC does not supply the equality x ~ K y
for some fresh type variable y. Perhaps it should. I too had to use similar
workarounds to what you have come up with.
One potential
Hi,
Am Freitag, den 31.08.2012, 13:14 +0100 schrieb Simon Marlow:
Note that the GC does evacuate the closures, as the pointers change. Why
are these not replaced by the static ones here?
Probably because GHCi has a dynamically loaded copy of the base package,
so the pointer comparisons
On Fri, Aug 31, 2012 at 9:37 AM, Richard Eisenberg e...@cis.upenn.eduwrote:
I ran into this same issue in my own experimentation: if a type variable x
has a kind with only one constructor K, GHC does not supply the equality x
~ K y for some fresh type variable y. Perhaps it should. I too had
Hrmm. This seems to render product kinds rather useless, as there is no way to
refine the code to reflect the knowledge that they are inhabited by a single
constructor. =(
Wait. When you say “This seems to render produce kinds useless”, are you saying
that in the code I wrote, you think irt
Same question. Do you expect the code below to type-check? I have stripped it
down to essentials. Currently it’s rejected with
Couldn't match type `a' with '(,) k k1 b0 d0
And that seems reasonable, doesn’t it? After all, in the defn of bidStar, (:*)
returns a value of type
Star x
It is both perfectly reasonable and unfortunately useless. :(
The problem is that the more polymorphic type isn't any more polymorphic,
since (ideally) the product kind (a,b) is only inhabited by things of the
form '(x,y).
The product kind has a single constructor. But there is no way to express
Also, even after upgrading to HEAD, I'm getting a number of errors like:
[2 of 8] Compiling Indexed.Functor ( src/Indexed/Functor.hs,
dist/build/Indexed/Functor.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.7.20120830 for x86_64-apple-darwin):
tc_fd_tyvar
k{tv aZ8}
k{tv l}
Try translating into System FC! It’s not just a question of what the type
checker will pass; we also have to produce a well-typed FC program.
Remember that (putting in all the kind abstractions and applications:
Thrist :: forall i. ((i,i) - *) - (i,i) - *
(:*) :: forall i j k. forall (a:
I'm going to defer to Conor on this one, as it is one of the examples from
his Kleisli Arrows of Outrageous fortune that I'm translating here. ;)
-Edward
On Fri, Aug 31, 2012 at 3:14 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:
Try translating into System FC! It’s not just a question
17 matches
Mail list logo
