> 
>   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

Reply via email to