[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Alternative algorithm to restrict use of data/string in patterns.
This looks good. A couple of minor comments: > To capture the tri-state "element"/"text"/"anyString", I'd like to > introduce "fpdsType". > > One important operation over fpdsType is "OR" operation. That is, > fpdsType||fpdsType -> fpdsType. > > This operation is commutative: fpds1|fpds2 == fpds2|fpds1. > > Definition of OR of fpdsType > ---------------------------- > X|Y == Y|X > X|X == X > > "text"|X == "text" > "anyString"|"element" == "anyString" > > If pattern p can start with transition "element"(X) and "text"(Y), then > what matters is "text"(X|Y). Or operation is used to extract what > matters. If we consider the three states to be ordered: element < anyString < text Then the "OR" operation is just max. Right? > So to correctly calculate what kind of transitions can be possible, > _calcFPDS has to receive fpdsType that succeeds pattern p. Would another way to do it be to have calcFPDS just take s single argument and for group to do if (p is <group>p1 p2</group>) { if (isNullable(p1)) return calcFPDS(p1) || calcFPDS(p2); else return calcFPDS(p1); } where isNullable(p) checks whether p can match the empty sequence (and any atts)? (I'm not saying this is easier. I just want to check my understanding.) James
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC