You're right. It must be "data" not "newtype". I first wrote it with "data", but then I consider using "newtype" instead, as the identity monad does, and the fact that the transformer worked right with "newtype" got me confused. After some tests I finally realised that whenever you use "newtype" in your underlying monad then the transformer gives something which is not a monad.<br>
<br>The problem (I think) is as follows: If you write a transformer which turns your monads into strict ones, then it may give something which is not a monad for some particular strict monads. If you relax your trasnformer in order to always have a monad, then it won't be strict for some particular lazy monads. Is the same old problem lifted to the transformers world. Does this intuition make any sense? I'm always referring to using Haskell strict primitives, not CPS.<br>
<br>Alvaro.<br><br><div class="gmail_quote">El 5 de noviembre de 2009 06:19, Ryan Ingram <span dir="ltr"><<a href="mailto:ryani.spam@gmail.com" target="_blank">ryani.spam@gmail.com</a>></span> escribió:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2009/11/4 Álvaro García Pérez <<a href="mailto:agarcia@babel.ls.fi.upm.es" target="_blank">agarcia@babel.ls.fi.upm.es</a>>:<br>
<div><div></div><div>> Hi,<br>
><br>
> I'm trying to characterise some strict monads to work with a particular<br>
> lambda-calculus evaluator, as an alternative to CPS monad.<br>
><br>
> In the thread "Stupid question #852: Strict monad" the implementation of<br>
> some strict monads (and pseudo-monads, not meeting the identity laws) is<br>
> discussed. It's clear form that thread that using pattern-matching in the<br>
> (>>=) operation will force evaluation, then the Id monad defined with<br>
> pattern-matching is strict (and it's indeed a monad):<br>
><br>
>> newtype Id a = Id a<br>
>><br>
>> instance Monad Id where<br>
>> return = Id<br>
>> (Id a) >>= f = f a<br>
><br>
> But it's impossible to derive a monad transformer from it, because you don't<br>
> know the constructors of the monads you're transforming. I then tried to use<br>
> strict application ($!). My first attempt was<br>
><br>
>> newtype Strict a = InSt { outSt :: a }<br>
>><br>
>> instance Monad Strict where<br>
>> return = InSt<br>
>> m >>= f = (\x -> fDoes this make sense, or am I wrong intuition? x) $! (outSt m)<br>
><br>
> which is not a monad (doesn't meet the left identity law).<br>
><br>
> (return undefined) >>= (\x -> const (return 1) x)<br>
> =/= (return 1)<br>
><br>
> Then I wondered if it was enough to force the evaluation of the whole monad,<br>
> instead of the value inside the monad, yielding the second attempt:<br>
><br>
>> newtype Strict a = InSt { outSt :: a }<br>
>><br>
>> instance Monad Strict where<br>
>> return = InSt<br>
>> m >>= f = (\x -> f (outSt x)) $! m<br>
><br>
> I placed the outSt inside the anonymous function, leaving the monad on the<br>
> right of the ($!). This meets the identity laws and surprisingly (I was<br>
> expecting a lazy behaviour) implements strict semantics (it behaves like<br>
> CPS, which is strict as well). A transformer from this monad can be easily<br>
> written:<br>
<br>
</div></div>This seems like it has the same problem to me:<br>
<br>
return undefined >>= const return 1<br>
= InSt undefined >>= const return 1<br>
= (\x -> (const return 1) (outSt x)) $! (InSt undefined)<br>
= let y = InSt undefined in seq y ((\x -> (const return 1) (outSt x)) y)<br>
= undefined -- since InSt is a newtype.<br>
<br>
You would get different behavior with<br>
<br>
data InStD a = InStD a<br>
<br>
which puts another element in the domain:<br>
<br>
InSt () contains<br>
[_|_, InSt ()] only<br>
<br>
whereas InStD () contains<br>
[_|_, InStD _|_, InStD ()]<br>
<font color="#888888"><br>
-- ryan<br>
</font></blockquote></div><br>