[Adding cvs-ghc, the GHC hackers list] | Output via strings alone is obsolete. Haskell should lead | the way by providing customisable support for output via | documents. I'm interested in documents for pretty printing, | but it is easy to imagine other applications as well, such | as HTML.
I'm all for that! | I wrote to you in May to say that I would have a student | writing a generic pretty printer for Haskell, and to ask on | your advice for which generic mechanism to use. The | student, Razvan Ranca, has now completed his work, which is | available here: | | http://hackage.haskell.org/package/GenericPretty Great! adding a couple of examples to the documentation at this link would help users, I think. And a link to his project report, for more background. | To use Razvan's library with first-year students, some extra | support in GHC is required. [I've re-ordered your list] | * To make things easy for first years, it would also | help to be able to create a custom version of ghci, | which automatically imports the necessary modules | and turns on the necessary pragmas. This would be | easy if GHCi had flags to specify the necessary | information. I believe this is already available, simply by putting stuff in your .ghci file. | * The ability to specify how the read-eval-print loop | converts data values to strings. What GHCi does is to compile (show it), where 'it' is the value just computed. So what you want is to be able to say "use the 'show' from my library, rather than using GHC.Show.show". Right? This is very like what the language extension RebindableSyntax does. http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#rebindable-syntax Except I suppose that you might not want to rebind *all* syntax, bur only the implicitly-called 'show' function. Then there's the question of how to specify which 'show' function to call. The one that happens to be in scope? That would be consistent with RebindableSyntax. Or, I suppose, you could specify a particular function to use -- that would require a bit more fiddling, because the InteractiveContext would need to remember what this function was. | * The ability to specify new class names that can | appear in a deriving clause. I think you mean you want to say data T = MkT deriving( MyPretty ) rather than data T = MkT deriving MyPretty T I'm more cautious about this. Why not just say the latter? The former is full of special cases; for example, if you say ...deriving( Enum ) you get a decent error message in the case where the type is not an enumeration. Moreover, there is quite a bit of huffing and puffing to *infer* a (probably) suitable context for the instance. So that when you say data S a = MkS a deriving( Eq ) you get the derived instance instance (Eq a) => Eq (S a) where... where the "(Eq a) => " context is inferred. This context inference process does not scale well to arbitrary classes (I can elaborate if you want). With standalone deriving instances the programmer gets to write the instances, which is probably a good thing: data S a = MkS a deriving instance Eq a => Eq (S a) So the compiler fills in the code, but the programmer writes the type signature. Simon _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
