Support Kythe metadata to crosslink Haskell code and protos about proto-lens HOT 3 OPEN

It sounds reasonable to annotate the typeclass instances of HasLens' that proto-lens generates. For example: https://github.com/google/proto-lens/blob/master/proto-lens/src/Proto/Google/Protobuf/Descriptor.hs#L59

To control that this happens only in haskell-indexer mode: like the C++ backend, you can pass extra colon-separate arguments to --haskell_out=BLAH when invoking protoc, and just teach protoc-gen-haskell to parse them correctly. As an example in proto-lens: https://github.com/google/proto-lens/blob/master/bootstrap.hs#L30

The hardest part, I think, will be getting the locations of individual declarations within the Haskell program...you need to tie proto names to specific lines/columns within the *.hs file, right? I'm not sure how to accomplish that with Text.PrettyPrint (which is what haskell-src-exts uses)...

One option is to generate the Haskell file, then parse it again with haskell-src-exts and walk the syntax tree (annotated with SrcSpanInfo, I think) to find all declarations that, for example, look like instance HasLens' .... That approach seems a little fragile, though.

from proto-lens.

from proto-lens.

On in-source annotation vs side-channel file: If we would do in-source annotation, the annotations would likely need to be there regardless of Kythe running or not - otherwise the source code would be different when indexed by Kythe and when users looking at them, leading to differences in source locations etc.

The C++ proto code generator avoids normal compile bloat by guarding the include of the metadata source with a kythe flag. But for Haskell this would mean unnecessary CPP usage.

Other generators seem to rely on some kind of side-channel piping, connecting the above mentioned proto info with some qualified names. If we wanted to go this route, we could emit a stable qualified name, for example name of generated module + instance name, that the indexer could recognize uniquely.

from proto-lens.