Ah, maybe Dan could tell us if it works only with GHC 7.<br><br>Dmitry, I had your problem many times. The last time was when I saw you could define the ContT monad in terms of Cont (the opposite is done in the mtl).<br>It leads to a simpler code, but you are stucked when trying to define ContT as an instance of MonadTrans:<br>
<br>data Cont r a = ...<br>-- [instances of Monad Cont, blah blah blah]<br><br>type ContT r m a = Cont r (m a)<br><br>instance MonadTrans (ContT r) where -- <b>This doesn't compile</b>, even if it is logical<br> lift = ...<br>
<br>For short, type synonyms work for mere aliases, but not for full-fledged type-level non-inductive functions.<br>And sometimes we intuitively want to use them as such.<br><br><div class="gmail_quote">2011/12/7 Dmitry Kulagin <span dir="ltr"><<a href="mailto:dmitry.kulagin@gmail.com">dmitry.kulagin@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> Dmitry, does your code work with LiberalTypeSynonyms extention activated?<br>
</div>No, the same error:<br>
Type synonym `StateA' should have 1 argument, but has been given 0<br>
<br>
But I have GHC 6.12.3<br>
<br>
Dmitry<br>
2011/12/7 Yves Parès <<a href="mailto:limestrael@gmail.com">limestrael@gmail.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> This is impossible:<br>
> in the definition of 'StateT s m a', m must be a monad and then have the *<br>
> -> * kind.<br>
> So you cannot pass (StateA a), because it has simply the * kind.<br>
><br>
> Dmitry, does your code work with LiberalTypeSynonyms extention activated?<br>
><br>
><br>
> 2011/12/7 Øystein Kolsrud <<a href="mailto:kolsrud@gmail.com">kolsrud@gmail.com</a>><br>
>><br>
>> You should be able to write something like this:<br>
>><br>
>> type StateB a b = StateT SomeOtherState (StateA a) b<br>
>><br>
>> Best regards, Øystein Kolsrud<br>
>><br>
>><br>
>> On Wed, Dec 7, 2011 at 11:48 AM, Dmitry Kulagin <<a href="mailto:dmitry.kulagin@gmail.com">dmitry.kulagin@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi Dan,<br>
>>><br>
>>> I am still pretty new in Haskell, but this problem annoys me already.<br>
>>><br>
>>> If I define certain monad as a type synonym:<br>
>>><br>
>>> type StateA a = StateT SomeState SomeMonad a<br>
>>><br>
>>> Then I can't declare new monad based on the synonym:<br>
>>><br>
>>> type StateB a = StateT SomeOtherState StateA a<br>
>>><br>
>>> The only way I know to overcome is to declare StateA without `a':<br>
>>><br>
>>> type StateA = StateT SomeState SomeMonad<br>
>>><br>
>>> But it is not always possible with existing code base.<br>
>>><br>
>>> I am sorry, if this is offtopic, but it seemed to me that the problem<br>
>>> is realted to partially applied type synomyms you described.<br>
>>><br>
>>> Thanks!<br>
>>> Dmitry<br>
>>><br>
>>> On Tue, Dec 6, 2011 at 10:59 PM, Dan Doel <<a href="mailto:dan.doel@gmail.com">dan.doel@gmail.com</a>> wrote:<br>
>>> > Greetings,<br>
>>> ><br>
>>> > In the process of working on a Haskell-alike language recently, Ed<br>
>>> > Kmett and I realized that we had (without really thinking about it)<br>
>>> > implemented type synonyms that are a bit more liberal than GHC's. With<br>
>>> > LiberalTypeSynonyms enabled, GHC allows:<br>
>>> ><br>
>>> > type Foo a b = b -> a<br>
>>> > type Bar f = f String Int<br>
>>> ><br>
>>> > baz :: Bar Foo<br>
>>> > baz = show<br>
>>> ><br>
>>> > because Bar expands to saturate Foo. However, we had also implemented<br>
>>> > the following, which fails in GHC:<br>
>>> ><br>
>>> > type Foo a b = b -> a<br>
>>> > type Bar f = f (Foo Int) (Foo Int)<br>
>>> > type Baz f g = f Int -> g Int<br>
>>> ><br>
>>> > quux :: Bar Baz<br>
>>> > quux = id<br>
>>> ><br>
>>> > That is: type synonyms are allowed to be partially applied within<br>
>>> > other type synonyms, as long as similar transitive saturation<br>
>>> > guarantees are met during their use.<br>
>>> ><br>
>>> > I don't know how useful it is, but I was curious if anyone can see<br>
>>> > anything wrong with allowing this (it seems okay to me after a little<br>
>>> > thought), and thought I'd float the idea out to the GHC developers, in<br>
>>> > case they're interested in picking it up.<br>
>>> ><br>
>>> > -- Dan<br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > Haskell-Cafe mailing list<br>
>>> > <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>>> > <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
>>><br>
>>> _______________________________________________<br>
>>> Haskell-Cafe mailing list<br>
>>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Mvh Øystein Kolsrud<br>
>><br>
>> _______________________________________________<br>
>> Haskell-Cafe mailing list<br>
>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
>><br>
><br>
</div></div></blockquote></div><br>