Proposal: Improving the IsString String instance
gabriel439 at gmail.com
Mon Aug 26 19:03:43 CEST 2013
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
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
> 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.
> 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
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries