Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] wrote:
When I use `seq`, it is sometimes in a construction like
unsafePerformIO (emit squawk!) `seq` x
My take on this kind of thing is that if you want a specific
operational behaviour, then you're doing something
Ross Paterson wrote:
On Mon, Nov 06, 2006 at 06:25:48PM +, Malcolm Wallace wrote:
When I use `seq`, it is sometimes in a construction like
unsafePerformIO (emit squawk!) `seq` x
where I am trying to force the impure side-effect to happen, exactly and
immediately before x is evaluated.
Ross Paterson wrote:
On Mon, Nov 06, 2006 at 12:53:55PM +, Simon Marlow wrote:
Incedentally, this is also one reason I think lazy I/O is a wart (despite
its obvious usefulness): because it necessarily requires talking about
evaluation order.
What is lazy output? Buffering?
Well ok,
On Mon, Nov 06, 2006 at 05:21:04PM +, Ross Paterson wrote:
Apart from that, the only thing wrong with seq is its name.
I take back that part. Simon's strong hint suggestion looks like a
good idea. It's just one of a number of implicit assumptions we make
about operational behaviour. After
On Mon, Nov 06, 2006 at 12:53:55PM +, Simon Marlow wrote:
Incedentally, this is also one reason I think lazy I/O is a wart (despite
its obvious usefulness): because it necessarily requires talking about
evaluation order.
What is lazy output? Buffering?
Malcolm Wallace wrote:
Ross Paterson [EMAIL PROTECTED] wrote:
When I've used seq, it's to ensure that a function is strict in that
argument, and therefore has been evaluated before the function is
called. (If the language had unlifted types, I might have used those
instead). Beyond that, I
Simon Marlow [EMAIL PROTECTED] wrote:
When I use `seq`, it is sometimes in a construction like
unsafePerformIO (emit squawk!) `seq` x
My take on this kind of thing is that if you want a specific
operational behaviour, then you're doing something
implementation-specific. We
Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] wrote:
The difference is subtle. The semantics of seq and pseq are
identical; however, GHC can see that seq is strict in both its
arguments and hence could choose to evaluate them in either order,
whereas pseq is only strict in its
Simon Marlow [EMAIL PROTECTED] wrote:
The report is in general very careful to say absolutely *nothing*
about evaluation order, leaving the implementation free to choose,
Yes, this is a highly desirable goal.
However, having said all that, arguably an exception should be made in
this
On Mon, Nov 06, 2006 at 01:53:52PM +, Malcolm Wallace wrote:
So the doubly bizarre thing is that, actually, `seq` does not control
the evaluation order (which is the only valid reason for wanting to use
it in the first place), but nevertheless it undesirably changes the
semantics of
On Mon, November 6, 2006 9:21 am, Ross Paterson wrote:
On Mon, Nov 06, 2006 at 01:53:52PM +, Malcolm Wallace wrote:
So the doubly bizarre thing is that, actually, `seq` does not control
the evaluation order (which is the only valid reason for wanting to use
it in the first place), but
On Mon, Nov 06, 2006 at 06:25:48PM +, Malcolm Wallace wrote:
When I use `seq`, it is sometimes in a construction like
unsafePerformIO (emit squawk!) `seq` x
where I am trying to force the impure side-effect to happen, exactly and
immediately before x is evaluated. Whilst this is
I just noticed, thanks to some testing of the parallelism support in 6.6 by
Satnam Singh, that Control.Parallel exports seq when in fact it should probably
export pseq.
The difference is subtle. The semantics of seq and pseq are identical; however,
GHC can see that seq is strict in both its
Simon Marlow [EMAIL PROTECTED] wrote:
The difference is subtle. The semantics of seq and pseq are
identical; however, GHC can see that seq is strict in both its
arguments and hence could choose to evaluate them in either order,
whereas pseq is only strict in its first argument as far as
14 matches
Mail list logo
