Proposal: Improving the IsString String instance

[Gabriel Gonzalez]

May I propose an alternative solution?  Why not just add a syntactic way to
selectively opt in or out of `OverloadedStrings` for certain string
literals?  It could be something as simple as Python's trick for prefixing
string literals with a single character to either enable or disable the
overloading:

    example1 :: Int
    example1 = length "Non-overloaded string"

    example2 :: Parser Int
    example2 = o"Overloaded string" *> pure 4

... but it doesn't have to be that specific solution.  All that really
matters is that it is syntactically lightweight.

I would personally prefer "opt-in" that way you could safely turn on
`OverloadedStrings` in any module without errors and then use whatever
syntactic annotation when you want to overload a particular string.

The reason I propose this solution is that I foresee the exact same problem
occurring later on for `OverloadedLists` where you will get ambiguous type
errors any time you pass a list literal to a function of `Foldable`s.
 Similarly, in that case it would also be nice to be able to selectively
opt in or out of overloaded list literals on a per-literal basis instead of
turning it on for every list literal within the module.


On Mon, Aug 26, 2013 at 9:45 AM, Edward Kmett <ekmett at gmail.com> wrote:

> If Ian can make defaulting work, then I'd prefer that solution. It hurts
> nobody and just makes everything work better.
>
> length was just the most galling example among many.
>
> The resolution to Ian's suggestion would absolutely affect just how
> liberal we want to be with generalizing more of the list combinators to
> Foldable/Traversable.
>
> There are a lot of desiderata to consider in balancing the needs of base.
>
> Forcing the only list based instance to be String is an arbitrary
> decision, but it fixes the vast majority of the issues with a typeclass and
> extension that was intended to be a convenience but currently causes a
> great deal of incovenience in otherwise unrelated code when you turn it on.
>
> Having base export two randomly different versions of the same combinator
> all over the place is also an inconvenience and fixing it comes with some
> tension towards OverloadedStrings.
>
> Forcing users to use signatures on every String and import
> Data.Traversable and Data.Foldable qualified "works," but it is the
> design equivalent of sticking your head in the sand and pretending their we
> don't have any problems.
>
> -Edward
>
>
> On Mon, Aug 26, 2013 at 12:33 PM, Henning Thielemann <
> schlepptop at henning-thielemann.de> wrote:
>
>> Am 25.08.2013 23:02, schrieb Edward Kmett:
>>
>>  The issue is that length "abc", splitAt 2 "abc", and dozens of other
>>> tools just stop working for anyone who turns on OverloadedStrings right
>>> now.
>>>
>>> IsString was originally put forth as a convenience to make string
>>> literals work with Text, ByteString, directly as a parsing combinator,
>>> or as a variable name or string type in an expression language, but
>>> presently that functionality comes at the tax that random other bits of
>>> code in your file stop working when you turn it on.
>>>
>>> My proposal is intended to address this fact, by giving up a subset of
>>> possible convenience instances in exchange for fixing the real headache
>>> this induces for users.
>>>
>>
>> What you propose is, to let the compiler infer: "If it is something
>> string-like (imposed by the string literal syntax in the presence of
>> OverloadedStrings) and it is a list (imposed by 'length'), then it must be
>> a String".
>>
>> This conclusion looks rather arbitrary to me. If 'length' would be more
>> specific (e.g. Text.length) your problem would not arise. If 'length' would
>> be more generic (e.g. Foldable.length) your proposal would not help. The
>> problem only arises, because you want to use Prelude's list functions
>> (_and_ OverloadedStrings _and_ don't want to write type annotations).
>>
>> I predict that soon people will propose here on this mailing list to
>> replace Prelude's half-monomorphic 'length' by a fully polymorphic
>> Foldable.length. It does not yet exist, but it could be added easily. What
>> will you do then?
>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130826/d4fdbc60/attachment.htm>