[Top][All Lists]

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

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

From: Alex Rozenman
Subject: Re: Visibility and error messages (in named refs).
Date: Sat, 18 Jul 2009 00:00:15 +0300

> 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
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

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
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 ?

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).

reply via email to

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