Re: [Flex-devel] Suggestion for an alternate skeleton file

[Joe K. <kr...@ni...>]

Aaron Stone wrote:
> I would also like to see less mixing of skeleton-generated and 
> C-generated output. They're too deeply intertwingled right now, and I am 
> concerned that people with custom skeletons will end up relying on hacky 
> internal functions.
> 
> Aaron
...
OK, I did some more work on my modified skeleton. Now, the only code 
written directly from C are the data tables. The only way to reduce 
C-generated code further is to define M4 macros for just the raw table 
data, i.e. "{1,2,3...}" and let the skeleton declare their variable 
names as well. Actually, that would probably be a good idea, because it 
would allow for skeletons written in something other than C.

This makes it impossible to use the old skeleton, but it still is 
possible to follow the old skeleton's order of putting section 1 code in 
the middle of header parts, if people want to avoid incompatibilities.

I wanted to see how traditional lex works, and found that Sun has 
released their lex source in "The Heirloom Development Tools" on 
sourceforge. It is essentially the basic traditional lex, and still has 
an output option for ratfor source-code. It does have an extension to 
parse wchar_t input, which might be good to add to flex.

Sun's lex actually puts user code from section 1 near the end of the 
"header" stuff, so you would have to either use CPP options on the 
command line to set some of the options like YYLMAX, or undefine then 
redefine them in the user code. I think most flex users depend on being 
able to set those macros, with few expectations for predefined types.

One exception that I found in a few places in test code is to declare 
variables of type "yyscan_t" in the reentrant scanner. They can instead 
just be declared "void*", but it also works to read in the output 
header, so you could do something like this:

%option header="scanner.h"
%top{
#define YYLMAX 256
}
%{
#include "scanner.h"
yyscan_t my_scanner;
%}

This will put YYLMAX into the header so it will be valid for external 
code, and still allows section 1 user code to access header typedefs, etc.

If users don't want to be required to write out a header file, flex 
could also support a new %bottom{} code tag that allows user-code to be 
inserted after the header definitions. Or, just define a %header command 
to indicates "insert header sutff here", so that all subsequent section 
1 code comes after the header block.

Joe Krahn