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
wrote:
> Try translating into System FC! It’s not just a question of what the
> type che
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:
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}
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 expres
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
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 sho
On Fri, Aug 31, 2012 at 9:37 AM, Richard Eisenberg wrote:
> 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
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 compari
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 proble
On Fri, Aug 31, 2012 at 9:06 AM, Edward Kmett 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 Agda:
data
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 whe
Hrmm. This seems to work manually for getting product categories to work.
Perhaps I can do the same thing for thrists.
{-# LANGUAGE PolyKinds, DataKinds, TypeOperators, GADTs, TypeFamilies #-}
module Product where
import Prelude hiding (id,(.))
class Category k where
id :: k a a
(.) :: k b c
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, DataKi
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
http://hackage.h
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 wrote:
> This looks related to bug #7128. In the response to that (fixed, closed)
> bug report, Simon PJ said that functional dependencies involving kind
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.
>
>
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
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
http://www.h
> On 13 August 2012 04:57, Ian Lynagh wrote:
>> We are pleased to announce the first release candidate for GHC 7.6.1:
I did a proper test build on Fedora 18 Alpha x86_64:
If you wish to try it on Fedora (I think it might work on Fedora 17 too)
you can download it from http://petersen.fedorapeopl
With the code below, I get this error message with HEAD. And that looks right
to me, no?
The current 7.6 branch gives the same message printed less prettily.
If I replace the defn of irt with
irt :: a '(i,j) -> Thrist a '(i,j)
irt ax = ax :- Nil
then it typechecks.
Simon
Knett.hs:20:10:
C
20 matches
Mail list logo
