Никита Нежевский writes:

Hello

I'm newcomer in GHC. I'd like to realize native support for colors in ghci (this feature was described in https://ghc.haskell.org/trac/ghc/ticket/10073 ). Great! I've been hoping someone would come along to look at this problem.

Is it possible to realize inside ghci? If possible i'd like to understand how to start implementation and how it might look in ghci?

Really, I believe that the problem that you are describing reduces to the problem of making GHC's error messages (or, more precisely, it's pretty-printer) more semantic. The Idris community has done a great job in making their pretty-printer documents descriptive, so familiarizing yourself with the approach they take would be a good place to start (see David Christiansen's writings and talk on this matter[1,2]). There are some thoughts on how this can be done in GHC in #8809. In comment 3 I lay out what I believe is the smoothest road to achieving this. Namely we turn the pretty-printer into a free monad, allowing values of a particular type to be embedded within SDoc. In most of GHC this type would be a sum type which would accomodate expressions, types, source locations, etc. This change would allow us to defer the pretty-printing of this known set of primitive objects, allowing the interpreter to perform more sophisticated printing (e.g. coloring). This approach has the advantage of being relatively unintrusive while being useful for users outside of GHC (e.g. IDEs). Some time ago I started playing with an implementation of this idea in the typechecker and it seemed to work out fairly well in practice. Richard has proposed that perhaps instead of indexing the pretty-printer we should merely allow the injection of dynamically typed data. I'm not convinced that this is necessary and suspect that it would ultimately become quite brittle. The whole point here is that we only want to allow a small, closed universe of atoms into our errors; IMHO allowing a dynamically typed open universe is a road which will ultimately lead to pain. The cost of defining a small sum-type per compiler component a small price to pay, especially relative to the safety and clarity that it brings. You'll also want to familiarize yourself with the relevant parts of GHC. Namely, you'll want to read GHC's Outputable module as well as some of its common users (TcErrors is a good place to start). Let us know on the list if you have questions about procedure or general questions about GHC. For questions and proposals pertaining to the pretty-errors problem itself it would be best if we stayed on the appropriate tickets (#8809 is probably best). Cheers, - Ben [1] http://www.davidchristiansen.dk/2014/09/06/pretty-printing-idris/ [2] https://www.youtube.com/watch?v=m7BBCcIDXSg&list=PLnqUlCo055hVfNkQHP7z43r10yNo-mc7B&index=10