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

[Alex Rozenman]

>
> Hi Alex.

Hi Joel,

Thank you for you answer.


> I cannot remember the definition for "misleading reference" that you
> eventually chose, and I haven't checked your code.  I suggested it should
> describe the case when there is exactly one "refers to" submessage and one
> or more "possibly meant" submessages.  I think all of your above
> discussion is a good argument that what I call a "misleading reference"
> should be a warning and not an error.


Your definition is correct. I would like to describe a terminology I used in
my code in order to give a background for further discussions.
I am calling to each possible resolution of a named reference a "variant".
The variant is "valid" when the resolution is completely legal; otherwise
the variant is "invalid". We've defined the following kinds of resolution
"issues" causing invalid variants to appear:

A. The symbol is not visible from the mid-rule action.
B. The symbol name contains dots or dashes. Also called "invalid
bracketing".
C. The symbol name is hidden by an explicit symbol reference.

In my current implementation, a reference is successfully resolved if and
only if there is exactly one valid variant and there is no invalid ones.
Otherwise, each valid variant is converted to "refers to" sub-message; each
invalid variant is converted to "possibly meant" sub-message and an error
(Invalid/Ambiguous/Misleading) is issued.

I agree, that in some cases "misleading reference" looks like a classic
warning situation. This is because no real resolution problem exists. There
are three main cases:

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.

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.

3. No valid references exist. "Invalid reference" error should be generated.
All invalid variants will be printed as sub-messages.

I feel the presented solution resolves most of my current concerns, and it
is not so far from the previous consensus. Could you please comment on it ?

P.S.
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.

-- 
Best regards,
Alex Rozenman (address@hidden).