Is ace not checking for well-formedness at compile time?

ACE
#1

Question primarily for @sweaglesw – but I’m interested in input from all formalism mavens.

We have a grammar from the customization system that the LKB (correctly) won’t compile, because the feature LOCAL is ‘declared’ for two types. The offending type addendum statement looks like this:

head-adj-int-phrase :+ [ LOCAL.CAT.VAL [ SUBJ clist,
                                                                    COMPS clist ] ].

Where head-adj-int-phrase is a subtype of phrase and so should have at least SYNSEM (and not LOCAL) at the start of that path, if not HEAD-DTR.SYNSEM. (Either one of those would be well-formed, according to the feature geometry.)

I thought it might have to do with type addenda being processed separately, but if I add that constraint to the definition of head-adj-int-phrase it still happily compiles it.

Practically speaking, I think it’s problematic for ace not to catch this because it makes the grammar behavior unpredictable (is that constraint not recorded at all? just not effective?). For Grammar Matrix purposes, the immediate problem is that this means our regression testing system (which relies on ace) is missing some errors.

Is this in fact the desired behavior?

Thank you!

#2

I guess this situation arose from the (historical) situation that ACE was designed to run already well-formed grammars, rather than to be a development and debugging environment. But as usage has certainly progressed more in that direction over time, I think you’re right Emily that ACE should take the time to make this well-formedness check. It turns out it already would have caught it for an inappropriate feature introduced slightly deeper in the structure, just not at the top level of a type. I checked in a fix that now throws an error in this case (at least it does for a similar perversion I put into the ERG).

#3

Thank you, Woodley!

(Now we need to remember to update ace in the Matrix regression testing set up…)