Johan Tibell wrote:
With this approach I would like some facility (e.g. table) to lookup common encodings as the encoding used for a particular datum is not know at compile time in many applications (e.g. it's read from a HTTP Content-Type header or similar.)
lookupEncoding :: String -> Maybe Encoding
In fact, there is probably use for several such lookup functions: one for each naming scheme for encodings (and there are several of those, largely overlapping). This lookupEncoding function can be implemented after the fact -- perhaps in a library dedicated to dealing with MIME content -- and it may look something like: lookupEncoding "ISO-8859-1" = Just iso8859_1 lookupEncoding "ISO-8859-2" = Just iso8859_2 ... lookupEncoding _ = Nothing And voila! You've got yourself a way to look up text encodings by name. All this praise of Java makes me nervous, because as a programmer interface, Java is *wrong* about text encodings. Its standard library treats strings, mainly, as the right type for talking about text encodings; and they are not! It keeps one global name-to-encoding mapping, assigns each encoding a canonical "Java name", which is sometimes invented out of thin air. The compiler has no list of encodings that will be available, so it doesn't complain if you hard-code a misspelled encoding name into your program. This stuff is *really* *bad*; it's part of why using Java is a chore rather than a joy. Obviously, I'd like to see Haskell avoid that route. I'm not saying anyone proposed going in that direction; but I got the sense that we may be wandering dangerously close. This is no less fundamental than a question of whether we use language features, or fear them because we fear committment. As Simon mentioned, perhaps there are more things that need to happen to make the language features to make them more compatibility-friendly; but we should make a concerted effort to dive right in and use language features for their intended purpose rather than timidly hang around the outside fringes. -- Chris Smith