Reference to called_subprogram is ambiguous

[joeseibel]

The syntax rule for called_subprogram in section 5.2 is ambiguous. In the following model, it is unclear if the reference should be to the subprogram implementation or to the subprogram access in the subprogram group subcomponent.

package conflict
public
  thread t
  end t;

  thread implementation t.i
    subcomponents
      a: subprogram group sub_group;
    calls
      sequence: {
        --Is this 'Component.Impl' or 'Subcomponent.Feature'?
        call: subprogram a.b;
      };
  end t.i;

  subprogram a
  end a;

  subprogram implementation a.b
  end a.b;

  subprogram group sub_group
    features
      b: provides subprogram access;
  end sub_group;
end conflict;

[jjhugues]

I understand a user might be confused, do you have any proposition for an update? Could we simply state that in case of a resolution conflict, the elements of a call sequence are resolved taking into accounts subcomponents? This could address this borderline issue.

[jjhugues]

Actually, there should be a general mechanism in places: references are first resolved in the local namespace (subcomponents here), then in the package namespace.

@lwrage what do you think?

[lwrage]

The difficulty is that a.b can be an identifier (of a component implementation) in the package namespace or a path consisting of two identifiers (subcomponent a followed by feature b in that subcomponent). The following rule is implemented in OSATE:

• If an element named a exists in the local component implementation namespace then a.b is interpreted as a path. To reference a component implementation with name a.b we must add the package name to it, i.e., conflict::a.b. For simplicity the decision should depend only on the first segment of the name (a), so the package name should also be required for a reference to a.c even if there is no feature named c in subcomponent a. (a.c without package should result in an error message that `c cannot be resolved.)

• Otherwise, if no element named a exists in the local namespace, a.b can only refer to a component implementation.

[jjhugues]

It seems we agree here. Where should such a rule be placed? I would imagine it could go in 5.2. I wonder how this discussion relates to the existing rules

(N3) If the called subprogram name is a subprogram classifier reference, its component type identifier or component implementation name must exist in the package namespace.

(N5) If the called subprogram name is a subprogram subcomponent reference, the subprogram subcomponent must exist in the component implementation containing the subprogram call declaration.

I would assume all we need is that N5 takes precedence over N3, is that also your understanding?

[jjhugues]

We need a specific section in the standard the provides a clear decision procedure for resolving names, e.g. component references, component classifiers for each namespace (package, subclauses)