> > So I guess, yes, I'm asking Arthur to suggest rules > of relevance that would > enable the compiler to decide what kind of user error is > implied by a given > syntax error. > > cheers, > DaveK > You're asking for a lot. I've never been accused of being smart (the quip being, 'I've always been admired for it'.)
In one of my previous e-mails I mentioned a criteria of selection. Do nothing. The compiler already provides adequate analysis. What is missing is an analysis of the analysis to produce more 'user friendly' diagnostic messages. What I think we get is a compiler writers' version of a suitable diagnostic. The messages seem to indicate what a compiler writer needs to determine what is at fault, and perhaps with sufficient detail to determine that the fault (message) is at fault. What I suggested is that a separate subsystem be created to extract 'meaning' from the compiler writers' message, and present a user version of the message. I do not believe that the compiler writers' messaging should be removed - it is useful for compiler writers - just that it be optioned-out for the user. Taking the approach that the existing messages are satisfactory the dialog on relevance moves a tad to the right. The issue becomes one of comparing the detailed messaging to the textual fault. In the original case, one of pointing out that arg<n> is at error because is doesn't match known overloads (and some other name for templates I suppose). In that way, the user is told that arg<n> is at fault rather than having to discover that fact. The error analysis subsystem, in the case of not finding a suitable overloaded function, is one of identifying user provided arguments again found potential overload. Essentially something like: function() overload() arg<1> arg<1> arg2<> arg<2> o o o o o o o o o arg<k> arg<k> and finding which arguments fail. There may be more than one answer and some heuristic is needed to determine which or how many messages to provide for a given failure. To throw an answer of relevancy on the mud-pile, suppose we choose to message the cases where there is the least number of failures. Using this heuristic for this failure the overloads which contain only 1 argument which fails takes precedence over overloads with 2 argument failures and so on. This is a mud-pile heuristic, sufficient to start a discussion but probably not suitable for ending one. In most cases I would find it a daunting task to provide an algorithm to decide which error, among many, is the 'most important' and should be addressed while the others are left unaddressed. The easy answer is to provide an option which details the 'depth' of fault diagnostics to provide - avoiding the problem of finding the best diagnostic but, again, introducing the notion of fault ranking. I also think that for some cases it might be possible to actually establish the 'best' wrong answer. Again, ideas are cheap, work is hard. In one of my previous e-mails I suggested that it might be possible to characterize semantic errors and to standardize existing diagnostic messaging to fit the characterization. The process for many 'user friendly' messages then becomes one of analysis of the cause of faults against the detailed messaging to extract some user oriented messaging. I said that the pragmatics of the approach may be hard. Now I know that this is all hand-waving and random bits of wisdom. There is a wide area for investigation, discussion, and debate. Now that I've ended up confusing myself art