Brandon S. Allbery KF8NH wrote:
On Nov 3, 2007, at 5:34 , Andrew Coppin wrote:
(BTW, anybody have any clue what's happening with stream fusion? I
remember reading the paper saying "hey, this is how it works and it's
cool and we're going to try to replace the whole list library with new
strea
On Nov 3, 2007, at 5:34 , Andrew Coppin wrote:
(BTW, anybody have any clue what's happening with stream fusion? I
remember reading the paper saying "hey, this is how it works and
it's cool and we're going to try to replace the whole list library
with new stream implementations", but that's
Andrew Coppin wrote:
Duncan Coutts wrote:
Yes, the semantics are different. ByteString is stricter. In some
circumstances you could discover that some list is being used
sufficiently strictly (spine and element strict) that you could do a
representation change to use strict arrays. It is somethi
Duncan Coutts wrote:
On Fri, 2007-11-02 at 21:35 +, Andrew Coppin wrote:
Well OK, maybe I was a little vague. Let me be a bit more specific...
If you do text processing using ByteString rather than String, you get
dramatically better performance in time and space. For me, this raises a
On Fri, 2007-11-02 at 21:35 +, Andrew Coppin wrote:
> Well OK, maybe I was a little vague. Let me be a bit more specific...
>
> If you do text processing using ByteString rather than String, you get
> dramatically better performance in time and space. For me, this raises a
> number of quest
On Nov 2, 2007, at 17:35 , Andrew Coppin wrote:
These are the things I'm thinking about. Is there some deep
theoretical reason why things are the way they are? Or is it merely
that nobody has yet had time to make something better? ByteString
solves the problem of text strings (and raw bina
Andrew Coppin wrote:
1. Why do I have to type "ByteString" in my code? Why isn't the compiler
automatically performing this optimisation for me?
One reason is that ByteString is stricter than String. Even lazy
ByteString operates on 64KB chunks. You can see how this might lead to
problems
Tim Chevalier wrote:
I don't think there's a deep theoretical reason why this doesn't
exist, but I also don't think it's necessarily *just* a matter of no
one having had time yet. As always, there are trade-offs involved, and
people try to avoid introducing *too* many special cases into the
compi
On 11/2/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
>
> 1. Why do I have to type "ByteString" in my code? Why isn't the compiler
> automatically performing this optimisation for me? (I.e., is there some
> observable property that is changed? Currently the answer is yes: the
> ByteString interface
Tim Chevalier wrote:
On 11/2/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
Somewhat related to the discussions about Haskell's performance...
String. ByteString. Do we really need both? Can one replace the other?
You can't get rid of "String" because a String is just a [Char].
Requirin
On 11/2/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
> Somewhat related to the discussions about Haskell's performance...
>
> String. ByteString. Do we really need both? Can one replace the other?
You can't get rid of "String" because a String is just a [Char].
Requiring the element type of a list
Somewhat related to the discussions about Haskell's performance...
String. ByteString. Do we really need both? Can one replace the other?
Why is one faster? Can't we make *all* lists this fast? [insert further
variations here]
Thoughts?
___
Haskell
12 matches
Mail list logo
