I do recognize the value of such a feature, and I would like to add features that make programming in Ragel a better experience, however, the feature that you describe is just not possible in Ragel. A mapping from the current input character and current state to some thread context is beyond the limits of the DFA execution model, to which the Ragel compiler is confined.
-Adrian Devin Bayer wrote: > Hi Adrian: > > After our discussion I think I can express this more clearly. > Ragel works well to recognize my grammar but doesn't expose the > primitive constructs required to determine context, which is > important for extracting values from the input stream. > > Workarounds are available but they require an unmaintainable > amount of copy & pasting and are less efficient, since they use > backtracking or duplication of all shared states. A macro > language would improve the situation, but it would only hide the > complexity. > > My proposal would make ragel easier to use. Constructs like > matching text before ']]>', which the manual admits cannot be > expressed using ragel's RE operators, would become simpler. > > Each state is in one or more threads. It doesn't require any > runtime overhead to make this information available and I don't > see any major hurdles with keeping track of the information in > the compiler. It doesn't require action rewriting, just building > one more piece of data. > > So my concern is not about implementation, but that you don't > recognize the value of this feature. > > Thanks, > Devin > > _______________________________________________ > ragel-users mailing list > [email protected] > http://www.complang.org/mailman/listinfo/ragel-users > _______________________________________________ ragel-users mailing list [email protected] http://www.complang.org/mailman/listinfo/ragel-users
