On Thu, Jul 08, 2021 at 09:02:29PM +0200, Hécate wrote:
From what I can see from the various typeclasses that exist:
Sadly, no new or extant alternative type classes can address the problem, simply because they're NOT `Show`, which is the default interface for inspecting the content of a term, and so is the only one at all likely to be available for the terms of interest. Yes, we should also consider having more type classes for presentation in forms other than compiler-friendly source syntax. Thus, e.g. for DNS data, one might have `Show` for debugging, but `Present` for textual presentations of DNS resource records specified in the multitude of DNS-related RFCs and used as the input syntax in DNS zone files. (Thus a DNS RR would have a binary wire form, an ASCII ByteString presentation form, a `Show` instance that exposes all the constructors, ..., and in the case of domain names also a U-label form for display of domain names to users more comfortable with the native script). Multiple applicable serialisation formats are to be expected, and yet I think that `Show` should still avoid escaping unicode printable text... I don't see a plausible path of getting most libraries that implement `Show` to start implemeting a second parallel class for friendly display. Unless you're thinking overlapping instances: instance Show a => Display a where display = show instance Display String where display = displayString -- Viktor.