On Jan 25, 2017, at 7:32 PM, Dave Abrahams <dabrah...@apple.com> 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. >> 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? When you say “real” parsers, you’re implicitly insulting the “unreal" parsers, without explaining what the “real” ones are, or why they matter. Please provide specific use cases that would be harmed by this approach., >> 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. >> Anyway, to summarize, I think that getting regex’s into the language >> is really important and expect them to be widely used. As such, I >> think it is worth burning compiler/language complexity to make them be >> truly great in Swift. > > Thanks for this post, Chris; it clarifies beautifully the reasons that > we're not trying to tackle regexes right away. … and hopefully why it is important to consider them first as a language feature, not a crazy DSL you’d try to build in the library through a ton of overloaded operators. -Chris _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
