Avoid non-default Show Name and Read Name (fix #120)

[Toxaris]

I like these changes.

Except for the names readName and showName. Can we rename these to something like parseName and prettyName to make it clear that these functions are related to the concrete syntax of PTS, but not related to the Show and Read type classes.

[Blaisorblade]

• [ ] Except for the names readName and showName. Can we rename these to something like parseName and prettyName to make it clear that these functions are related to the concrete syntax of PTS, but not related to the Show and Read type classes.

Sure.

• [ ] To automatically check the invariant that "Show is only used for debugging", we could disable deriving Show during integration testing (using CPP or regexp substitution or whatever).

True, though I'm not enthusiast of CPP. But since we use it already, I guess we could.

[Toxaris]

Alternative to CPP:

If we use standalone instance deriving, we could put the deriving instance Show whatever statements into a seperate module that is part of the library, but not imported by any other modules in the library nor by the application.

[Blaisorblade]

If we use standalone instance deriving, we could put the deriving instance Show whatever statements into a seperate module that is important when developers use ghci, but not imported into the actual library and application.

That's an orphan instance, but I'm fine with that (EDIT: and IIRC we have some already). Also, that module could be auto-imported by PTS.Interactive, so it wouldn't be a pain for students.

[Toxaris]

Yes, it is an orphan instance. But since you're never supposed to import that module into a reusable library, most problems of orphan instances don't apply. Yes, PTS.Interactive would import or contain these instances.