You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When parsing of a field fails we currently select the next &synchronize field after the failing field. This means that if parsing fails on the last field of the unit marked &synchronize we cannot synchronize the unit at all. For such units one would need to write custom code or need to rely on e.g., list synchronization in the outer unit (this only works if the list element unit supports lookahead parsing). Such custom code look e.g., like this:
typeMessage=unit{a: b"X";b: b"F";# Field we would like to synchronize on.# Only used for synchronization.## - this field is only parsed if `self.b` was left unset: `if ( ! self?.b )`# - it is left unnamed so it does not store data on its own and is invisible# - if it parses data it stores its data in the original field: `self.b = $$`# - for this example we confirm unconditionally
: b"F" &synchronizeif( ! self?.b){self.b= $$;confirm;}};
This seems pretty subtle and makes me wonder whether we should change the way we pick the sync field.
If we started from scratch we could e.g., add the failing field the the list of fields consider and pick it if it is marked &synchronize. This would seem okay if errors causing synchronization are triggered independently of the data (gaps), but I believe could change semantics if synchronization is triggered by parser-internal code (e.g., failed &requires/overflows).
Alternatively we could introduce some new syntax or attribute so users need to explicitly mark such fields. The downside is that synchronization is already pretty subtle and unlikely to be fully covered with test data.
The text was updated successfully, but these errors were encountered:
When parsing of a field fails we currently select the next
&synchronize
field after the failing field. This means that if parsing fails on the last field of the unit marked&synchronize
we cannot synchronize the unit at all. For such units one would need to write custom code or need to rely on e.g., list synchronization in the outer unit (this only works if the list element unit supports lookahead parsing). Such custom code look e.g., like this:This seems pretty subtle and makes me wonder whether we should change the way we pick the sync field.
&synchronize
. This would seem okay if errors causing synchronization are triggered independently of the data (gaps), but I believe could change semantics if synchronization is triggered by parser-internal code (e.g., failed&requires
/overflows).The text was updated successfully, but these errors were encountered: