<div dir="ltr">ok, framed, that way, the proposal seems much more reasonable.<div><br></div><div style>When framed wrt Maybe, I immediately think "nullable values", though now that I think about it more, any use of IsString there would always be f a = Just a, so even then, its philosophically kosher.</div>
<div style><br></div><div style>I withdraw my -1, at least for the applicative version</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 11, 2013 at 8:19 PM, John Lato <span dir="ltr"><<a href="mailto:jwlato@gmail.com" target="_blank">jwlato@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 dir="ltr">To play devil's advocate, why?<div><br></div><div>What does limiting IsString in this fashion gain anyone? It doesn't complicate type inference any more than it already is. For any applicative, there's the trivial instance</div>
<div><br></div><div>instance (IsString a, Applicative t) => IsString (t a) where</div><div> fromString = pure . fromString</div><div><br></div><div>which is conceptually a very simple step and is always total.</div>
<div><br></div><div>Of course some functors admit other instances. I think some parser libraries already provide IsString instances as a nice syntax on matching string literals. A rule like this would invalidate those instances for no particularly good reason I can see.</div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 12, 2013 at 4:22 AM, Sjoerd Visscher <span dir="ltr"><<a href="mailto:sjoerd@w3future.com" target="_blank">sjoerd@w3future.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Could this be formalised by saying that there should be a function toString such that<br>
<br>
fromString . toString = id<br>
<br>
There's no such toString for "Maybe a" with fromString = Just.<br>
<span><font color="#888888"><br>
Sjoerd<br>
</font></span><div><div><br>
On Jul 10, 2013, at 4:02 PM, David Luposchainsky <<a href="mailto:dluposchainsky@googlemail.com" target="_blank">dluposchainsky@googlemail.com</a>> wrote:<br>
<br>
> On 2013-07-10 15:55, Joachim Breitner wrote:<br>
>> Hi,<br>
>><br>
>> Am Mittwoch, den 10.07.2013, 09:21 +1000 schrieb Ivan Lazar Miljenovic:<br>
>>> -0.5 from me; I think it's too easy to forget that it's a Maybe value<br>
>>> there when refactoring, etc.<br>
>><br>
>> same here; even with OverloadedStrings Haskell should feel as strongly<br>
>> typed as it is.<br>
><br>
> Agreed. Overloaded strings should be reserved for things that *are*<br>
> strings in a certain way. A "Maybe String" is not a special way of<br>
> storing a string (like for example a "Vector Char"), it's a String with<br>
> an additional value. Providing a Maybe instance goes too far in the<br>
> direction of having a general "'return' with strings" function, so I'm<br>
> -1 on this.<br>
><br>
> David<br>
><br>
><br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
<br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>