this Keyword

[dgp1130]

We need to add support for the this keyword. It should be set to the identifier or variable that was used in its closest containing block.

make {
    valid: this matches @filled; // this = make
}

This will be most useful when we implement #45 as it will apply to each element in the block header.

make, model, year {
    // valid tag applied to make / model / year with `this` set appropriately
    valid: this matches @filled;
}

[dgp1130]

Implemented this keyword as specified. this is bound to the parent Identifier block. So in the case above this would resolve to be equivalent to make. A couple notes on the changes.

this is not all that beneficial right now, since you can simply type the name of the identifier. It will primarily be useful when we add multiple owners to a block (#45).

Currently this resolves to the value of make not the make identifier itself. As a result, you cannot use the dot operator. this.valid will fail, which I'm ok with at the moment, since there isn't really a good reason to do so at this time. Such a feature would allow you to do something like:

make {
    enabled: hasCar;
    valid: this.enabled and this matches @filled;
}

which wouldn't really be a great idea anyways. The tags we have now don't work well in such situations so I'm not supporting it at this time. Later we will probably need it though. If we add support for a value tag, that would play well with others and make a lot of sense to use in other tags (#14), and once we scope variables within identifiers we might use this.@myVar to access them (#3) since they will be specific to each instance.

I also did not support this at the root level or within a BlockVariable. Both of these could make sense when we want to support the dot operator, but there is no clear value to assign to this when used without a dot, and since that is the only case we currently allow there's no sense in allowing them at this time.

If you use this in the wrong place it currently throws a ParsingError, though I'm wondering if we should have some other error for this kind of occurrence. This is really a semantic checking error, but there's no clear error type we can use for it.