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
becoming
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 not
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, 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
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
unsatisfying
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
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
overlooking
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 separated, but
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 had
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. I had
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,
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)
* built in
13 matches
Mail list logo
