From 9c533dcaf8e35c567e6049426bc63d09c0f5b871 Mon Sep 17 00:00:00 2001 From: Chris Allen Date: Sun, 11 Jan 2015 11:42:11 -0600 Subject: [PATCH] formatting --- dialogues.md | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/dialogues.md b/dialogues.md index 9dd6074..4354afc 100644 --- a/dialogues.md +++ b/dialogues.md @@ -1379,13 +1379,15 @@ The pattern matching above will fail if f is not bijective. ## pseq, seq, sparks - +``` 16:24 < Lindrian> sparks in haskell seem so... unintuitive -16:24 < Lindrian> It doesnt really follow the traditional sense of how you use threads, which might be why I find it odd +16:24 < Lindrian> It doesnt really follow the traditional sense of how you use threads, +which might be why I find it odd 16:25 < qu1j0t3> this might also be a very good thing :-) 16:26 < Lindrian> why? 16:28 < Lindrian> I need to remember the functionality of seq, par and pseq. -16:28 < Lindrian> seq forces evaluation of the first argument, before returning the second? par creates a "spark" that allows the first argument to be evaluated at the same time the second is being returned? +16:28 < Lindrian> seq forces evaluation of the first argument, before returning the second? +par creates a "spark" that allows the first argument to be evaluated at the same time the second is being returned? 16:28 < Lindrian> I thinkkkkk 16:30 < Lindrian> damn cant remember pseq, gotta look it up 16:31 < Lindrian> oh right, pseq evaluates the left before returning the right, guaranteed. @@ -1399,13 +1401,15 @@ The pattern matching above will fail if f is not bijective. 16:54 < zwer_z> IIRC in ghc seq will always evaluate to error "one", while haskell (the language) allows either 16:55 < Lindrian> i read seq as "try to evaluate the first argument, but compiler might think otherwise" 16:55 < ski> Lindrian : yes, `pseq a b' guarantees `a' is forced before `b'. `seq a b' doesn't -16:56 < ski> (i think in `seq a b' you're not even guaranteed that `a' is forced before `b' is returned .. as long as it will happen eventually) +16:56 < ski> (i think in `seq a b' you're not even guaranteed that `a' is forced before `b' is +returned .. as long as it will happen eventually) 16:56 < zwer> ski I think there's a lack of guarantee only if both a and b are bottom. 16:57 < zwer> > seq (error "foo") 10 16:57 < lambdabot> *Exception: foo 16:57 < zwer> whereas that should always evaluate to bottom 16:58 < benzrf> iirc -16:58 < ski> zwer : consider `seq (seq (error "foo") ()) (error "bar")' -- i think this can legally raise `error "bar"' +16:58 < ski> zwer : consider `seq (seq (error "foo") ()) (error "bar")' -- i think this can legally +raise `error "bar"' 16:58 < benzrf> the haskell spec only says 16:58 < benzrf> seq bottom anything = bottom 16:58 < ski> yes @@ -1417,9 +1421,12 @@ The pattern matching above will fail if f is not bijective. 17:03 < zwer> ski a is entire inner seq, which may not be evaluated 17:05 < ski> yes 17:05 < ski> (i think i used a different argument, though. i can't recall it atm) -17:06 < ski> Lindrian : both will evaluate to WHNF. `pseq' guarantees sequential *ordering*. `seq' just guarantees - that both will be forced +17:06 < ski> Lindrian : both will evaluate to WHNF. `pseq' guarantees sequential *ordering*. +`seq' just guarantees that both will be forced 17:07 < Lindrian> pseq guarantees the first argument is evaluated to WHNF before the second, while seq doesnt. Ok. -17:07 < ski> `seq' is specified using "denotational semantics", which only talks about the final value/denotation of an evaluation, not how you can get to it -17:08 < ski> `pseq' would need to be specified using "operational semantics", which talks in terms of rewriting steps (so there's an inherent ordering that we talk about here) +17:07 < ski> `seq' is specified using "denotational semantics", which only talks about the +final value/denotation of an evaluation, not how you can get to it +17:08 < ski> `pseq' would need to be specified using "operational semantics", which talks in terms of +rewriting steps (so there's an inherent ordering that we talk about here) 17:08 * ski nods to Lindrian +```