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, "
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.
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
implementation-
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-specifi
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 d
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?
___
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. Aft
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 thi
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 don't care exactly w
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), b
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 pro
Malcolm Wallace wrote:
Indeed, `seq` is widely viewed as a wart on the language _because_ it
specifies the evaluation order, which is something otherwise avoided in
the Report.
I don't agree with that statement - the main problem with (polymorphic) seq is
that its existence implies that the f
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
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 fir
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
15 matches
Mail list logo
