35 messages
12
Open this post in threaded view
|

Open this post in threaded view
|

Open this post in threaded view
|

 Alberto G. Corona  writes: > (...) Desugarize the > "do" notation, after that, desugarize the >>= and >>  operators down to the > function call notation and suddenly everithing lost its magic because it > becomes clear that a haskell monad is a sugarization of plain  functional > tricks. Yep. But, BTW, could you tell me what was the result of the final desugarization and the BASIC sense of the IO monad for you? Jerzy Karczmarczuk _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe
Open this post in threaded view
|

 In reply to this post by Alberto G. Corona Alberto G. Corona wrote: > But it seems that the trick is so productive because it comes from some > fundamental properties of math, the reality, and maybe the human mind . Jost > now I found this article: > > Categorial Compositionality: A Category Theory Explanation for the > Systematicity of Human > Cognition Ooh, that looks very shiny. Thanks for sharing :) -- Live well, ~wren _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe
Open this post in threaded view
|

 In reply to this post by jerzy.karczmarczuk [hidden email] wrote: > Alberto G. Corona  writes: > > > (...) Desugarize the "do" notation, after that, desugarize the >>= > > and >> operators down to the function call notation and suddenly > > everithing lost its magic because it becomes clear that a haskell > > monad is a sugarization of plain functional tricks. > > Yep. > > But, BTW, could you tell me what was the result of the final > desugarization and the BASIC sense of the IO monad for you? Example:   do x <- getLine      print (x+1)      print (x+2) There are various models.  One (the state monad model) of them would desugar this to:   \world0 ->   let (x, world1) = getLine world0       world2 = print (x+1) world1       world3 = print (x+2) world2   in world3 Another one (the EDSL model, which I personally prefer) would desugar it to something as simple as this:   GetLine `BindIO` \x ->   Print (x+1) `BindIO`   const (Print (x+2)) I wonder if there are more models for IO. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/_______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe
Open this post in threaded view
|

## Re: Re: philosophy of Haskell

Open this post in threaded view
|

Open this post in threaded view
|

## Re: Re: philosophy of Haskell

Open this post in threaded view
|

## Re: Re: philosophy of Haskell

 On Saturday Aug 14, 2010, at 12:50 AM, Conal Elliott wrote: > And the IO monad is what Jerzy asked about.  I'm pointing out that the state monad does not capture concurrency, and the "EDSL model" does not capture FFI.  (Really, it depends which "EDSL model".  I haven't seen one that can capture FFI.  And maybe not concurrency either.) > So which model captures the way the IO monad works? _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe
Open this post in threaded view
|

Open this post in threaded view
|

## Re: Re: philosophy of Haskell

Open this post in threaded view
|

Open this post in threaded view
|

Open this post in threaded view
|

## Re: Re: philosophy of Haskell

 Ertugrul Soeylemez wrote: >>>  let (x, world1) = getLine world0 >>>      world2 = print (x+1) world1 > > If between 'getLine' and 'print' something was done by a > concurrent thread, then that change to the world is captured by 'print'. But in a world passing interpretation of IO, print is supposed to be a pure Haskell function. So the value world2 can only depend on the values of print and world1, but not on the actions of some concurrent thread. If print is not restricted to be a pure Haskell function, we don't need the world passing in the first place.    Tillmann _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe
Open this post in threaded view
|

## Re[2]: Re: philosophy of Haskell

 Hello Tillmann, Sunday, August 15, 2010, 7:40:54 PM, you wrote: > But in a world passing interpretation of IO, print is supposed to be a > pure Haskell function. So the value world2 can only depend on the values > of print and world1, but not on the actions of some concurrent thread. the whole World includes any concurrent thread though ;) -- Best regards,  Bulat                            mailto:[hidden email] _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe
Open this post in threaded view
|

## Re: Re: philosophy of Haskell

 Bulat Ziganshin wrote: >> But in a world passing interpretation of IO, print is supposed to be a >> pure Haskell function. So the value world2 can only depend on the values >> of print and world1, but not on the actions of some concurrent thread. > > the whole World includes any concurrent thread though ;) Oh I see. So given world1, print can simulate the behavior of the concurrent thread to take it into account when constructing world2. Since that simulation depends only on world1, print is still pure. Does that mean that world passing *does* account for concurrency after all?    Tillmann _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe
Open this post in threaded view
|

## Re: Re: philosophy of Haskell

Open this post in threaded view
|

## Re: Re: philosophy of Haskell

Open this post in threaded view
|