8.2 Labels and scope

• returning to the np_agr macro from Section 8.1, we note a problem with this query:

  > A = /np_agr[] [pos = "VVFIN"] /np_agr[];

  when the second NP does not contain any adjectives but the first does, the b label will still point to an adjective in the first NP; consequently, the agreement check may fail even if both NPs are really valid

• in order to solve this problem, the two NPs should use different labels; for his purpose, every macro has an implicit $$ argument, which is set to a unique value for each interpolation of the macro; in this way, we can construct unique labels for each NP:

  DEFINE MACRO np_agr(0) 
    $$_a:[pos="ART"] 
    $$_b:[pos="ADJA"]*
    $$_c:[pos="NN"]
    [: ambiguity(/unify[agr, $$_a,$$_b,$$_c]) >= 1 :]
  ;
  

  a comparison with the previous results shows that this version of the /np_agr[] macro finds additional matches that were incorrectly rejected by the first implementation

  > B = /np_agr[] [pos = "VVFIN"] /np_agr[];
> diff B A;

• however, the problem still persists in queries where the macro is interpolated only once, but may be matched multiple times

  > A = ( /np_agr[] ){3};

  here, a solution is only possible when the scope of labels can be limited to the body of the macro in which they are defined; i.e. the labels must be reset to undefined values at the end of the macro block; this can be achieved with the built-in /undef[] macro, which resets the labels passed as arguments and returns a true value

  DEFINE MACRO np_agr(0) 
    a:[pos="ART"] 
    b:[pos="ADJA"]*
    c:[pos="NN"]
    [: ambiguity(/unify[agr, a,b,c]) >= 1 :]
    [: /undef[a,b,c] :]
  ;
  

  > B = ( /np_agr[] ){3};
> diff B A;

• however, it may still be wise to construct unique label names (either in the form np_agr_a etc., or with the implicit $$ argument) in order to avoid conflicts with labels defined in other macros or in the top-level query