[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Joel E. Denny
Subject: Re: Visibility and error messages (in named refs).
Date: Fri, 17 Jul 2009 23:08:17 -0400 (EDT)
User-agent: Alpine 1.00 (DEB 882 2007-12-20)

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 "$" has a "valid"
> resolution to a symbol "abc" and "invalid" resolution to "". 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.  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.

> Akim, when do you plan to release the 2.5 ? I'm currently very busy with my
> main job :), so it will take some time to update the code.

2.4.2 is still waiting for release.  I still have some cleanup to do with 
IELR(1) before 2.5.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]