No subject
Thu Feb 24 17:58:36 CET 2011
languages could lead the same problems.
Personally, I don't see difference between typo in
>n = name "foo}bar"
and
>n = "foo}bar"
But I prefer the second because I have no additional function names in my
memory.
I consider IsString instance just as standard conversion from String without
any parameters.
2011/6/9 Yitzchak Gale <gale at sefer.org>
> >> Since the whole idea of xml-types is for it to be a
> >> unifying standard, I'd like to see it usable in that kind
> >> of environment, too.
>
> > It is usable in such an environment -- simply do not
> > use the IsString instance.
>
> Once you have the Name type rather than just Text -
> which is useful for people needing namespaces -
> the IsString instance is important to keep code from
> becoming really awkward.
>
> Perhaps the real problem here is including Clark
> notation in the IsString instance. Clark notation is
> very nice, but it doesn't really belong in the IsString
> instance. Clark notation could be a function, or a
> quasi-quoter. Perhaps the client library should be
> allowed to decide.
>
> But if it is included in the IsString instance, it
> absolutely cannot raise an asynchronous exception.
> That is a serious bug.
>
> >> In addition, I have already pointed out that semantically
> >> it doesn't make sense for a fromString implementation
> >> to return _|_. And it is easy to make a small change
> >> to the current implementation to avoid that.
> >>
> >> So let me turn the question around. Is there a compelling
> >> reason why, in some use case, the fromString must
> >> return _|_, rather than returning some text that will allow
> >> the application to handle the situation itself?
>
> > The string "foo}bar" is invalid; it must *never* be converted to a
> > Name. Doing so would cause silent, unpredictable failures which cannot
> > be tested for.
>
> '}' `elem` name would do the trick nicely.
>
> The Name type already produces invalid XML. A client library
> that wants to avoid invalid names must already check for them.
> If a typo in Clark notation were another way to create invalid
> XML that wouldn't change anything.
>
> But if that really bothers you, let's discuss the many other
> options for introducing Clark notation other than in the IsString
> instance.
>
> > IsString does not support reporting parse errors;
>
> Right, and it shouldn't. IsString is just a way of giving a different
> string type, like ByteString or Text, to Haskell's string literal syntax.
> There is no parsing to do beyond what the compiler already does.
> Any IsString instance should just take the contents of the string
> literal and incorporate it directly into the string type.
>
> There is no language I've ever heard of where you can cause a
> program to crash at *runtime* because of the particular characters
> you include in a string literal in your source code. Please don't make
> Haskell the first. That would be very ironic.
>
> > if you're very concerned about it, I could add a flag like
> > "NoIsString" which disables that particular instance. You could enable
> > it in your build scripts.
>
> I wouldn't use that flag. I need and use the IsString instance.
> The instance must be defined in the module that defines the type.
>
> Thanks,
> Yitz
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
--001485f85f327ef0ce04a544f3db
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><div class=3D"gmail_quote"><div class=3D"im">> There is no language =
I've ever heard of where you can cause a<br>> program to crash at *r=
untime* because of the particular characters<br>> you include in a strin=
g literal in your source code. Please don't make<br>
> Haskell the first. That would be very ironic.<br>
<br></div>This possibility is provided by "OverloadedStrings" ext=
ension, not by instance for Name.<br>From other side I suppose that any imp=
licit transformation in other languages could lead the same problems. <br>
<br>
Personally, I don't see difference between typo in <br>>n =3D name &=
quot;foo}bar" <br>and <br>>n =3D "foo}bar"<br><br>But I p=
refer the second because I have no additional function names in my memory.<=
br>
I consider IsString instance just as standard conversion from String withou=
t any parameters.<div><div></div><div class=3D"h5"><br><br><br><br><div cla=
ss=3D"gmail_quote">2011/6/9 Yitzchak Gale <span dir=3D"ltr"><<a href=3D"=
mailto:gale at sefer.org" target=3D"_blank">gale at sefer.org</a>></span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>>> Since the whole idea of xml-ty=
pes is for it to be a<br>
>> unifying standard, I'd like to see it usable in that kind<br>
>> of environment, too.<br>
<br>
> It is usable in such an environment -- simply do not<br>
> use the IsString instance.<br>
<br>
</div>Once you have the Name type rather than just Text -<br>
which is useful for people needing namespaces -<br>
the IsString instance is important to keep code from<br>
becoming really awkward.<br>
<br>
Perhaps the real problem here is including Clark<br>
notation in the IsString instance. Clark notation is<br>
very nice, but it doesn't really belong in the IsString<br>
instance. Clark notation could be a function, or a<br>
quasi-quoter. Perhaps the client library should be<br>
allowed to decide.<br>
<br>
But if it is included in the IsString instance, it<br>
absolutely cannot raise an asynchronous exception.<br>
That is a serious bug.<br>
<div><br>
>> In addition, I have already pointed out that semantically<br>
>> it doesn't make sense for a fromString implementation<br>
>> to return _|_. And it is easy to make a small change<br>
>> to the current implementation to avoid that.<br>
>><br>
>> So let me turn the question around. Is there a compelling<br>
>> reason why, in some use case, the fromString must<br>
>> return _|_, rather than returning some text that will allow<br>
>> the application to handle the situation itself?<br>
<br>
> The string "foo}bar" is invalid; it must *never* be converte=
d to a<br>
> Name. Doing so would cause silent, unpredictable failures which cannot=
<br>
> be tested for.<br>
<br>
</div>'}' `elem` name would do the trick nicely.<br>
<br>
The Name type already produces invalid XML. A client library<br>
that wants to avoid invalid names must already check for them.<br>
If a typo in Clark notation were another way to create invalid<br>
XML that wouldn't change anything.<br>
<br>
But if that really bothers you, let's discuss the many other<br>
options for introducing Clark notation other than in the IsString<br>
instance.<br>
<div><br>
> IsString does not support reporting parse errors;<br>
<br>
</div>Right, and it shouldn't. IsString is just a way of giving a diffe=
rent<br>
string type, like ByteString or Text, to Haskell's string literal synta=
x.<br>
There is no parsing to do beyond what the compiler already does.<br>
Any IsString instance should just take the contents of the string<br>
literal and incorporate it directly into the string type.<br>
<br>
There is no language I've ever heard of where you can cause a<br>
program to crash at *runtime* because of the particular characters<br>
you include in a string literal in your source code. Please don't make<=
br>
Haskell the first. That would be very ironic.<br>
<div><br>
> if you're very concerned about it, I could add a flag like<br>
> "NoIsString" which disables that particular instance. You co=
uld enable<br>
> it in your build scripts.<br>
<br>
</div>I wouldn't use that flag. I need and use the IsString instance.<b=
r>
The instance must be defined in the module that defines the type.<br>
<br>
Thanks,<br>
Yitz<br>
<div><div></div><div><br>
_______________________________________________<br>
web-devel mailing list<br>
<a href=3D"mailto:web-devel at haskell.org" target=3D"_blank">web-devel at haskel=
l.org</a><br>
<a href=3D"http://www.haskell.org/mailman/listinfo/web-devel" target=3D"_bl=
ank">http://www.haskell.org/mailman/listinfo/web-devel</a><br>
</div></div></blockquote></div><br>
</div></div></div><br>
--001485f85f327ef0ce04a544f3db--
More information about the web-devel
mailing list