<p dir="ltr">What I'm looking for is more limited than lazy IO or unsafeInterleaveIO, but it seems quite possible that there's no way to get just what I'm looking for with the IO type proper using GHC's implementation of IO. Lazy IO allows evaluation to drive action. When a thunk is forced, it may trigger I/O (spooky action at a distance). What I'm talking about is separating what actions are performed from what values are calculated from them. Here's a partial concept which won't actually compile because of the lazy pattern matches:</p>
<p dir="ltr">data MyIO a = forall b . MyIO (b -> a) (IO b)<br>
instance Functor MyIO where<br>
fmap f ~(MyIO t m) = MyIO (f . t) m<br>
instance Applicative MyIO where<br>
pure a = MyIO (const a) (pure ())<br>
MyIO t1 m1 <*> ~(MyIO t2 m2) =<br>
MyIO (\(r1, r2) -> t1 r1 (t2 r2)) ((,) <$> m1 <*> m2)<br>
instance Monad MyIO where<br>
???<br>
instance MonadFix MyIO where<br>
???</p>
<p dir="ltr">On Tue, Apr 19, 2016 at 2:30 AM, David Turner <<a href="mailto:dct25-561bs@mythic-beasts.com">dct25-561bs@mythic-beasts.com</a>> wrote:<br>
> I suspect you're looking for something like lazy IO (or a similarly unsafe<br>
> cousin like unsafeInterleaveIO as featured in the definition of fixIO)<br>
> although I still remain a bit confused.<br>
><br>
> The type of lazyMap :: (a -> b) -> IO a -> IO b is the same as for fmap, but<br>
> fmap is already as lazy as it can be without unsafeness:<br>
><br>
> fmap (const ()) (return undefined) = return ()<br>
> fmap (const ()) undefined = undefined<br>
><br>
> You can't (safely) define lazyMap where lazyMap f ma doesn't have all the<br>
> real-world effects of ma before returning. If ma has infinitely many effects<br>
> then it's not going to return, because if it did then you'd have your hands<br>
> on something of pure type 'b' which continues to have real-world effects as<br>
> you evaluate it. This is, roughly speaking, lazy IO.<br>
><br>
> On the other hand, you mention knot-tying and this is precisely what fixIO<br>
> is for. A slightly contrived example:<br>
><br>
> import Control.Monad<br>
> import Control.Monad.Fix<br>
><br>
> main :: IO ()<br>
> main = do<br>
> fibs <- fibsIO<br>
> print $ fibs !! 10<br>
><br>
> fibsIO :: IO [Int]<br>
> fibsIO = mfix $ \fibs -> do<br>
> fibs' <- forM [2..10] $ \i -> do<br>
> putStrLn $ "Calculating fibs !! " ++ show i<br>
> return $ fibs !! (i-1) + fibs !! (i-2)<br>
> return $ 0:1:fibs'<br>
><br>
> Note that I have to limit the number of actions for this to work - if it<br>
> said 'forM [2..] then there'd be infinitely many effects and it'd never<br>
> return.<br>
><br>
> Hope that helps,<br>
><br>
> David<br>
><br>
><br>
><br>
><br>
><br>
><br>
> On 19 April 2016 at 00:25, David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br>
>><br>
>> lazyMap :: (a -> b) -> IO a -> IO b, hypothetically.<br>
>><br>
>> Let me take a step back. There are two ways I know of to use the result of<br>
>> an IO action. The most common way, by far, is to use >>= to send it on to<br>
>> the next computation. The other notable way is to use fixIO.<br>
>><br>
>> No part of the result of an IO action becomes available until that action<br>
>> "completes" (in the shady case of lazy IO, this may be immediate, but I'm<br>
>> ignoring lazy IO for this discussion). This causes the well-known<br>
>> inefficiency of mapM in IO: individual results cannot be consed until the<br>
>> entire computation is complete. It seems to cause much more painful effects<br>
>> for fixIO--lazy programming techniques may simply be unavailable.<br>
>><br>
>> For example, it's possible for a pure computation using a queue in a<br>
>> single-threaded fashion to represent that queue as a list, tying the knot to<br>
>> pass the list of all enqueued elements to the beginning. If an IO<br>
>> computation wants to use a queue, this technique does not seem to be<br>
>> available. The knot can be tied with fixIO, but conses are delayed until<br>
>> it's too late--attempting to dequeue an element will block forever.<br>
>><br>
>> I'm wondering if there's some way to make this sort of thing work, either<br>
>> with plain Haskell IO or some thin layer built on top.<br>
>><br>
>> On Apr 18, 2016 5:12 PM, "David Turner" <<a href="mailto:dct25-561bs@mythic-beasts.com">dct25-561bs@mythic-beasts.com</a>><br>
>> wrote:<br>
>>><br>
>>> Sorry, you've lost me. I suspect you're trying to give a minimal example<br>
>>> of the problem you're having, but you've stripped away too much context.<br>
>>> What are lazyMap and f? At least, what are their types?<br>
>>><br>
>>> On 18 Apr 2016 22:03, "David Feuer" <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Consider the implementation of `second` for pairs:<br>
>>>><br>
>>>> second f ~(a,b) = (a, f b)<br>
>>>><br>
>>>> Now<br>
>>>><br>
>>>> fix $ second (3 :)<br>
>>>><br>
>>>> Will be (undefined, [3,3,....])<br>
>>>><br>
>>>> Translating this to IO, I'd want<br>
>>>><br>
>>>> lazyMap f undefined<br>
>>>><br>
>>>> to produce as much as possible of the result, although it cannot produce<br>
>>>> the final State# RealWorld token.<br>
>>>><br>
>>>> On Apr 18, 2016 4:47 PM, "David Turner" <<a href="mailto:dct25-561bs@mythic-beasts.com">dct25-561bs@mythic-beasts.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> You can't know that the final result of the computation (x `seq`<br>
>>>>> (3:...)) will begin with 3, because sometimes it doesn't! More specifically,<br>
>>>>> it diverges (without yielding the 3) if x diverges.<br>
>>>>><br>
>>>>> I don't think this is anything special about mfix: (let x = x `seq`<br>
>>>>> 3:... in x) also diverges for the same reason.<br>
>>>>><br>
>>>>> Hope that helps,<br>
>>>>><br>
>>>>> David<br>
>>>>><br>
>>>>> On 18 Apr 2016 21:19, "David Feuer" <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br>
>>>>>><br>
>>>>>> If<br>
>>>>>><br>
>>>>>> f :: a -> IO a<br>
>>>>>><br>
>>>>>> for some a, and I want to use<br>
>>>>>><br>
>>>>>> mfix f<br>
>>>>>><br>
>>>>>> then f must not inspect its argument in any way, or the computation<br>
>>>>>> will get stuck. In some cases, this seems a bit harsh. For example,<br>
>>>>>><br>
>>>>>> mfix (\x -> fmap (3 :) (x `seq` readLn))<br>
>>>>>><br>
>>>>>> looks perfectly reasonable. There is no need to inspect the return []<br>
>>>>>> action to know that the final result of the computation will begin<br>
>>>>>> with 3:. Is there a lazy IO mapping function somewhere that can work<br>
>>>>>> such magic?<br>
>>>>>> _______________________________________________<br>
>>>>>> Haskell-Cafe mailing list<br>
>>>>>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>>>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
><br>
><br>
</p>