Re: Visibility and error messages (in named refs).

[Akim Demaille]

Le 18 juil. 09 à 05:08, Joel E. Denny a écrit :

> On Sat, 18 Jul 2009, Alex Rozenman wrote:
>
> > 1. More than one valid variant present. Here, an "Ambiguous  
> > reference" error
> > should be issued, we may even consider not to print invalid  
> > variants as
> > sub-messages.
>
> I think they should stay because one of them might be what the user  
> really
> means.  It will be helpful if the valid variants are printed first.
>
> > 2. There is exactly one valid variant. No resolution problem  
> > exists, but
> > more detailed analysis gives the following:
> > 2.1. When an invalid variant of type "A" (mid-rule visibility)  
> > presents - a
> > classic warning situation holds.
> > 2.2. When an invalid variant of type "B" (invalid bracketing)  
> > presents -
> > looks like an error, for example a reference "$abc.xxx" has a "valid"
> > resolution to a symbol "abc" and "invalid" resolution to "abc.xxx".  
> > Too
> > ambiguous to be a warning.
> > 2.3. For invalid references of type "C" (hidden). Here I have  
> > strong feeling
> > we must not to complain at all. This will resolve issues from my  
> > previous
> > mail.
> > The final decision (error or warning) may be found as a "worst  
> > case" on all
> > existing invalid variants.
>
> I think the main confusion for the user will be understanding why a
> reference he wrote is rejected when it is perfectly valid and  
> unambiguous.
> That's why I had suggested that Bison always report "misleading  
> reference"
> in these cases.

I concur.  The richer the messages, the better.

> Based on your previous email, that's why I'm also now
> suggesting that a misleading reference always be just a warning.   
> Bison is
> just telling the user that something *may* be wrong.  I think it's
> confusing and not helpful to the user if Bison makes it an error  
> only in
> some subcases.  I also do not think we should drop the "hidden"  
> warnings.
>
> Maybe Akim can give his opinions on both of these issues too.

In my opinion, warnings are basically corner cases in specifications.   
Most warnings in GCC should be stated as errors in C itself, but  
making them errors would prevent GCC from being a compliant C  
compiler, so it has to be a warning, not an error.  Yet so many  
patterns should have been errors from the beginning.

So it is my religion that when you are totally free, because you're  
designing a new feature and you have no standard or backward  
compatibility to obey to, warnings should be errors.  It helps  
programmers converge to a single form of writing, and therefore it  
helps escaping for local dialects (I think that the Perl motto  
TIMTOWTDI is wrong).

In Bison, for instance, I would have preferred that ';' be mandatory,  
and that %expect 0 be the default.

Errors are very painful when obscure and hard to fix, but in the  
current case, a lot of effort was put in the quality of the messages,  
and I foresee that the documentation will be equally good (actually,  
the documentation is currently being polished in your exchanges!).

So I vote for errors everywhere when we can.  But that's just my  
opinion.