Hi all,
I just tried, and it appears that the new DefaultSignatures extension doesn't
work with multi parameter type classes. For example, when I compile this file:
{-# LANGUAGE DefaultSignatures, MultiParamTypeClasses #-}
module Test where
class C a b where
conv :: a -> b
default con
On 1/15/12 10:02 AM, Jan-Willem Maessen wrote:
On Sat, Jan 14, 2012 at 10:48 PM, wren ng thornton
wrote:
On 12/12/11 3:37 PM, wren ng thornton wrote:
I've noticed that take and filter are good producers (and consumers) for
list fusion, but takeWhile, drop, and dropWhile are not. Is there any
r
On 13/01/2012, Simon Peyton-Jones wrote:
> Thanks to Greg for leading the records debate. I apologise that I
> don't have enough bandwidth to make more than an occasional
> contribution. Greg's new wiki page, and the discussion so far has
> clarified my thinking, and this message tries to expres
On 15/01/2012, Ian Lynagh wrote:
> On Sun, Jan 15, 2012 at 01:38:20PM +0100, Greg Weber wrote:
>> >
>> > The blocking issues are described on
>> > http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
>> >
>> > a) "Representation hiding" (look for that heading)
>
> How about
>
The following code seems to trigger a panic (under 7.03, 7.2 and 7.4):
{-# LANGUAGE Arrows, GADTs #-}
import Control.Arrow
data Value a where BoolVal :: Value Bool
class ArrowInit f where
arrif :: f b -> ()
instance ArrowInit Value where
arrif = proc BoolVal -> returnA -< () -- this pan
On Sun, Jan 15, 2012 at 01:38:20PM +0100, Greg Weber wrote:
> >
> > The blocking issues are described on
> > http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
> >
> > a) "Representation hiding" (look for that heading)
How about
http://hackage.haskell.org/trac/ghc/wiki/Reco
That is a downside the Frege author had - one of the reasons he
abandandoned this style of implementation. It is listed on the wiki.
On Sat, Jan 14, 2012 at 3:28 PM, Jan-Willem Maessen
wrote:
> On Fri, Jan 13, 2012 at 6:52 PM, Simon Peyton-Jones
> wrote:
> > [... good summary of the issues...]
>
On Sat, Jan 14, 2012 at 12:52 AM, Simon Peyton-Jones
wrote:
>
> Complexities of (Plan B)
>
> Proposal (Plan B) sounds innocent enough. But I promise you, it isn't.
> There has ben some mention of the "left-to-right" bias of Frege type
> inference engine; indeed the wohle
Yes, indeed.
Thanks again, (and thanks for building all the arrow notation infrastructure in
the first place - it's awesome!)
--Ben
On 15 Jan 2012, at 11:57, Ross Paterson wrote:
> On Sun, Jan 15, 2012 at 11:42:28AM +, Ben Moseley wrote:
>> The real application is trying to process a struc
On Sun, Jan 15, 2012 at 11:42:28AM +, Ben Moseley wrote:
> The real application is trying to process a structure containing GADTs -
> something more like this:
>
> {-# LANGUAGE GADTs,Arrows,Rank2Types #-}
> import Control.Arrow
>
> data G a where
> G1 :: Int -> G Char
> G2 :: Int ->
Thanks for the explanation Ross.
> So the limitation is in the design rather than the implementation.
> Is this a major obstacle?
I don't think so for my use case - I think I'll be able to work around it
without too much trouble.
> I appreciate that this was cut down to provide
> a concise re
On Sun, Jan 15, 2012 at 09:34:35AM +, Ben Moseley wrote:
> Consider the code below:
>
>
>
> {-# LANGUAGE Arrows,Rank2Types #-}
>
> import Control.Arrow
>
> -- cmdcomb :: Arrow a => (a (env,x) x) -> a (env,x) x
> -- cmdcomb aegg = aegg
>
> cmdcomb :: Arrow a => (forall x . a (env,x) x)
I have a quick question on the current (GHCi, version 7.4.0.20111219)
implementation of arrow notation.
Consider the code below:
{-# LANGUAGE Arrows,Rank2Types #-}
import Control.Arrow
-- cmdcomb :: Arrow a => (a (env,x) x) -> a (env,x) x
-- cmdcomb aegg = aegg
cmdcomb :: Arrow a => (fo
13 matches
Mail list logo
