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 functi
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 sugg
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
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 co
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 Has
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 b
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 opti
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
>
> http://www.haskell.org/pipermail/haskell-cafe/2
On Tue, Mar 28, 2006 at 12:27:43PM -0800, Greg Fitzgerald wrote:
> >
> > ...Anyway, I can't help but think that there might be a happy medium
> > between eager and lazy evaluation.
>
>
> What I'd love to see is the compiler continue to be call-by-need, but be
> smart enough to recognize when mult
...Anyway, I can't help but think that there might be a happy mediumbetween eager and lazy evaluation.
What I'd love to see is the compiler continue to be call-by-need, but be smart enough to recognize when multiple expressions will all eventually need to be evaluated. A simple example: show (a
On Mar 28, 2006, at 1:02 AM, Tomasz Zielonka wrote:
On Mon, Mar 27, 2006 at 03:10:18PM -0800, Greg Fitzgerald wrote:
hold a part of the data in memory while you show the first one,
Here would be a better example then.
f lst = show (sum (filter (> 1) lst), sum (filter (> 2) lst))
It oug
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
>
> http://www.haskell.org/pipermail/haskell-cafe/2005-December/013428.html
On Mon, Mar 27, 2006 at 03:10:18PM -0800, Greg Fitzgerald wrote:
> > hold a part of the data in memory while you show the first one,
>
> Here would be a better example then.
>
> f lst = show (sum (filter (> 1) lst), sum (filter (> 2) lst))
>
> It ought to be *possible* to compute both opera
On 3/28/06, Neil Mitchell <[EMAIL PROTECTED]> wrote:
> > This feels like a situation Parsec users would find themselves in all the
> > time. When you have a bunch of parsers in a 'choice', does the start of the
> > input stream linger until the last parser is executed?
>
> No, as soon as one token
> Thanks Neil. How do I add in another ~10 computations, or map a list of a
> 100 computations to the same input?
>
> Isn't there a way to do this without one computation having to be aware of
> the other?
I guess they have to be aware at some level, perhaps arrows generalise
the awareness they n
Thanks Neil. How do I add in another ~10 computations, or map a list of a 100 computations to the same input?Isn't there a way to do this without one computation having to be aware of the other? This feels like a situation Parsec users would find themselves in all the time. When you have a bunch
Neil Mitchell wrote:
> I suspected that you actually wanted to do something "cleverer" with
> the list, for the sake of argument, I'm going to change >1 to p1 and
> >2 to p2 - to show how this can be done in the general case. With the
> specific information you know about >1 vs >2 you can do better
Hi,
> Here would be a better example then.
>
> f lst = show (sum (filter (> 1) lst), sum (filter (> 2) lst))
I suspected that you actually wanted to do something "cleverer" with
the list, for the sake of argument, I'm going to change >1 to p1 and
>2 to p2 - to show how this can be done in the
> hold a part of the data in memory while you show the first one,Here would be a better example then. f lst = show (sum (filter (> 1) lst), sum (filter (> 2) lst))It ought to be *possible* to compute both operations without holding onto any of the list elements.
In the imperative world, you'
Hi Greg,
> But if I do something like this:
> f lst = show (filter (> 1) lst, filter (> 2) lst)
> then it looks like GHC won't garbage collect list elements
> until the first
> filter has completely finished
There is a very good reason for this, show (a,b) is essentially
show (a,b) = "(" +
How do I perform multiple computations on a long lazy list without introducing a space leak?Doing a single computation like this works great:
f = show . filter (> 1)But if I do something like this: f lst = show (filter (> 1) lst, filter (> 2) lst)then it looks like GHC won't garbage coll
21 matches
Mail list logo
