on Wed Jan 25 2017, Chris Lattner <sabre-AT-nondot.org> wrote: > On Jan 25, 2017, at 7:32 PM, Dave Abrahams <[email protected]> wrote: >>> There are two important use cases for regex's: the literal case >>> (e.g. /aa+b*/) and the dynamically computed case. The former is >>> really what we’re talking about here, the latter should obviously be >>> handled with some sort of Regex type which can be formed from string >>> values or whatever. >> >> Ideally these patterns interoperate so that you can combine them. > > Yes, as I mentioned, the regex literal should form something of the > Regex type. Any API that takes a Regex would work with them.
But I think we want distinct types for some of these patterns so they can capture compile-time knowledge. That's why https://github.com/apple/swift/blob/master/test/Prototypes/PatternMatching.swift#L32 has a Pattern protocol. If you mean “type” in a looser sense that admits protocols, then we are aligned. >>> 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. > > > When you say “real” parsers, you’re implicitly insulting the “unreal" > parsers, No offense intended, truly. As a PL guy I assumed you'd know what I meant. As you know, regexes aren't sufficiently powerful to handle parsing languages like Swift, and even if they were, retaining only the last match of a capture would be insufficient to go from recognizing valid input (parsing) to semantic analysis. > without explaining what the “real” ones are, or why they matter. > Please provide specific use cases that would be harmed by this > approach., I'm talking about the kinds of parsers made possible by Perl 6 grammars, which can be recursive. Some examples: http://stackoverflow.com/questions/18561179/example-of-perl-6-grammar-with-operator-precedence-rules?answertab=active#tab-top >>> Unless we were willing to dramatically expand how patterns work, this >>> requires baking support into the language. >> >> I don't understand the "Unless" part of that sentence. It seems obvious >> that no expansion of how patterns work could make the above work without >> language changes. > > I’m not a believer in this approach, but someone could argue that we > should allow arbitrary user-defined syntactic expansion of the pattern > grammar, similar to how we allow syntactic expansion of the expression > grammar through operator definitions. This is what I meant by > “dramatically expanding” how patterns work. Oh, I see what you mean. You need to bake *something* into the language. That thing could either be regex support or it could be something more general, like a macro system that allowed beautiful regex support to be built in a library. Well, I'd love to have the latter, but wouldn't be willing to sacrifice much quality-of-user-experience with in order to get it. It would have to be roughly indistinguishable from the end-user's point-of-view. -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
