String != [Char]

[Edward Kmett]

On Mon, Mar 26, 2012 at 5:56 PM, Ben Millwood <haskell at benmachine.co.uk>wrote:

> On Mon, Mar 26, 2012 at 6:21 PM, Brandon Allbery <allbery.b at gmail.com>
> wrote:
> > On Mon, Mar 26, 2012 at 13:12, Ian Lynagh <igloo at earth.li> wrote:
> >>
> >> Maybe your point is that neither "take" function should be used with
> >> unicode strings, but I don't see how advocating the Text type is going
> >> to help with that.
> >
> >
> > I think we established earlier that the list-like operations on Text are
> a
> > backward compatibility wart.  Either they should go away, or they should
> be
> > modified to operate on some other level than codepoints.  Probably the
> way
> > the ecosystem should work is that [Char] (or possibly a packed version
> > thereof, sort of like lazy ByteStrings with Word32 instead of Word8 as
> the
> > fundamental unit) is the codepoint view and Text is the grapheme view;
> both
> > are necessary at various times, but the grapheme view is the more natural
> > one for text /per se/.
> >
>
> Does this mean we've firmly established that there currently is *no*
> completely satisfactory method of dealing with Unicode in existence
> today? In that case, even if it /will be/ a good idea one day, can't
> we agree that it's not the right time to deprecate String = [Char]?
> The language has a good history, I understand, of not standardising
> that which is not implemented and in common use, so if we'd like to
> change Text before introducing it to the language, I say let's do that
> separately.
>

Agreed. Haskell-prime has in the past gone out of its way not to
standardize anything that hasn't actually been implemented somewhere.


> No-one's yet argued against OverloadedStrings. I think there /is/ an
> argument to be made, that it introduces ambiguity and could break
> existing programs (probably we can extend defaulting to take care of
> this, but I think there are people who'd be happier if we killed
> defaulting too). Too much polymorphism /can/ be a bad thing. But I
> think there's a serious chance we can make that happen, and make Text
> a bit more pleasant to work with.
>

I would agree that OverloadedStrings definitely needs to work with
defaulting better! I've been bitted by this in my own code.

In the past I have longed for a trivial class

class Defaulting a

which merely served to meet the conditions for extended default from

http://www.haskell.org/ghc/docs/6.6/html/users_guide/ch03s04.html#extended-default-rules
*
*

> *All* of the classes Ci are single-parameter type classes.
> At least one of the classes Ci is numeric, *or is Show, Eq, or Ord*.


by adding Defaulting to the list of extra classes the language permits.

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.

A passing thought: nearly anything can be made an instance of
> IsString, via something read-like. This prospect upsets me a little :)
> Maybe it would make sense to introduce additional methods, as in Num,
> to make sure that some sense is maintained (perhaps toString?)


I don't like the idea of adding a toString to IsString. One of the more
compelling usecases is in DSLs.

Just because I can make an

instance IsString Expr where
  fromString = StringLiteral

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.

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.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-prime/attachments/20120326/bd28c55b/attachment.htm>