on Fri Jan 27 2017, Chris Lattner <sabre-AT-nondot.org> wrote: > On Jan 26, 2017, at 11:15 AM, Dave Abrahams <[email protected]> wrote: >>>>> You should instead be able to directly bind subexpressions into local >>>>> variables. For example if you were trying to match something like >>>>> “42: Chris”, you should be able to use straw man syntax like this: >>>>> >>>>> case /(let id: \d+): (let name: \w+)/: print(id); print(name) > >>>> >>>> This is a good start, but inadequate for handling the kind of recursive >>>> grammars to which you want to generalize regexes, because you have to >>>> bind the same variable multiple times—often re-entrantly—during the same >>>> match. Actually the Kleene star (*) already has this basic problem, >>>> without the re-entrancy, but if you want to build real parsers, you need >>>> to do more than simply capture the last substring matched by each group. >>> >>> Please specify some more details about what the problem is, because >>> I’m not seeing it. Lots of existing regex implementations work with >>> "(…)*” patterns by binding to the last value. From my perspective, >>> this is pragmatic, useful, and proven. What is your specific concern? >> >> My specific concern is that merely capturing the last match is >> inadequate to many real parsing jobs. > > Sure, depending on how the grammar is defined, the compiler will know > when multiple matches are possible. If multiple matches are possible, > it is straight-forward to bind them into an array of results instead > of a single scalar result.
Even an array of subranges is inadequate for the general case; you actually need to capture the structure of the parse tree somehow. A really simple example would be case /((let id: \d+): (let name: \w+)?)+/ If you're just accumulating arrays, you lose the association of id to name as soon as someone decides to omit a name. Designing a system that is both super clean for the simple cases and powerful enough to handle more complex ones is going to be a fun project. -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
