On Fri, Nov 9, 2012 at 10:22 PM, Roman Cheplyaka wrote:

* Johan Tibell [2012-11-09 19:00:04-0800]

...

As a community we should primary use strict ByteStrings and Texts. There are uses for the lazy variants (i.e. they are sometimes more efficient), but in general the strict versions should be preferred.

I'm fairly surprised by this advice.

I think that lazy BS/Text are a much safer default.

If there's not much text it wouldn't matter anyway, but for large amounts using strict BS/Text would disable incremental producing/consuming (except when you're using some kind of an iteratee library).

Can you explain your reasoning?

It better communicates intent. A e.g. lazy byte string can be used for two separate things: * to model a stream of bytes, or * to avoid costs due to concatenating strings. By using a strict byte string you make it clear that you're not trying to do the former (at some potential cost due to the latter). When you want to do the former it should be clear to the consumer that he/she better consume the string in an incremental manner as to preserve laziness and avoid space leaks (by forcing the whole string). -- Johan

On Sat, Nov 10, 2012 at 4:00 AM, Johan Tibell wrote:

As for type classes, I don't think we use them enough. Perhaps because Haskell wasn't developed as an engineering language, some good software engineering principles (code against an interface, not a concrete implementation) aren't used in out base libraries. One specific example is the lack of a sequence abstraction/type class, that all the string, list, and vector types could implement. Right now all these types try to implement a compatible interface (i.e. the traditional list interface), without a language mechanism to express that this is what they do.

I think the challenge is designing an abstraction that everyone is comfortable with. If you just make everything a class method (ListLike), it's ugly. If you don't, how do you figure out what goes in the class and what gets implemented on top of it? Is there any principled reason for it, or is it just ad hoc? How do you make sure that none of the implementations suffers a performance decrease? What about sequential vs. random access (list vs. array) issues? Should an interface be implemented if it's semantically reasonable, but slow? If you treat everything as a uniform sequence, doesn't that bring back the Unicode issues again? (And can you make it work for all of Text/ByteString (kind *), boxed Vectors and lists (* -> *), and unboxed vectors (* -> * with a constraint)? What about operations that change the element type? Surely it's possible with TypeFamilies, ConstraintKinds, and PolyKinds all available, but I'm not sure if it's obvious. Can it go into the Prelude if it uses extensions? Should it also support other containers, like Maps? And so on.) So my impression is that the reason the problem hasn't been solved yet is that it's hard. We do have some useful things: Functor, Foldable, Traversable, and the classes in Data.Key[1], but for starters none of them can be implemented by Text and ByteString, so that brings us back to square one. But a constructive idea: what if strict Text and ByteString were both synonyms for unboxed Vectors (already available in ByteString's case[2])? What if, for lazy Text and ByteString, we either had lazy Vectors to make them synonyms of, or a 'data Lazy v' which made a lazy chunked sequence out of any underlying strict Vector-ish type? That would cut down on the number of types, which is a good thing in itself, and it would suggest an obvious way to abstract over them: the existing Functor/Foldable/Traversable/Data.Key classes extended with an associated constraint. I'm not sure how much of the use cases that would cover, but certainly a lot more than we have now. It wouldn't solve every one of the questions above, but it anwers many of them, and it seems like a good compromise. The big drawbacks I can see are that (a) it would be a *lot* of work, especially if we want to be completely uncompromising on performance, and (b) I'm not sure how pinned arrays and interoperation with C would be handled without making it complicated again. (Though I suppose we could just punt and have ByteString be a synonym for Vector.Storable (pinned) and Text for Vector.Unboxed (not pinned) to mirror the current situation. Or maybe we could have a pinArray# primop?) Anyway, if I'm blue-sky dreaming, that's what looks appealing to me. [1] http://hackage.haskell.org/packages/archive/keys/3.0.1/doc/html/Data-Key.htm... [2] http://hackage.haskell.org/package/vector-bytestring -- Your ship was destroyed in a monadic eruption.

At Sat, 10 Nov 2012 15:16:30 +0100, Alberto G. Corona wrote:

There is a ListLike package, which does this nice abstraction. but I don't know if it is ready for and/or enough complete for serious usage. I´m thinking into using it for the same reasons.

Anyone has some experiences to share about it?

I've used it in the past and it's solid, it's been around for a while and the original author knows his Haskell. Things I don't like: * The classes are huge: http://hackage.haskell.org/packages/archive/ListLike/3.1.6/doc/html/Data-Lis.... I'd much rater prefer to have all those utilities functions outside the type class, for no particular reason other then the ugliness of the type class. * It defines its own wrappers for `ByteString': http://hackage.haskell.org/packages/archive/ListLike/3.1.6/doc/html/Data-Lis.... * It doesn't have instances for `Text', you have to resort to the `listlike-instances' package. In any case I think it's on the right track, I'd really like something like that, but much simpler, to be in `base'. Francesco