Re: Pragmatic concurrency Re: [Haskell-cafe] multiple computations, same input

2006-03-30 Thread Tomasz Zielonka
On Wed, Mar 29, 2006 at 12:50:02PM +0100, Jon Fairbairn wrote: [...] but add [a] pragma[s] to the effect that evaluation should be input driven, and that ll, ww, and cc are to be given equal time. Something like {-# STEPPER cs; ROUND_ROBIN ll,ww,cc #-} (please do not take this as a

Re: Pragmatic concurrency Re: [Haskell-cafe] multiple computations, same input

2006-03-30 Thread Tomasz Zielonka
On Thu, Mar 30, 2006 at 05:05:30PM +0200, Tomasz Zielonka wrote: Actually, it may require no effort from compiler implementors. I just managed to get the desired effect in current GHC! :-) More specifically: in uniprocessor GHC 6.4.1. I implemented your idea of stepper by writing the function

Pragmatic concurrency Re: [Haskell-cafe] multiple computations, same input

2006-03-29 Thread Jon Fairbairn
On 2006-03-28 at 08:02+0200 Tomasz Zielonka wrote: I wonder if it would be possible to remove the space-leak by running both branches concurrently, and scheduling threads in a way that would minimise the space-leak. I proposed this before

Re: Pragmatic concurrency Re: [Haskell-cafe] multiple computations, same input

2006-03-29 Thread Robin Green
On Wed, 29 Mar 2006 12:50:02 +0100 Jon Fairbairn [EMAIL PROTECTED] wrote: There are some observations I'd like to make, and a proposal. Since the proposal relates (in a small way) to concurrency and is, I think worthwhile, I've cc'd this message to haskell-prime. 1) choosing the optimal

Re: Pragmatic concurrency Re: [Haskell-cafe] multiple computations, same input

2006-03-29 Thread Brian Hulley
Robin Green wrote: On Wed, 29 Mar 2006 12:50:02 +0100 Jon Fairbairn [EMAIL PROTECTED] wrote: [snip] 1) choosing the optimal reduction strategy is undecidable 2) we shouldn't (in general) attempt to do undecidable things automatically [snip] [snip] I suggest that a Haskell program should be

Re: Pragmatic concurrency Re: [Haskell-cafe] multiple computations, same input

2006-03-29 Thread Brian Hulley
Brian Hulley wrote: Robin Green wrote: On Wed, 29 Mar 2006 12:50:02 +0100 Jon Fairbairn [EMAIL PROTECTED] wrote: [snip] 1) choosing the optimal reduction strategy is undecidable 2) we shouldn't (in general) attempt to do undecidable things automatically [snip] [snip] I suggest that a

Re: Pragmatic concurrency Re: [Haskell-cafe] multiple computations, same input

2006-03-29 Thread Philippa Cowderoy
On Wed, 29 Mar 2006, Brian Hulley wrote: This sounds good. The only thing I'm wondering is what do we actually gain by using Haskell in the first place instead of just a strict language? It seems that Haskell's lazyness gives a succinct but too inefficient program which then needs extra code

Re: Pragmatic concurrency Re: [Haskell-cafe] multiple computations, same input

2006-03-29 Thread John Meacham
On Wed, Mar 29, 2006 at 03:23:04PM +0100, Robin Green wrote: I suggest that a Haskell program should be treated as an executable specification. In some cases the compiler can't optimise the program well enough, so we (by which I mean, ordinary programmers, not compiler geeks) should be able to