<div>On Mon, Mar 26, 2012 at 5:56 PM, Ben Millwood <span dir="ltr"><<a href="mailto:haskell@benmachine.co.uk">haskell@benmachine.co.uk</a>></span> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, Mar 26, 2012 at 6:21 PM, Brandon Allbery <<a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>> wrote:<br>
> On Mon, Mar 26, 2012 at 13:12, Ian Lynagh <<a href="mailto:igloo@earth.li">igloo@earth.li</a>> wrote:<br>
>><br>
>> Maybe your point is that neither "take" function should be used with<br>
>> unicode strings, but I don't see how advocating the Text type is going<br>
>> to help with that.<br>
><br>
><br>
> I think we established earlier that the list-like operations on Text are a<br>
> backward compatibility wart. Either they should go away, or they should be<br>
> modified to operate on some other level than codepoints. Probably the way<br>
> the ecosystem should work is that [Char] (or possibly a packed version<br>
> thereof, sort of like lazy ByteStrings with Word32 instead of Word8 as the<br>
> fundamental unit) is the codepoint view and Text is the grapheme view; both<br>
> are necessary at various times, but the grapheme view is the more natural<br>
> one for text /per se/.<br>
><br>
<br>
</div>Does this mean we've firmly established that there currently is *no*<br>
completely satisfactory method of dealing with Unicode in existence<br>
today? In that case, even if it /will be/ a good idea one day, can't<br>
we agree that it's not the right time to deprecate String = [Char]?<br>
The language has a good history, I understand, of not standardising<br>
that which is not implemented and in common use, so if we'd like to<br>
change Text before introducing it to the language, I say let's do that<br>
separately.<br></blockquote><div><br></div><div>Agreed. Haskell-prime has in the past gone out of its way not to standardize anything that hasn't actually been implemented somewhere.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
No-one's yet argued against OverloadedStrings. I think there /is/ an<br>
argument to be made, that it introduces ambiguity and could break<br>
existing programs (probably we can extend defaulting to take care of<br>
this, but I think there are people who'd be happier if we killed<br>
defaulting too). Too much polymorphism /can/ be a bad thing. But I<br>
think there's a serious chance we can make that happen, and make Text<br>
a bit more pleasant to work with.<br></blockquote><div><br></div><div>I would agree that OverloadedStrings definitely needs to work with defaulting better! I've been bitted by this in my own code.</div><div><br></div>
<div>In the past I have longed for a trivial class</div><div><br></div><div><font face="courier new, monospace">class Defaulting a</font></div><div><br></div><div>which merely served to meet the conditions for extended default from</div>
<div><br></div><div><a href="http://www.haskell.org/ghc/docs/6.6/html/users_guide/ch03s04.html#extended-default-rules">http://www.haskell.org/ghc/docs/6.6/html/users_guide/ch03s04.html#extended-default-rules</a></div><div>
<span class="emphasis" style="font-family:sans-serif"><em><br></em></span></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class="emphasis" style="font-family:sans-serif"><em>All</em></span><span style="font-family:sans-serif"> </span><span style="font-family:sans-serif">of the classes</span><span style="font-family:sans-serif"> </span><code class="literal">Ci</code><span style="font-family:sans-serif"> </span><span style="font-family:sans-serif">are single-parameter type classes.<br>
</span><span style="font-family:sans-serif">At least one of the classes</span><span style="font-family:sans-serif"> </span><code class="literal">Ci</code><span style="font-family:sans-serif"> </span><span style="font-family:sans-serif">is numeric,</span><span style="font-family:sans-serif"> </span><span class="emphasis" style="font-family:sans-serif"><em>or is <code class="literal">Show</code>, <code class="literal">Eq</code>, or <code class="literal">Ord</code></em></span><span style="font-family:sans-serif">.</span></blockquote>
<div><br></div><div>by adding Defaulting to the list of extra classes the language permits.</div><div><br></div><div>In the special case of ghc where we have polymorphic kinds now, the Defaulting class could allow for defaulting rules to then be applied trivially for higher kinds, and when you have new classes you really want defaulting to apply, like in this case IsString, you could just add Defaulting as a superclass constraint.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A passing thought: nearly anything can be made an instance of<br>
IsString, via something read-like. This prospect upsets me a little :)<br>
Maybe it would make sense to introduce additional methods, as in Num,<br>
to make sure that some sense is maintained (perhaps toString?)</blockquote><div></div></div><div><br></div><div>I don't like the idea of adding a toString to IsString. One of the more compelling usecases is in DSLs. </div>
<div><br></div><div>Just because I can make an </div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">instance IsString Expr where</font></div><div><font face="courier new, monospace"> fromString = StringLiteral</font></div>
<div><br></div><div>to get a syntaxless embedding of string literals into my language for some expression type, doesn't mean that every expression is a string literal.</div><div><br></div><div>Ultimately, abuses of IsString for parsing should probably just be treated with the same general distaste as the use of Show instances that don't show source representations.</div>
<div><br></div><div>-Edward</div>