[swift-evolution] Strings in Swift 4

Dave Abrahams dabrahams at apple.com
Fri Jan 27 21:54:09 CST 2017

on Fri Jan 27 2017, Chris Lattner <sabre-AT-nondot.org> wrote:

> On Jan 26, 2017, at 11:15 AM, Dave Abrahams <dabrahams at apple.com> 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.


More information about the swift-evolution mailing list