Hi all,
how comes that it is considered safe to use
Control.Monad.Primitive.primitive and .internal
[1]?
Why aren't they called, i.e.., unsafePrimitive and unsafeInternal?
primitive allows accessing the RealWorld state and, say, passing it
to two different IO actions unwrapped through internal? Yo
Ertugrul Soeylemez wrote:
Heinrich Apfelmus wrote:
In particular, the World -> (a,World) model is unsuitable even without
concurrency because it cannot distinguish
loop, loop' :: IO ()
loop = loop
loop' = putStr "c" >> loop'
I interpret the "EDSL model" to be the operational sema
On Wednesday 18 August 2010 2:50:00 pm Gregory Crosswhite wrote:
> On 08/18/10 11:30, Dan Doel wrote:
> > Now, moving to the two loops:
> > loop = loop
> > loop' = \w0 -> let (w1, ()) = putStr "c" w0 in loop' w1
> >
> > How are we to distinguish between these? I know of exactly one Haskell
>
On 08/18/10 12:04, Gregory Crosswhite wrote:
> Now we have that loop' = loop''.
Oops! I meant that loop' = loop'' in the world passing model, so that if
loop' = \w0 -> let (w1, ()) = putStr "c" w0 in loop' w1
loop'' = \w0 -> let (w1, ()) = putStr "c" w1 in loop' w1
then loop' =
On 08/18/10 11:30, Dan Doel wrote:
> By contrast, here:
>
> http://code.haskell.org/~dolio/agda-share/html/IOE.html
>
> is a term model of IO. It's in Agda, for some proofs, but it's easily done in
> GHC. And if we write the above loops in this model, we get:
>
> loop = loop
On 08/18/10 11:30, Dan Doel wrote:
> Now, moving to the two loops:
>
> loop = loop
> loop' = \w0 -> let (w1, ()) = putStr "c" w0 in loop' w1
>
> How are we to distinguish between these? I know of exactly one Haskell
> function that can do so: seq. And this is only because it can distinguish
On Wednesday 18 August 2010 11:14:06 am Ertugrul Soeylemez wrote:
> > loop, loop' :: IO ()
> > loop = loop
> > loop' = putStr "c" >> loop'
>
> Huh?! Let's translate them. 'loop' becomes:
>
> undefined
>
> But 'loop\'' becomes:
>
> \w0 -> let (w1, ()) = putStr "c" w0
>
Heinrich Apfelmus wrote:
> In particular, the World -> (a,World) model is unsuitable even without
> concurrency because it cannot distinguish
>
> loop, loop' :: IO ()
> loop = loop
> loop' = putStr "c" >> loop'
>
> I interpret the "EDSL model" to be the operational semantics presente
Bill Atkins wrote:
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 c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/15/2010 08:32 PM, wren ng thornton wrote:
> Brandon S Allbery KF8NH wrote:
>> only ordering of calls in the *current*
>> thread of execution. (Which, hmm, implies that unsafePerformIO and
>> unsafeInterleaveIO are conceptually similar to forkIO
Brandon S Allbery KF8NH wrote:
only ordering of calls in the *current*
thread of execution. (Which, hmm, implies that unsafePerformIO and
unsafeInterleaveIO are conceptually similar to forkIO.)
Implementationally they are very similar (at least as far as the baton
is concerned). How hard we s
On Sunday, August 15, 2010, Tillmann Rendel
wrote:
> 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.
"Patai Gergely" wrote:
> > No. As you say the world1 value is immutable, but that's not
> > contradictory. If between 'getLine' and 'print' something was done
> > by a concurrent thread, then that change to the world is captured by
> > 'print'.
>
> Well, that's technically true, but it basicall
Brandon S Allbery KF8NH wrote:
> On 8/15/10 11:40 , Tillmann Rendel 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
Tillmann Rendel wrote:
> 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 wh
> No. As you say the world1 value is immutable, but that's not
> contradictory. If between 'getLine' and 'print' something was done by a
> concurrent thread, then that change to the world is captured by 'print'.
Well, that's technically true, but it basically amounts to saying that
the 'model' of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/15/10 13:27 , Tillmann Rendel wrote:
> Brandon S Allbery KF8NH wrote:
>> I am confused by this discussion. I originally thought some time back that
>> IO was about "world passing", but in fact it's just handing off a baton to
>> insure that a par
Brandon S Allbery KF8NH wrote:
I am confused by this discussion. I originally thought some time back that
IO was about "world passing", but in fact it's just handing off a baton to
insure that a particular sequence of IO functions is executed in the
specified sequence and not reordered. Nothing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/15/10 11:40 , Tillmann Rendel 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 concurre
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 ;)
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 W
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
"Patai Gergely" wrote:
> > I don't agree. A concurrent change is the effect of an IO action,
> > not of the thread. For example if a concurrent thread writes to an
> > MVar, then that change becomes the effect of the next takeMVar,
> > which gets executed. If a concurrent thread changes a file
> I don't agree. A concurrent change is the effect of an IO action, not
> of the thread. For example if a concurrent thread writes to an MVar,
> then that change becomes the effect of the next takeMVar, which gets
> executed. If a concurrent thread changes a file on disk, then that
> changing be
On Sat, Aug 14, 2010 at 10:11 PM, Bill Atkins wrote:
> 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 dep
Conal Elliott wrote:
> On Sat, Aug 14, 2010 at 9:27 AM, Ertugrul Soeylemez wrote:
>
> > Conal Elliott wrote:
> >
> > > > There are various models. One (the state monad model) of them
> > > > would desugar this to:
> > > >
> > > > \world0 ->
> > > > let (x, world1) = getLine world0
> > > >
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
> c
On Sat, Aug 14, 2010 at 9:27 AM, Ertugrul Soeylemez wrote:
> Conal Elliott wrote:
>
> > > 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
> > >
Conal Elliott wrote:
> > 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
>
> Hi Ertugrul,
>
> This state mon
>
> 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
>
Hi Ertugrul,
This state monad model does not really work for IO, sin
jerzy.karczmarc...@info.unicaen.fr 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
31 matches
Mail list logo
