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

**URL:** <https://delphinqa.ling.washington.edu/t/is-ace-not-checking-for-well-formedness-at-compile-time/913>\
**Category:** ACE\
**Created:** [April 24, 2023, 9:58pm UTC](https://delphinqa.ling.washington.edu/t/is-ace-not-checking-for-well-formedness-at-compile-time/913 "2023-04-24T21:58:23Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![ebender](https://delphinqa.ling.washington.edu/letter_avatar_proxy/v4/letter/e/34f0e0/32.png) [@ebender](https://delphinqa.ling.washington.edu/u/ebender)\
**Post date:** [April 24, 2023, 9:58pm UTC](https://delphinqa.ling.washington.edu/t/is-ace-not-checking-for-well-formedness-at-compile-time/913/1 "2023-04-24T21:58:23Z")

</div>

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:

```auto
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!

---

<div class="post-metadata">

**Author:** ![sweaglesw](https://delphinqa.ling.washington.edu/letter_avatar_proxy/v4/letter/s/c67d28/32.png) [@sweaglesw](https://delphinqa.ling.washington.edu/u/sweaglesw)\
**Post date:** [May 19, 2023, 4:31pm UTC](https://delphinqa.ling.washington.edu/t/is-ace-not-checking-for-well-formedness-at-compile-time/913/2 "2023-05-19T16:31:18Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![ebender](https://delphinqa.ling.washington.edu/letter_avatar_proxy/v4/letter/e/34f0e0/32.png) [@ebender](https://delphinqa.ling.washington.edu/u/ebender)\
**Post date:** [May 19, 2023, 5:49pm UTC](https://delphinqa.ling.washington.edu/t/is-ace-not-checking-for-well-formedness-at-compile-time/913/3 "2023-05-19T17:49:32Z")

</div>

Thank you, Woodley!

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