Here are the design principles I've followed
- no object orientation for all parsing functions
- no symbol table manipulation
- reuse the same functions for all "self-identifying structures " (structured fields, triplets, ptx sequences)
- use yaml for the AFP syntax and all config files
The main work of the library is to translate the AFP between different data strctures, and eventualy to and from a bytestring.
The "data structures" (loosely speaking) of the library, are
The AFP bytestring
"$struct": a hash containing all the details of a Structured Field, Triplet or PTX Coding Sequence.
"$easy": only needed when we translate in the direction YAML to $pretty to $struct. The idea is that if you write the YAML of a structured field, you shouldn't give all the fields: the missing fields will be filled by default values.
"$pretty": a ref to an array that rearranges some data of a "struct". The rationale is that when YAML::Dump dumps a $struct, you cannot predict the order of the output (because hashes are not ordered).
YAML documents
Sometimes the semantics of a SF depends on the context: on values found in preceding Structured Fields. There are even cases where the syntax of a Structured Field depends on another SF: for example in the SF FNI (Font Index) and some other SF's, the length of the repeating group depends on a value in another Structured Field.
A more common case is the encoding of TRNDATA: the value of the current LID is "modal" (~like a global value) and its mapping to the actual codepage depends on values read in MCF* Structured Fields.
To solve these problems, the library allows you to assign a mapping function to a structured field; the mapping function will be executed after parsing the SF, but before applying the other handlers. Some "mapper functions" are in the library. You can enable the mappings when you create the parser, by specify the option Parser->new(apply_mapping => 1);