Support for colors in ghci

[Ben Gamari]

Никита Нежевский <empthynickname at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160323/ceab89f5/attachment.sig>