[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 "$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. 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.