[Haskell-cafe] Re: String vs ByteString

Jason Dagit dagit at codersbase.com
Fri Aug 13 19:35:48 EDT 2010


On Fri, Aug 13, 2010 at 4:03 PM, Ivan Lazar Miljenovic <
ivan.miljenovic at gmail.com> wrote:

> Kevin Jardine <kevinjardine at gmail.com> writes:
>
> > Hi Don,
> >
> > With respect, I disagree with that approach.
> >
> > Almost every modern programming language has one or at most two
> > standard representations for strings.
>
> Almost every modern programming language thinks you can whack a print
> statement wherever you like... ;-)
>
> > That includes PHP, Python, Ruby, Perl and many others. The lack of a
> > standard text representation in Haskell has created a crazy patchwork
> > of incompatible libraries requiring explicit and often inefficient
> > conversions to connect them together.
> >
> > I expect Haskell to be higher level than those other languages so that
> > I can ignore the lower level details and focus on the algorithms. But
> > in fact the string issue forces me to deal with lower level details
> > than even PHP requires. I end up with a program littered with ugly
> > pack, unpack, toString, fromString and similar calls.
>
> So, the real issue here is that there is not yet a good abstraction over
> what we consider to be textual data, and instead people have to code to
> a specific data type.
>

Isn't this the same problem we have with numeric literals?  I might even go
so far as to suggest it's going to be a problem with all types of literals.

Isn't it also a problem which is partially solved with the OverloadedStrings
extension?
http://haskell.cs.yale.edu/ghc/docs/6.12.2/html/users_guide/type-class-extensions.html#overloaded-strings

It seems like the interface exposed by ByteString could be in a type class.
 At that point, would the problem be solved?

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100813/dac2f8e5/attachment.html


More information about the Haskell-Cafe mailing list