Re: messages

[Arthur Schwarz <aschwarz1309 at verizon dot net>]

> > Thanks Dave;'
> > 
> > Acerbic comments below.
> 
> >>???Isn't that exactly what the
> compiler IS doing, as
> >> indicated by "candidates are ... "?
> > 
> >???I don't think so. [ ... ] A clear
> message that arg<n> is wrong I think
> >???is a better approach. 
> 
> ? But maybe arg<n> is right and it's something
> else that is wrong?
> 
> >>???It's not always possible for the
> compiler to do
> >> that.
> 

> 
> ? Nonono; I didn't mean to impugn anything you're
> doing, just trying to point
> out that it's not easy.? 

  Impugn away. I am terribly thin-skinned and the barbs wake me up.
> 

> Should the compiler always assume the function prototypes
> are correct and the
> choice of argument in the function call is wrong?? It
> occurs to me that that
> might be a good rule of thumb for system headers, but
> probably not for headers
> within the user's application.

  In this case the compiler detected an error and provided the correct 
  answer, but the answer lacked clarity for (really) a non-compiler
  writer. Before I say another word (let's see you deal with that one),
  if we look at the statement you have made then, I think, we are left
  nowhere. In particular your caveat on when my suggested reporting
  algorithm is inapplicable. To tear into the statement and bring you to
  a proper state of receptiveness, in absurdum you are saying that even
  though the compiler has detected an error and reported (what it thinks)
  is an error, the compiler is unable to determine that the error occurred
  in arg<n> - the nub of the suggested diagnostic message. I would say
  that given the existing compiler message, if the compiler can't draw this
  conclusion then the message is wrong. I would then say if the compiler
  is clever enough to provide a function template as a candidate for
  correcting the fault, then the compiler has all of the information
  needed to do a comparison, argument by argument, to determine which
  argument(s) are at fault, and can do this recursively (or iteratively
  if you're going to get picky) with all candidate function solutions. 
  I believe your caveat is then moot. The existing diagnostic message
  should be sufficient to allow the compiler to perform the analysis
  necessary to provide a more 'user friendly' (according to 'art') fault
  indication.

  I would go further by saying that (especially) any time the compiler
  is able to provide a candidate solution then the compiler should be
  able to analyze it's own solution against the fault to provide a more
  meaningful message.

  I assert that in those cases where compiler fault analysis fails, then
  under the stated conditions above the compiler has provided a faulty
  initial analysis of the problem and that is a 'bug'.

  Conventional wisdom, in my youth when the Sun shone brighter, was
  that error analysis was O(n**3), so I acknowledge that this is not
  easy. My argument is that the compiler has already done the analysis
  and just fails on the messaging. 

  I believe that it is possible to generalize the analysis tool and 
  avoid case-by-case special purpose code for each 'nasty'. If not 
  completely for all cases and forever, at least for enough cases to 
  make the effort worthwhile. My reasoning is that most semnatic errors 
  fall into broad categories, call it a 'failure in semantics', and
  these broad categories can be leveraged into a generic toolset. The
  pragmatic difficulty is that that existing diagnostic messages would
  have to be reworked into a standardized framework, and I view this
  as a hard problem. (Mind you, this is all without doing a lick of
  work or seeing a line of code - obviously I'm an expert.)

  Now, whew, I may be all wrong and if so, please be gentle.

art