> > 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 ([email protected]).
