John Millikin wrote:
To me, the choice is between raising an exception or removing IsString.
That would be a shame, but removing it may be the only way out of this conundrum.
IsString without namespaces is pointless.
I am making good use of it in a project that doesn't involve namespaces at all. It would actually be a lot of work to back out at this point.
IsString without input checking is dangerous. If fromString cannot fail on invalid input, then it shouldn't be defined.
I appreciate your concerns, but Haskell has other means of providing such guarantees. Raising an asynchronous exception is just not an option in an IsString instance.
The Name type already produces invalid XML.
You're right -- it is already possible for Names to be invalid. There should probably be stricter input checking on names, to ensure they match the XML spec. Something like this...
Yes, as I mentioned earlier, newtype wrappers with hidden constructors is the way we would do that if we wanted to guarantee those kinds of things at the type level. You could then provide several constructor functions that either do or do not raise exceptions. See, for example, Data.Text.Encoding, Neil Mitchell's Safe library, Michael's xml-enumerator. But you certainly could not use the version that raises an exception for an IsString instance. In fact, I don't think an IsString instance makes sense at all for a validating type. So maybe just removing it really is the right thing to do after all. Thanks, Yitz