Re: [Flex-devel] Skeleton question
flex is a tool for generating scanners
Brought to you by:
wlestes
From: Will E. <wes...@gm...> - 2015-12-07 13:40:26
|
On Sunday, 6 December 2015, 9:42 pm -0500, Mighty Jo <mig...@gm...> wrote: > Fair enough. I'll still try to persuade you :-) > > Emitting code via two mechanisms is the one big thing standing in the way > of supporting scanner generation in more than one language. It pretty much > works right now for C/C++ because they're so similar. Still, the header > option doesn't work for C++ because of hard coded C emissions. If we're > keeping the C++ generator, those have to be suppressed somehow. > > In reading the code, I see that very similar conditional emissions are made > both from C and m4. The benefit of moving (almost) all emission to m4 is it > simplifies supporting scanner skeletons for different languages > independently. (With the obvious downside that you have two sources to > maintain, but that may be a disguised blessing in this case.) > > End of persuasion. Done actually. ;) If it lets us do more and would be easier, then yeah, that's a win. We should explore your "almost" though. And see what it would take to turn it into an "all". > > At any rate, I want to experiment with a new generator condition with the > semantic, "for header only." The existing %ok-for-header doesn't suffice > because the block it guards also gets emitted into the non-header file. > Should such a thing be m4-only or also have a %control-code form? Given the above, it should be m4 only. I.e. the migration pattern is "new things done the new way and move the old things into the new way when that's convenient". > > -Joe > On Dec 5, 2015 5:06 AM, "Will Estes" <wes...@gm...> wrote: > > > I think I prefer that we do things in C where we can. > > > > On Friday, 4 December 2015, 9:26 pm -0500, Mighty Jo <mig...@gm...> > > wrote: > > > > > Good evening folks, > > > > > > I've been working on overhauling the scanner generation code to move all > > of > > > the target language emissions into the skeleton. I don't know yet > > whether > > > the state tables can be generalized this way, but I've identified a few > > > dozen sites where C code emissions can be converted to setting m4 > > > definitions and performing checks in the skeleton. > > > > > > In the skeleton itself I've found similar checks coded two ways. One is > > > the collection of m4_check_something macros. The other is the set of > > > %check_something statements which are translated into m4 macro calls by > > > skelout(). > > > > > > Which style do you prefer going forward? I won't remove either of them > > in > > > my work, but I have to augment at least one of them and I'd like to know > > > the community's thoughts. > > > > > > -Joe > > > > > > > ------------------------------------------------------------------------------ > > > Go from Idea to Many App Stores Faster with Intel(R) XDK > > > Give your users amazing mobile app experiences with Intel(R) XDK. > > > Use one codebase in this all-in-one HTML5 development environment. > > > Design, debug & build mobile apps & 2D/3D high-impact games for multiple > > OSs. > > > http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 > > > > > _______________________________________________ > > > Flex-devel mailing list > > > Fle...@li... > > > https://lists.sourceforge.net/lists/listinfo/flex-devel > > > > > > -- > > Will Estes > > Flex Project Maintainer > > wes...@gm... > > https://github.com/westes/flex > > > ------------------------------------------------------------------------------ > Go from Idea to Many App Stores Faster with Intel(R) XDK > Give your users amazing mobile app experiences with Intel(R) XDK. > Use one codebase in this all-in-one HTML5 development environment. > Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. > http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 > _______________________________________________ > Flex-devel mailing list > Fle...@li... > https://lists.sourceforge.net/lists/listinfo/flex-devel -- Will Estes wes...@gm... |