On Fri, Aug 13, 2010 at 4:03 PM, Ivan Lazar Miljenovic < ivan.miljeno...@gmail.com> wrote:
> Kevin Jardine <kevinjard...@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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
