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