On Mon, Apr 29, 2013 at 8:35 PM, Duncan Coutts duncan.cou...@googlemail.com
wrote:
On Mon, 2013-04-29 at 20:19 +0200, Gábor Lehel wrote:
Thanks for the explanation. I looked at your thesis previously, but only
read through a couple of sections (including the one about concatMap). I
might
On Mon, Apr 29, 2013 at 8:40 PM, Dan Doel dan.d...@gmail.com wrote:
On Mon, Apr 29, 2013 at 10:05 AM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
On Thu, 2013-04-25 at 00:52 +0200, Gábor Lehel wrote:
On Wed, Apr 24, 2013 at 7:56 PM, Bryan O'Sullivan b...@serpentine.com
wrote:
On Thu, 2013-04-25 at 00:52 +0200, Gábor Lehel wrote:
On Wed, Apr 24, 2013 at 7:56 PM, Bryan O'Sullivan b...@serpentine.comwrote:
On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
I address it briefly in my thesis [1], Section 4.8.2. I think it's a
On Mon, Apr 29, 2013 at 4:05 PM, Duncan Coutts duncan.cou...@googlemail.com
wrote:
On Thu, 2013-04-25 at 00:52 +0200, Gábor Lehel wrote:
On Wed, Apr 24, 2013 at 7:56 PM, Bryan O'Sullivan b...@serpentine.com
wrote:
On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts
On Mon, 2013-04-29 at 20:19 +0200, Gábor Lehel wrote:
Thanks for the explanation. I looked at your thesis previously, but only
read through a couple of sections (including the one about concatMap). I
might go through the state machine parts as well now that I know the
significance/relevance.
On Mon, Apr 29, 2013 at 10:05 AM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
On Thu, 2013-04-25 at 00:52 +0200, Gábor Lehel wrote:
On Wed, Apr 24, 2013 at 7:56 PM, Bryan O'Sullivan b...@serpentine.com
wrote:
On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts
On 25/04/2013, at 3:47 AM, Duncan Coutts wrote:
It looks like fold and unfold fusion systems have dual limitations:
fold-based fusion cannot handle zip style functions, while unfold-based
fusion cannot handle unzip style functions. That is fold-based cannot
consume multiple inputs, while
Hi Ben,
On Thu, Apr 25, 2013 at 7:46 PM, Ben Lippmeier b...@ouroborus.net wrote:
The Repa plugin will also do proper SIMD vectorisation for stream programs,
producing the SIMD primops that Geoff recently added. Along the way it will
brutally convert all operations on boxed/lifted numeric
On 26/04/2013, at 2:15 PM, Johan Tibell wrote:
Hi Ben,
On Thu, Apr 25, 2013 at 7:46 PM, Ben Lippmeier b...@ouroborus.net wrote:
The Repa plugin will also do proper SIMD vectorisation for stream programs,
producing the SIMD primops that Geoff recently added. Along the way it will
On Thu, 2013-04-25 at 21:15 -0700, Johan Tibell wrote:
{-# LANGUAGE Strict #-}
God, I would love this. Obviously the plugin approach could do it, but
could not GHC itself just _not create thunks_ for things unless told to
be lazy in the presence of such a pragma?
[at which point, we need an
On Thu, Apr 25, 2013 at 10:30 PM, Andrew Cowie
and...@operationaldynamics.com wrote:
On Thu, 2013-04-25 at 21:15 -0700, Johan Tibell wrote:
{-# LANGUAGE Strict #-}
God, I would love this. Obviously the plugin approach could do it, but
could not GHC itself just _not create thunks_ for things
On Thu, Apr 25, 2013 at 9:20 PM, Ben Lippmeier b...@ouroborus.net wrote:
On 26/04/2013, at 2:15 PM, Johan Tibell wrote:
Hi Ben,
On Thu, Apr 25, 2013 at 7:46 PM, Ben Lippmeier b...@ouroborus.net wrote:
The Repa plugin will also do proper SIMD vectorisation for stream programs,
producing
On Sun, 2013-04-21 at 18:07 -0700, Edward Z. Yang wrote:
Hello all, (cc'd stream fusion paper authors)
I noticed that the current implementation of stream fusion does
not support multiple-return stream combinators, e.g.
break :: (a - Bool) - [a] - ([a], [a]). I thought a little
bit about
On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
I address it briefly in my thesis [1], Section 4.8.2. I think it's a
fundamental limitation of stream fusion.
See also concat, where the naive fusion-based implementation has quadratic
performance:
concat ::
On Wed, 2013-04-24 at 10:56 -0700, Bryan O'Sullivan wrote:
On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
I address it briefly in my thesis [1], Section 4.8.2. I think it's a
fundamental limitation of stream fusion.
See also concat, where the
On Wed, Apr 24, 2013 at 7:56 PM, Bryan O'Sullivan b...@serpentine.comwrote:
On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
I address it briefly in my thesis [1], Section 4.8.2. I think it's a
fundamental limitation of stream fusion.
See also concat,
Presumably concat also has to use skip, for the same reason as filter.
Otherwise it has to recursively process the outer stream until it gets to a
non-empty inner stream, which breaks the rule that only the final consumer
is recursive.
concat [[1,2,3],[4,5],[],[6,7]]
probably looks something
Ah, good point.
On Thu, Apr 25, 2013 at 1:06 AM, Dan Doel dan.d...@gmail.com wrote:
Presumably concat also has to use skip, for the same reason as filter.
Otherwise it has to recursively process the outer stream until it gets to a
non-empty inner stream, which breaks the rule that only the
So, if I understand correctly, you're using the online/offline
criterion to resolve non-directed cycles in pipelines? (I couldn't
tell how the Shivers paper was related.)
Cheers,
Edward
Excerpts from Ben Lippmeier's message of Sun Apr 21 19:29:29 -0700 2013:
On 22/04/2013, at 12:23 , Edward
On 22/04/2013, at 5:27 PM, Edward Z. Yang wrote:
So, if I understand correctly, you're using the online/offline
criterion to resolve non-directed cycles in pipelines? (I couldn't
tell how the Shivers paper was related.)
The online criteria guarantees that the stream operator does not need
Hello all, (cc'd stream fusion paper authors)
I noticed that the current implementation of stream fusion does
not support multiple-return stream combinators, e.g.
break :: (a - Bool) - [a] - ([a], [a]). I thought a little
bit about how might one go about implement this, but the problem
seems
On 22/04/2013, at 11:07 , Edward Z. Yang ezy...@mit.edu wrote:
Hello all, (cc'd stream fusion paper authors)
I noticed that the current implementation of stream fusion does
not support multiple-return stream combinators, e.g.
break :: (a - Bool) - [a] - ([a], [a]). I thought a little
bit
I've got a solution for this problem and it will form the basis of
Repa 4, which I'm hoping to finish a paper about for the upcoming
Haskell Symposium.
Sounds great! You should forward me a preprint when you have something
in presentable shape. I suppose before then, I should look at
On 22/04/2013, at 12:23 , Edward Z. Yang ezy...@mit.edu wrote:
I've got a solution for this problem and it will form the basis of
Repa 4, which I'm hoping to finish a paper about for the upcoming
Haskell Symposium.
Sounds great! You should forward me a preprint when you have something
in
Hello,
While re-reading RealWorldHaskell, chapter 25, I saw that -- unlike I
believed -- loop fusion wasn't activated by default under GHC for lists
(but that module Data.List.Stream from package stream-fusion could provide
it).
Is that still the case? If not, then are there some cases of list
Yves Parès wrote:
While re-reading RealWorldHaskell, chapter 25, I saw that -- unlike I
believed -- loop fusion wasn't activated by default under GHC for lists
(but that module Data.List.Stream from package stream-fusion could provide
it).
Note that stream fusion is only one way to do
2009/5/13 Don Stewart d...@galois.com:
rl:
On 12/05/2009, at 14:45, Reiner Pope wrote:
The Stream datatype seems to be much better suited to representing
loops than the list datatype is. So, instead of programming with the
lists, why don't we just use the Stream datatype directly?
I think
On Tue, 12 May 2009, Reiner Pope wrote:
So, thoughts? Do people program with Streams directly? What have I not
considered?
Yes, for signal processing I sometimes use my custom Streams data type
that misses the Skip constructor since I do not use 'filter' functions:
Hi everyone,
With stream-fusion, we can write functions which construct and
destruct lists, such as (this is the main example from the Stream
Fusion paper[1])
f :: Int - Int
f n = sum [k * m | k - [1..n], m - [1..k]]
and the rewrite rules in stream-fusion replace these operations on
lists
On 12/05/2009, at 14:45, Reiner Pope wrote:
The Stream datatype seems to be much better suited to representing
loops than the list datatype is. So, instead of programming with the
lists, why don't we just use the Stream datatype directly?
I think the main reason is that streams don't store
rl:
On 12/05/2009, at 14:45, Reiner Pope wrote:
The Stream datatype seems to be much better suited to representing
loops than the list datatype is. So, instead of programming with the
lists, why don't we just use the Stream datatype directly?
I think the main reason is that streams don't
On Tue, May 12, 2009 at 1:39 PM, Roman Leshchinskiy r...@cse.unsw.edu.au
wrote:
let xs = map f ys in (sum xs, product xs)
the elements of xs will be computed once if it is a list but twice if it is
a stream.
If you're using lists for loops rather than data, that's what you want
(what you
Roman Leshchinskiy wrote:
On 12/05/2009, at 14:45, Reiner Pope wrote:
The Stream datatype seems to be much better suited to representing
loops than the list datatype is. So, instead of programming with the
lists, why don't we just use the Stream datatype directly?
This is more or less the
Sure, but this definition leaks space, which I think is one of the
points that Reiner made.
-- ryan
On Tue, May 12, 2009 at 5:39 AM, Roman Leshchinskiy r...@cse.unsw.edu.au
wrote:
On 12/05/2009, at 14:45, Reiner Pope wrote:
The Stream datatype seems to be much better suited to representing
not
happen to happen. This makes me anxious.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Stewart
| Sent: 18 November 2007 20:09
| To: Tom Schrijvers
| Cc: haskell-cafe@haskell.org
| Subject: Re: [Haskell-cafe] Stream fusion for Hackage
On Sat, Nov 17, 2007 at 06:31:08PM -0800, Don Stewart wrote:
Just a quick announce: the stream fusion library for lists,
that Duncan Coutts, Roman Leshchinskiy and I worked on earlier this year
is now available on Hackage as a standalone package:
Just to note: I'm excited about one day using
simonpj:
| Will it eventually replace Data.List in GHC?
|
| That is the plan, yep.
But first we need to solve the concatMap problem, no?
So far as I know, fold/build has the property that if fusion doesn't happen,
no harm is done. But streams risk making the program *worse* if Good
On Sat, 17 Nov 2007, Don Stewart wrote:
Just a quick announce: the stream fusion library for lists,
that Duncan Coutts, Roman Leshchinskiy and I worked on earlier this year
is now available on Hackage as a standalone package:
Don Stewart wrote:
Just a quick announce: the stream fusion library for lists,
that Duncan Coutts, Roman Leshchinskiy and I worked on earlier this year
is now available on Hackage as a standalone package:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-fusion-0.1.1
As
Tom.Schrijvers:
On Sat, 17 Nov 2007, Don Stewart wrote:
Just a quick announce: the stream fusion library for lists,
that Duncan Coutts, Roman Leshchinskiy and I worked on earlier this year
is now available on Hackage as a standalone package:
Just a quick announce: the stream fusion library for lists,
that Duncan Coutts, Roman Leshchinskiy and I worked on earlier this year
is now available on Hackage as a standalone package:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-fusion-0.1.1
As described in the
41 matches
Mail list logo
