On Wed, Feb 20, 2008 at 5:53 PM, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
> In general, I don't see why programming directly with streams is
> something that should be avoided. You do have to be quite careful,
> though, if you want to get good performance (but GHC's simplifier is
> becomin
Chad Scherrer wrote:
Here's an example of the problem. Start with a function
extract :: [Int] -> [a] -> [a]
extract = f 0
where
f !k nss@(n:ns) (x:xs)
| n == k= x : f (k+1) ns xs
| otherwise = f (k+1) nss xs
f _ _ _ = []
If you want this to play nicely with stream
On Feb 17, 2008 6:06 PM, Derek Elkins <[EMAIL PROTECTED]> wrote:
> It's -quite- possible that a coalgebraic perspective is much more
> natural for your code/problem. If that's the case, use it (the
> coalgebraic perspective that is). Obviously depending on the internals
> of the stream library is
On Sun, 2008-02-17 at 18:02 -0800, Chad Scherrer wrote:
> On Feb 17, 2008 5:01 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> > yeah, with lists, as compared to bytestrings, there are:
> >
> > * more complex operations to fuse
> > * allocation is much cheaper (lazy list cons nodes)
> > *
On Feb 17, 2008 5:01 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> yeah, with lists, as compared to bytestrings, there are:
>
> * more complex operations to fuse
> * allocation is much cheaper (lazy list cons nodes)
> * built in desugaring for build/foldr fusion interferes (enumerations,
chad.scherrer:
> > they currently use two different fusion systems. bytestring uses an
> > older version of what is now stream fusion. at some point we'll switch
> > bytestrings over to using the new stuff in the stream-fusion package,
> > since its a lot better.
>
> Oh, that's pretty interesting.
> they currently use two different fusion systems. bytestring uses an
> older version of what is now stream fusion. at some point we'll switch
> bytestrings over to using the new stuff in the stream-fusion package,
> since its a lot better.
Oh, that's pretty interesting. I had assumed bytestring h
chad.scherrer:
> On Feb 17, 2008 4:13 PM, Brandon S. Allbery KF8NH <[EMAIL PROTECTED]> wrote:
>
> > Have you looked at the stream-fusion package on Hackage?
> > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-
> > fusion-0.1.1
>
> Yeah, I've seen this. It's nice that this is sep
chad.scherrer:
> ByteStrings have given a real performance boost to a lot of Haskell
> applications, and I'm curious why some of the techniques aren't more
> abstracted and widely available. If it's "because it's a big job",
> that's certainly understandable, but maybe there's something I'm
> overl
On Feb 17, 2008, at 19:23 , Chad Scherrer wrote:
On Feb 17, 2008 4:13 PM, Brandon S. Allbery KF8NH
<[EMAIL PROTECTED]> wrote:
Have you looked at the stream-fusion package on Hackage?
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-
fusion-0.1.1
Yeah, I've seen this. It's n
On Feb 17, 2008 4:13 PM, Brandon S. Allbery KF8NH <[EMAIL PROTECTED]> wrote:
> Have you looked at the stream-fusion package on Hackage?
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-
> fusion-0.1.1
Yeah, I've seen this. It's nice that this is separated, but a little
unsatisf
On Feb 17, 2008, at 18:53 , Chad Scherrer wrote:
ByteStrings have given a real performance boost to a lot of Haskell
applications, and I'm curious why some of the techniques aren't more
abstracted and widely available. If it's "because it's a big job",
that's certainly understandable, but maybe
ByteStrings have given a real performance boost to a lot of Haskell
applications, and I'm curious why some of the techniques aren't more
abstracted and widely available. If it's "because it's a big job",
that's certainly understandable, but maybe there's something I'm
overlooking that some of the a
13 matches
Mail list logo
