[logon] Mysterious problem with regexps in transfer rules

[Francis Bond]

G'day,

I'm glad you copied us all on this.

> i am impressed you do consider "~(de:_jed_q_rel|de:_fast[+]jed_q_rel)"
> concise :-).  but i am afraid the behaviour you report is `correct': at
> the start of transfer, for rule sets that were loaded with `:filter t',
> all input predicates are compared (as strings) against the `dictionary'
> of known INPUT predicates in that rule set.  that test, currently, does
> not take into account regular expressions (though it probably should).
>
> a way of working around this limitation could be to normalize predicate
> names in the first (GG accomoation) phase, and turn off filtering there
> (relatively few rules, not much of a loss).  this is what we have been
> doing for the NoEn LOGON system, so i never noticed the limitation :-).
>
> but for this to work, `_jed_q' and `_fast+jed_q' have to be considered
> equivalent, at least for transfer purposes (if you can translate both
> to `every', you might be willing to make that assumption).  otherwise,
> i see no alternative currently to breaking the rule into two.

So that was why the following (in my snug) doesn't match.

_d_ditch_ef := elision_mtr &
[ INPUT.RELS < [ PRED "~^ja:.*_d_" ] > ].

I need to move it into the non-filtered, post-transfer accommodation,
where it works.

If only I could commit (^_^).

-- 
Francis Bond <http://www2.nict.go.jp/x/x161/en/member/bond/>
NICT Language Infrastructure Group