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.
This possibility is provided by "OverloadedStrings" extension, not by instance for Name.
From other side I suppose that any implicit transformation in other 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
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@haskell.org http://www.haskell.org/mailman/listinfo/web-devel