A.5.4 Translation Guidelines
- Don’t bother supporting non-reentrant parser generation.
The interface of original Lex with all those globals hanging out
needs to be supported in C for backwards compatibility, but
there is no need to carry it forward.
- The “one exception” to target-syntax independence hinted at earlier
is some C code spliced into the skeleton when table serialization is
enabled. This option is thus available only with the C back end; you
need not bother supporting it in yours.
- If your target language has an object system, you probably want your
back end to generate a class named by default FlexLexer (as the
C++ back end does) with all of the controls and query functions as
methods. As in C++,
%option yyclass should modify the
class name. If your target language has a module system, the
-P option (which in C/C++ sets a common prefix on exposed entry
points) can be pressed into service to set the module name.
The following assumptions in the code might trip you up and
require fixes outside a back end.
- As previously noted, the item separator in data initializers is a
comma. Flex does not assume that a trailing comma after the last
initializer element is legal, though it is legal in C/C++.
- Either case arms can be stacked as in C; that is, there is
an implicit fallthrough if the case arm has no code. Or,
there is an explicit fallthrough keyword that enables this,
as in Go.
By putting a yyterminate() call in the expansion of
M4_HOOK_EOF_STATE_CASE_FALLTHROUGH and defining an empty
M4_HOOK_EOF_STATE_CASE_TERMINATE macro, you could handle
languages like Pascal.