[swift-evolution] Strings in Swift 4

[Dave Abrahams]

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

> On Jan 25, 2017, at 7:32 PM, Dave Abrahams <dabrahams at 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.

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