I'm afraid I don't much care for this solution either. (1) it's not at all clear to me what on earth it's good for. The main reason I use unsafe casting is because I need a way of storing and retrieving a value in a storage location which does not know its type. For example, a finite map which contains values of different types. It should always be the case that the type with which I wish to extract the value is the same at which I want to put the value in. Usually I do this kind of thing via Glasgow Haskell's Dynamic types. I don't think the Read/Show solution really helps much. (2) My mind revolts from the idea of having to casting numbers by converting them into their ASCII decimal representation. This is also potentially an expensive operation, for example for floats, where converting a very large or very small float to decimal in such a way that the original float can be recovered is an operation requiring expensive multiprecision arithmetic. (It is possible to speed this up to some extent, but this involves either tricky coding, or making compromises with precision which mean that the number you get out may not be the number you put in.) (3) In many cases this is wholly impossible, for example functions, or values of IO type. I have actual examples where I do this sort of thing. (4) It does not work intuitively. For example you can cast (10^20) from Integer to Float, even though it is not precisely representable. You cannot cast from Float to Integer at all. The main way I can envisage users using this kind of cast is for converting between different sorts of numbers. But there are already good ways of doing this kind of thing (fromIntegral, Numeric.fromRat). Surely it is much better for the user to be encouraged to these functions?