Multi-clause definitions are only linked once

[mpickering]

If a file contains the following definition for go, only the first occurence of go is linked. The second occurrence is not linked.

go 0 = ()
go 1 = ()

[robinp]

At least for Kythe, we can only define a single binding site. When we have

go :: Int -> ()
go 0 = ()
go 1 = ()

then the first implementing clause is used as binding site, and the name in the type declaration ref/doc-s it. Just to describe current state.

+@creachadair How would we mark up alternative clauses? Emitting a ref from them would pollute the backreferences of the binding.

Unless there's a special Kythe edge/support for this, I think leaving them unreferenced is the least surprising thing we can do, as the clauses are expected to be grouped and near the main one anyway. What do you think?

[creachadair]

You can define as many binding sites as you like, but it's reasonable to choose not to if you find the xrefs confusing that way. Schematically it seems like the pattern matches should be bindings, since they define behaviour for the type -- but I can see the argument in the other way too.

+@zrlk might have some better ideas. One possibility is to treat them as references with a separate kind (e.g., perhaps ref/alternative say), which would let them show up in the xrefs (which I'd argue they probably should) but in a distinguishable way.

[robinp]

Is there a semantics expected by tooling for multiple binding sites? Are they complementary, or are they ambiguous?

If having multiple, complementary binding sites is the 'right' way, then no point in diverging from that. Especially inventing new reference kinds, which is just additional burden for tools (ref/alternative doesn't exist yet I guess).

[creachadair]

Is there a semantics expected by tooling for multiple binding sites?

In our experience, there is no consistent pattern that all (or even most) tools expect. Some UIs (notably Eclipse) have a fairly strong baked-in assumption that definition sites are unique (one and only one), which leads to odd results when there are none (e.g., an implicit constructor call) or many (e.g., a C++ class or function with multiple forward declarations or prototypes). As a rule I think that is a poor assumption, and better UIs will give the user some affordance to choose when there are multiple options.

As far as indexing, we've generally tried to err on the side of completeness except where there is some pragmatic constraint (notably: we collapse xrefs for template instantiations for storage capacity and processing time limitations). But I'd say there's always a judgement call for the indexer—and sometimes the "true" results (as specified by the language) don't align with programmers' intuitions about how things "should" work.

So I'd say there isn't a definitive answer. The informal litmus test we fall back on is "the xrefs of a thing should tell you all the places that have to be updated if you change that thing". From that perspective, it'd probably make sense to include the xrefs of all the patterns as xrefs of the underlying type. Depending how much information the compiler gives you, you could slice that more finely, usually at a cost of some additional data.

ref/alternative doesn't exist yet I guess

That's correct. But if there's a motivating case for it, adding it wouldn't be (too) hard. Part of the point of the "qualified" ref kinds is that a UI can ignore the distinctions ("fetch ALL the refs!") or use them to subcategorize.