> Attached is the the parser from the bash shell.
> It is interesting for several reasons
> 1) They have written a parser with all the usual control structures in only C
Cool
> 2) Its not unduly complicated
Good
> 3) They have written their own scanner
Hmmm. Sounds like maybe they ran into similar problems as NCO
and solved them by brute force.
> I've been following some of the problems connected with compiling
> the output of flex , to create our scanner
Yes, the problems also involve #including the scanner prototypes
in the parser.
> Couldn't we supply the compiled scanner in our distribution ?
Yes, we could brute force a scanner/parser like the bash folks did.
> i.e take the output of flex and do some manual "ANSI-ification" ?
As long as the manually recoding of the flex output
1. Works in all cases
2. Preserves the infomation and flexibility of the .l and .y files
Recoding in C might _improve_ the flexibility.
We just do not want to go backwards.
We don't know---it might be easiest/best to change flex upstream.
Or flex could be a world of its own and be hard to modify safely.
Personally, I like lexers and parsers so would prefer to see them
fixed. Still, we would have to accept a "recode in C" patch that
fixed all the problems they cause.
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Henry,
> Attached is the the parser from the bash shell.
> It is interesting for several reasons
> 1) They have written a parser with all the usual control structures in only C
Cool
> 2) Its not unduly complicated
Good
> 3) They have written their own scanner
Hmmm. Sounds like maybe they ran into similar problems as NCO
and solved them by brute force.
> I've been following some of the problems connected with compiling
> the output of flex , to create our scanner
Yes, the problems also involve #including the scanner prototypes
in the parser.
> Couldn't we supply the compiled scanner in our distribution ?
Yes, we could brute force a scanner/parser like the bash folks did.
> i.e take the output of flex and do some manual "ANSI-ification" ?
As long as the manually recoding of the flex output
1. Works in all cases
2. Preserves the infomation and flexibility of the .l and .y files
Recoding in C might _improve_ the flexibility.
We just do not want to go backwards.
We don't know---it might be easiest/best to change flex upstream.
Or flex could be a world of its own and be hard to modify safely.
Personally, I like lexers and parsers so would prefer to see them
fixed. Still, we would have to accept a "recode in C" patch that
fixed all the problems they cause.
Charlie