Description
It would be convenient to define parsers outside of TAG for use within it. This would allow users to easily adjust the behavior of a parser for an evolving format (ex. https://github.com/lum-ai/odinson).
Plan
-
To support this we'd need to discuss how a custom parser should be registered with TAG. Perhaps it should be passed in the config object (ex.
{"odin": mycustomParseFunction}
, wheremycustomParseFunction
returnsdata
.) -
The
Parser
constructor and helper functions inparse/parse.js
will also need to be modified to work over a dynamic set of parsers instead of (or in addition to) the statically-defined ones TAG currently supports.
The parser system as currently written is based on classes, and Parser
reads directly from each parser object's .data
(e.g., from this.odin.data
in the parseOdin()
function) property. We may want to consider switching to a purely functional approach to support custom parsers.