On Sat, Apr 30, 2016 at 8:47 PM Takenobu Tani wrote:
> Hi Carter,
>
> You are right. I had mixed case.
> In single thread case, I implicitly assumed IO context rather than pure
> parallel context.
>
>
thank you for your wonderful questions!
> Thank you for explanation.
>
> Regards,
> Takenobu
>
Hi Carter,
You are right. I had mixed case.
In single thread case, I implicitly assumed IO context rather than pure
parallel context.
Thank you for explanation.
Regards,
Takenobu
2016-04-30 23:20 GMT+09:00 Carter Schonwald :
>
>
> On Sat, Apr 30, 2016, 10:16 AM Takenobu Tani
> wrote:
>
>> Hi
> José Manuel Calderón Trilla writes:
> Is this the reason it wasn't standardized this way to begin with? Miranda's
> `seq` is like `pseq` (as was `seq` in other lazy language implementations)
> so it's not as if there wasn't precedent.
Note that this has been discussed previously, but anoth
On Sat, Apr 30, 2016 at 6:11 AM, Lennart Augustsson
wrote:
> Order of evaluation can be very important for memory use. So I can imagine
> cases where seq would run out of memory, but pseq would not.
>
That's fair enough. Do you think it's worth attempting to standardize
the behavior of `seq` to
On Sat, Apr 30, 2016, 10:16 AM Takenobu Tani wrote:
> Hi Prime,
>
> This is additional information to organize my brain.
>
> This issue also occurs in single thread.
> Especially, when they have side effects.
>
>seq exp1 exp2
>
> Because compiler can always re-order two expressions
> in accor
Hi Prime,
This is additional information to organize my brain.
This issue also occurs in single thread.
Especially, when they have side effects.
seq exp1 exp2
Because compiler can always re-order two expressions
in accordance with seq's denotational semantics.
Regards,
Takenobu
2016-04-30
Order of evaluation can be very important for memory use. So I can imagine
cases where seq would run out of memory, but pseq would not.
I would argue that pseq is almost always what you want, but seq has a nicer
denotational semantics.
-- Lennart
On Friday, April 29, 2016, José Manuel Calderó
Hi Jose and Cale,
Thank you for clear and detailed explanation.
short summary:
* `seq` used to eliminate/manage space leaks
* `pseq` used to specify order of evaluation
* `seq` is a bad name, but well established.
* If we introduce parallelism to standard, we need `pseq` or some method.
Well, the value of par x y is identical to that of y, so any expression
which you could use to semantically distinguish pseq from seq using par
could be rewritten into one which did so without involving par.
If the way in which we're telling programs apart involves performance
characteristics then
Hello Takenobu,
Great question, this is actually a pretty interesting issue! It isn't
out of scope at all.
The first thing to think about is the following thought experiment:
Without the presence of side-effects, how can you tell the difference
between a `seq` that conforms to the Haskell report
Dear Community,
Apologies if I'm missing context.
Does Haskell 2020 specify evaluation order control by `pseq`?
We use `pseq` to guarantee the evaluation order between two expressions.
But Haskell 2010 did not specify how to control the evaluation order
between two expressions.
(only specified `
11 matches
Mail list logo
