Archives/learnhaskell
2
0
Fork 0
mirror of https://github.com/bitemyapp/learnhaskell.git synced 2024-11-17 15:25:45 +00:00
Code Issues Packages Projects Releases Wiki Activity

new dialogue

Browse Source
This commit is contained in:
Chris Allen 2015-01-11 11:39:38 -06:00
parent b0a81ffd98
commit 527c50e07e
1 changed files with 48 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
dialogues.md
View File

@ -1376,3 +1376,51 @@ inv f b = let [a] = [ a | a <- universe, f a == b ] in a
``` ```
The pattern matching above will fail if f is not bijective. 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: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> 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.
16:32 < Lindrian> So the difference between seq and pseq is that pseq guarantees it while seq doesnt?
16:51 < qu1j0t3> well, thread API has proven to be a poor fit for many purposes.
16:53 < zwer_z> > seq (error "one") (error "two")
16:53 < lambdabot> *Exception: one
16:53 < Lindrian> > pseq (error "first") (error "second")
16:53 < lambdabot> Not in scope: ‘pseq’
16:53 < lambdabot> Perhaps you meant ‘seq’ (imported from Prelude)
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 < 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 < benzrf> the haskell spec only says
16:58 < benzrf> seq bottom anything = bottom
16:58 < ski> yes
16:58 < benzrf> seq anything bottom = bottom
16:58 < zwer> ski I think so too. if b is bottom a does not have to be evaluated at all
17:00 < ski> zwer : in this case "`b'" for the inner call is not bottom
17:02 < Lindrian> so seq will try to evaluate to WHNF?
17:02 < Lindrian> pseq guarantees WHNF
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: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:08 * ski nods to Lindrian
```