# Future Directions

> Spirit is an on-going development. It is designed as a parser for the common programmer. Daily programming chores increasingly necessitate parsing. Most of the time, sometimes without realizing it, we are coding a parser by hand. Many stay away from full blown applications such as YACC because of the jumbo-jet syndrome. Spirit's intent is to be a library-based parser in between regex and a full-blown parser. Further developments will focus on this prime motivation.

> Thanks to the extensible nature of Spirit, version 1.2 already implements most of the features previously sought for and more. So far, version 1.2 developments more or less focused on the dynamic aspect of Spirit which without doubt is one of its fortes. Development of version 1.3 on the other hand will attempt to focus more on (but will not be limited to) the static aspects of Spirit. Here are some of the features we can expect to see.

> > Closures. Immediately after V1.2 is released, the capability of the reference wrappers will be boosted to allow access to true local parser variables. Parsers will have access to local variables on the hardware stack. Rules are invoked in a tree like traversal as parsing proceeds. The start rule first, then on to inner rules until we reach the leaves (terminals). This implies that outer rules, starting from the start rule, have the longest lifetimes, thus, inner production rules will be able to access the stack frames of outer production rules. Closures will significantly ease the burden of semantic actions in the generation of output such as ASTs.

> > Multiple scopes. C++ is a great model for the complexity of scoping that perhaps has no parallel in any other language. There are classes and inheritance, private, protected and public access restrictions, friends, namespaces, using declarations, using directives, Koenig lookup and more. The symbol table functionality we have now will be the basis of a complete facility that will attempt to model this.

> > A full-blown lexer. Borrowing from the ideas set forth by the scanner, we shall have a full lexical analyzer using advanced functional-metaprogramming techniques. We can expect the lexer to be highly efficient. The lexer will be totally static, relying solely on compile-time data structures to implement a DFA from statically defined regular expressions.

> > The lexer will be fully deterministic; requiring only a single token (character) lookahead. The final code generated by the template meta-program will be extremely tight and fast switch case functions. Like before, there will be seamless integration between the lexer and the rest of the framework. The lexer will be optional. You don't have to use it and you don't pay for it if it's not in use. Most importantly, ease of use will be a prime concern.

> > Deterministic parsers. Using the same template metaprogramming techniques, a strict LL(1) parser sub-framework (under namespace spirit::LL1) is being planned. This can be used in places where we can totally eliminate backtracking and ambiguity. Integration and interoperability with the current backtracking parsers will be a prime concern.

> > More predefined parsers. parsers for comments, hex/octal/binary numbers, delimited lists, strings, character literals, identifiers, and other commonly used utilities.

> > More sample files, tutorials and real world examples.

> > XML generation of debugging information. This will allow us to view the parse traversal using an external XML editor/viewer. This will be the basis of a powerful parser debugger.

#