Hello,
Mikhail Vorozhtsov wrote:
>> I also worry (although not based on anything particular you said)
>> whether this will not change meaning of any existing programs. Does it
>> only allow new programs?
>
> As far as I can see, no change in meaning. Some hacky operators and some
> hacky identifi
Dear Gergo,
Thank you for your prompt reply. Now the ordering makes sense. To be
honest, I still find it a little confusing even after knowing that the
order is logical, but maybe it is just a matter of getting used to it.
Also thank you for the clarification that higher-order pattern
functions
> pattern (Num a, Eq b) => P a b :: (Show a) => T a
Is “P a b” a typo for “P b”? Otherwise I cannot see how we can read
from this signature that pattern synonym P should be used with one
argument, which is a pattern of type b.
Is there a reason why the leftmost context is the provided one and th
if there are equalities in the
> "givens" of the implication, for reasons explained in the paper (we'd get
> spurious errors in the case of GADTs and the like). In this case the (TF b ~
> Y) can't really affect matters, but it's hard to be sure in general.
&g
Hello,
Can anyone please explain why the following code is rejected by GHC (7.4.1)?
The same code is also available at https://gist.github.com/3606849.
-
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE RankNTypes #
t; SPECIALISE f :: spec_ty
> where f's type is
> f :: poly_ty
> we simply ask whether poly_ty is more polymorphic than spec_ty; that is,
> whether f can appear in a context requiring a value of type spec_ty. If so,
> we see what arguments f would need to do that, and that
Hello,
Why does GHC 7.4.1 reject the rewrite rule in the following code?
> module Test where
>
> import Data.Monoid
> import Control.Monad.Writer.Strict
>
> f :: Monad m => a -> m a
> f = return
>
> g :: Monoid w => a -> Writer w a
> g = return
>
> {-# RULES
> "f->g" f = g
> #-}
On the line co
