primitives
This uber combinator exists because we (currently) do quite different things for parsing and unparsing.
Refactored primitives that use expressions to put expression evaluation in one place.
Refactored primitives that use expressions to put expression evaluation in one place. On this base (for the primitive), and a corresponding parser base class for the actual evaluation.
That fixed a bug where a SDE wasn't being reported until the parser was run that could have been reported at compilation time.
Anything being computed that involves the dsom or grammar objects or attributes of them, should be done in the grammar primitives, and NOT in the parser. This is important to insure errors are captured at compilation time and reported on relevant objects.
A SequenceChild is exactly that, a child Term of a Sequence
A SequenceChild is exactly that, a child Term of a Sequence
These objects are part of the Gram object hierarchy. They represent the use of a Term in a context. They are objects that belong to (are owned by exactly one) the enclosing sequence, are part of it, and so it is reasonable for a SequenceChild to have a backpointer to the enclosing Sequence object.
This allows the Term object that provides the definition of the SequenceChild to be shared/reused, in principle without having a backpointer to the enclosing Sequence. That allows sharing, and removes lots of duplication/copying in the schema compiler data strucures.
Eventually things like alignment calculations should move from Terms to these objects. That is, those calculations should not be done on the DSOM objects, but on these SequenceChild objects in the Gram objects.
Base class for all kinds of sequences.
For stubbing out primitives that are placeholders
The purpose of this checker is to examine a regex and look for a situation one can run into if you try to use the free-form regex syntax, which allows a regex to be spread out over multiple lines with comments intersperced.
The purpose of this checker is to examine a regex and look for a situation one can run into if you try to use the free-form regex syntax, which allows a regex to be spread out over multiple lines with comments intersperced.
Trouble is, such regex must be wrapped with CDATA bracketing, otherwise it will all end up on one line, and the comments are from a # to end of line, so this breaks the regex, and very commonly the regex will begin with a comment and so the effective regex is one that matches anything at all, but is completely legal as a regex, which makes it very very painful to debug.
This uber combinator exists because we (currently) do quite different things for parsing and unparsing.
It lets us introduce the new unparser capabilities for the situations where they are truly necessary, and keep using the older style stuff for the situations where it works already.
Ultimately, some big refactoring is needed here though, or this is going to get very complicated to reason about, as if it isn't already :-), well this is going to make it worse.