<br><br><div class="gmail_quote">On Fri, Aug 13, 2010 at 4:03 PM, Ivan Lazar Miljenovic <span dir="ltr"><<a href="mailto:ivan.miljenovic@gmail.com">ivan.miljenovic@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Kevin Jardine <<a href="mailto:kevinjardine@gmail.com">kevinjardine@gmail.com</a>> writes:<br>
<br>
> Hi Don,<br>
><br>
> With respect, I disagree with that approach.<br>
><br>
> Almost every modern programming language has one or at most two<br>
> standard representations for strings.<br>
<br>
</div>Almost every modern programming language thinks you can whack a print<br>
statement wherever you like... ;-)<br>
<div class="im"><br>
> That includes PHP, Python, Ruby, Perl and many others. The lack of a<br>
> standard text representation in Haskell has created a crazy patchwork<br>
> of incompatible libraries requiring explicit and often inefficient<br>
> conversions to connect them together.<br>
><br>
> I expect Haskell to be higher level than those other languages so that<br>
> I can ignore the lower level details and focus on the algorithms. But<br>
> in fact the string issue forces me to deal with lower level details<br>
> than even PHP requires. I end up with a program littered with ugly<br>
> pack, unpack, toString, fromString and similar calls.<br>
<br>
</div>So, the real issue here is that there is not yet a good abstraction over<br>
what we consider to be textual data, and instead people have to code to<br>
a specific data type.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Isn't it also a problem which is partially solved with the OverloadedStrings extension?</div><div><a href="http://haskell.cs.yale.edu/ghc/docs/6.12.2/html/users_guide/type-class-extensions.html#overloaded-strings">http://haskell.cs.yale.edu/ghc/docs/6.12.2/html/users_guide/type-class-extensions.html#overloaded-strings</a></div>
<div><br></div><div>It seems like the interface exposed by ByteString could be in a type class. At that point, would the problem be solved?</div><div><br></div><div>Jason</div></div>