In parserSample02, I illustrate an issue that will be difficult to
resolve: each path through the parse tree could result in a
different mapping between HyPer4's consolidated extracted.data
field and the source .p4's header fields.  Thus has several
implications: 1) tset_control_state_nextbits is insufficient as it
incorrectly assumes that of all paths leading to a given parse state,
those paths that incur the same bit extraction requirement prior to
entering the parse state may all be represented by this value (the
number of bits that have been extracted).  This is incorrect because
for some paths the number may represent explicit 'extract'
statements while for other paths the number may include (or
completely consist of) support for handling 'current' expressions
in preceding parse states' return statements.  2) We will have to
store each possible extracted.data -> source.p4 field mapping,
indexed by the final path taken through the parse tree from start
to ingress, and for each possible path incurring a different
mapping, we will have to supply different match table entries,
meaning the path ID will have to be added to the match fields,
resulting in a multiplication of the memory required for emulating
source.p4 table entries.  3) Back in the parse tree compilation,
we will have to deal with implications for issuing the correct
tset_inspect_XX_XX entries, where different paths may require
different entries and even different tset_inspect_XX_XX tables
(if the different mappings mean the select expression, in the
parse state's return statement, has to look at different
sets of bytes crossing tset_inspect_XX_XX boundaries).