[web-devel] xml-types IsString instance for Name causes crashes

[Yitzchak Gale]

I wrote:
>>> I noticed when looking at the IsString instance
>>> for Name: it can introduce crashes into a program if someone
>>> accidentally puts a '{' at the beginning of a Name string.
> Or accidentally omits the '}' in Clark notation.
> The way xml-types is now, it cannot be used in an
> environment where code is not allowed to introduce
> any additional risk of crashes. That is quite common in
> commercial development.

John Millikin wrote:
> The code won't ever *crash*, it will merely throw an exception,
> which can be caught...
> Second, GHC's IsString feature is not enabled by default...
> Third, the IsString instance is largely for convenience...

Sorry, I guess I really wasn't making myself clear.

I never raised any doubts about it being *possible*, or even
easy, to write safe code using the xml-types library as it
is now.

In a large-scale software development environment, one way
that risk is evaluated is by counting the number of ways that it
is *possible* for a library to cause a crash. And yes, in this
context raising an asynchronous exception that knocks your
program all the way out to some last-chance exception
handler in the outer IO layer counts as a crash.

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.

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?

Thanks,
Yitz