Hi Alex. On Sat, 5 Sep 2009, Alex Rozenman wrote:
> On Sat, Sep 5, 2009 at 10:14 PM, Joel E. Denny <[email protected]> wrote: > > > to "unresolved reference" > > For the case where there are no valid referents, I think Bison should > > consistently report "invalid reference". I don't see how "unresolved > > reference" describes the subcase of no suggestions any better. A > > suggestion is not a resolution, in my view. > > > > I have strong feeling that we must pay user's attention to the fact that the > reference is not just "invalid" which is very common word, but it is invalid > because it has an undeclared component. I don't see how "undeclared component" describes the distinction we're discussing. The distinction is whether Bison was able to come up with suggestions for what the user might have meant. Regardless of whether there are suggestions, the symbol name component of the reference is "not declared in this scope". > For example, in gcc we can see: > > int func() { return a + 1; } > func.cpp:4: error: ‘a’ was not declared in this scope > > Suppose that instead of this gcc would print: > func.cpp:4: error: invalid reference: ‘a’. > I think this messages is unacceptable common, and allows tens of possible > reasons. Certainly the second is worse for C++ because the term "reference" has a very different meaning in C++. The first is slightly misleading because it implies a scoping issue when, in fact, "a" may never have been declared anywhere. But your gcc analogy doesn't show why "invalid reference" is the wrong message only when Bison has no suggestions to give. If you dislike the phrase "invalid reference", then let's discuss an alternative but use it consistently regardless of whether Bison has suggestions. Maybe the trouble is that you really just want to tell the user what symbol name Bison extracted from the reference so that he knows what Bison was looking for and didn't find. Maybe that doesn't seem as necessary to you when Bison has suggestions. But I think the user may then be misled by the inconsistency. So, to satisfy us both, I'd be fine with: test.y:24.36-41: invalid reference: $cond1 test.y:24.36-41: symbol not found in production: cond1 test.y:26.43-53: invalid reference: $stmt.field test.y:24.36-41: symbol not found in production: stmt test.y:25.35-38: possibly meant: $then.field, hiding $stmt.field at $4 In the cases of ambiguous references and misleading references, the existing "refers to" submessages can replace the "symbol not found" message as they are probably sufficient to indicate what symbol was sought and, in those cases, actually found.
