Empower String type with regular expression

[Haravikk3 (Haravikk)]

I like the verbal expressions syntax, could we do both? i.e- instead of mapping straight onto NSRegularExpression, could we have a Swift RegularExpression struct that can either take a traditional regular expression, or be constructed via verbal expressions? It might be mapped onto NSRegularExpression behind the scenes, but could let us use both forms easily.

···

On 1 Feb 2016, at 03:48, John Randolph via swift-evolution <swift-evolution@swift.org> wrote:

Perl 6’s regex implementation looks like a logical progression of the grep style as we’ve come to know it over the years, but I’d really like to see Swift go with something like the Verbal Expressions approach.

GitHub - VerbalExpressions/SwiftVerbalExpressions: Swift Port of VerbalExpressions

All the power is there, but it’s far more readable.

[gwendal.roue (Gwendal Roué)]

It depends who is the reader.

When the reader is an expert, `VerEx().startOfLine().then("http")` is much less readable than /^http/. It’s all about calling a spade a spade, and a regular expression, a regular expression. See Swift.org - API Design Guidelines.

Swift should aim at expert features: the great open source community will provide libraries as SwiftVerbalExpressions. Expert features don’t have to be complex. they just need to be comprehensive and well-exposed.

In a related topic, I much prefer a Swift wrapper for a SQL database that gives me *optional* sugar on top on a *solid* support for SQL.

Gwendal Roué

···

Le 1 févr. 2016 à 04:48, John Randolph via swift-evolution <swift-evolution@swift.org> a écrit :

On Jan 31, 2016, at 7:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 31, 2016, at 8:32 AM, Patrick Gili via swift-evolution <swift-evolution@swift.org> wrote:

There have been several threads that have discussed the notion of a regular expression literals. However, I didn't see anyone putting together a formal proposal, and hence I took the liberty to do so. I would appreciate discussion and comments on the proposal:

I am +1 on the concept of adding regex literals to Swift, but -1 on this proposal.

Specifically, instead of introducing regex literals, I’d suggest that you investigate introducing regex’s to the pattern grammar, which is what Swift uses for matching already. Regex’s should be usable in the cases of a switch, for example. Similarly, they should be able to bind variables directly to subpatterns.

Further, I highly recommend checking out Perl 6’s regular expressions. They are a community that has had an obsessive passion for regular expressions, and in Perl 6 they were given the chance to reinvent the wheel based on what they learned. What they came up with is very powerful, and pretty good all around.

Perl 6’s regex implementation looks like a logical progression of the grep style as we’ve come to know it over the years, but I’d really like to see Swift go with something like the Verbal Expressions approach.

GitHub - VerbalExpressions/SwiftVerbalExpressions: Swift Port of VerbalExpressions

All the power is there, but it’s far more readable.

[Chris_Lattner]

PCRE is based on Perl 5 regular expressions. You are correct that they are well known and widely used, but they also have a lot of problems, and Perl 6 made them a lot better.

This is the first hit I had for “Perl 6 regex”:

GitHub - Raku/old-design-docs: Raku language design documents

Things I like about them:
1) They mostly use the standard regex operator grammar x?, x*, x+, etc.
2) They allow free form style.
3) They allow comments within them.
4) Unicode aware and correct.
5) They are checked and validated by the compiler (not just a string fed into a runtime call).

etc.

-Chris

···

On Feb 1, 2016, at 6:47 AM, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:

Hi Chris,

Thank you for the feedback; it is much appreciated.

I like the idea of folding this into the language's pattern grammar. It makes it more Swifty. I didn't see that direction, and I will investigate it further.

I have been looking a lot at Perl 6. In fact, a lot of languages these days use PCRE or PCRE2, which was based on Perl's implementation of regular expressions. Does this mean there is attitude to move away from the regular expression implementation used by the foundation today?

[Dany_St-Amant]

Nice (too verbose for me) but mainly missing some key use cases; beside
1. checking if something matches
2. replacing matches

One needs to be able to:
3. see the matches (as tuple?) (the capturing concept in the perl documentation)
4. counting matches (common use: are there more than a single match raise)

And to satisfy people familiar with strstr() maybe:
5. location of first match

Dany

···

Le 31 janv. 2016 à 22:48, John Randolph via swift-evolution <swift-evolution@swift.org> a écrit :

On Jan 31, 2016, at 7:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 31, 2016, at 8:32 AM, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

There have been several threads that have discussed the notion of a regular expression literals. However, I didn't see anyone putting together a formal proposal, and hence I took the liberty to do so. I would appreciate discussion and comments on the proposal:

I am +1 on the concept of adding regex literals to Swift, but -1 on this proposal.

Specifically, instead of introducing regex literals, I’d suggest that you investigate introducing regex’s to the pattern grammar, which is what Swift uses for matching already. Regex’s should be usable in the cases of a switch, for example. Similarly, they should be able to bind variables directly to subpatterns.

Further, I highly recommend checking out Perl 6’s regular expressions. They are a community that has had an obsessive passion for regular expressions, and in Perl 6 they were given the chance to reinvent the wheel based on what they learned. What they came up with is very powerful, and pretty good all around.

Perl 6’s regex implementation looks like a logical progression of the grep style as we’ve come to know it over the years, but I’d really like to see Swift go with something like the Verbal Expressions approach.

GitHub - VerbalExpressions/SwiftVerbalExpressions: Swift Port of VerbalExpressions

All the power is there, but it’s far more readable.

[Patrick_Gili]

Dany,

When you say "sub patterns", do you mean "capture groups"?

-Patrick

···

On Feb 1, 2016, at 10:43 PM, Dany St-Amant via swift-evolution <swift-evolution@swift.org> wrote:

Le 31 janv. 2016 à 22:39, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

On Jan 31, 2016, at 8:32 AM, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

There have been several threads that have discussed the notion of a regular expression literals. However, I didn't see anyone putting together a formal proposal, and hence I took the liberty to do so. I would appreciate discussion and comments on the proposal:

I am +1 on the concept of adding regex literals to Swift, but -1 on this proposal.

Specifically, instead of introducing regex literals, I’d suggest that you investigate introducing regex’s to the pattern grammar, which is what Swift uses for matching already. Regex’s should be usable in the cases of a switch, for example. Similarly, they should be able to bind variables directly to sub patterns.

I was seeing the sub patterns originally a bit like:
switch( string <match-op> regex) {
  case .matches(_, "http", let port):
  case .matches(_, let name, "8080"):
  case .matches(_, "\\smb\ <smb://smb/>"):
}
but the comment about the pattern grammar make me of:
switch( string ) {
  case regexp1: if ($0.1 = "http") { }
  case regexp2:
}
Both have their uses

Dany

Further, I highly recommend checking out Perl 6’s regular expressions. They are a community that has had an obsessive passion for regular expressions, and in Perl 6 they were given the chance to reinvent the wheel based on what they learned. What they came up with is very powerful, and pretty good all around.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Tino]

Of course it is possible to create a regex from a string at runtime — but when you do so at compile time you
- can check the syntax
- compile the expression down to machine code for better performance (there could be a significant advantage).

Sidenote:
In 2013, when I got bored by Objective-C and didn't know about the secret work on Swift, I started playing with llvm and tried to build a regex-compiler to get familiar with the infrastructure.
I had to stop halfway because of "real" work, but I'm sure native regex support would make Swift even better for server-side programming and scripting.

[Patrick_Gili]

Hi Brent,

I think we should go all the way. The Perl6 community has done a bang up job: developers don't need to worry about writing tokenizers anymore, more intuitive and reduced number of meta characters, increased reusability and readability, and well throughout support for Unicode.

I like the new grammar feature, but I'm still reading about this and playing with it. I wonder if it isn't something we can consider later.

Cheers,
-Patrick

···

Sent from my iPad

On Feb 7, 2016, at 5:13 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

Further, I highly recommend checking out Perl 6’s regular expressions. They are a community that has had an obsessive passion for regular expressions, and in Perl 6 they were given the chance to reinvent the wheel based on what they learned. What they came up with is very powerful, and pretty good all around.

As someone who learned to argue about language design on perl6-language, you have my interest. :^)

How far do you want to go here? In the small, Perl 6 redesigned regex syntax to remove certain syntactic hacks and make more common operations more accessible; in the medium, they introduced extensibility and reusability with named rules; in the large, they made grammars of named rules a first-class language feature; and in the very large, they turned the parsing of Perl itself into a Perl grammar you could subclass and modify for metaprogramming. #1 and #4 are very different propositions.

--
Brent Royal-Gordon
Architechies

[Chris_Lattner]

Further, I highly recommend checking out Perl 6’s regular expressions. They are a community that has had an obsessive passion for regular expressions, and in Perl 6 they were given the chance to reinvent the wheel based on what they learned. What they came up with is very powerful, and pretty good all around.

As someone who learned to argue about language design on perl6-language, you have my interest. :^)

How far do you want to go here?

Honestly, I don’t know. I haven’t had much time to think/fantasize about this since it is clearly outside the scope of what we can do in Swift 3. I’d love to tackle regex’s in Swift 4, though it is too early to tell what we’ll be able to tackle there (depends on what all we get done in Swift 3).

In the small, Perl 6 redesigned regex syntax to remove certain syntactic hacks and make more common operations more accessible; in the medium, they introduced extensibility and reusability with named rules; in the large, they made grammars of named rules a first-class language feature; and in the very large, they turned the parsing of Perl itself into a Perl grammar you could subclass and modify for metaprogramming. #1 and #4 are very different propositions.

I don’t care about #4 at all, but I’m very interested in 1-3. My interest in turning regex’s into a first class language feature (instead of, e.g., a new string literal type) is that we can get better compiler error recovery, IDE support, better integration with pattern matching, and generally “unlimited” integration with the rest of the language.

-Chris

···

On Feb 7, 2016, at 2:13 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

[Dany_St-Amant]

Hi Dany,

Please find my response inline below.

Cheers,
-Patrick

This seem to be two proposals in one:
1. Initialize NSRegularExpression with a single String which includes options

The ultimate goal based on the earlier mail in the thread seems to be able in a future proposal do thing like: string ~= replacePattern, if string =~ pattern, decoupled from the legacy Obj-C. Isn’t NSRegularExpression part of the legacy? The conversion of the literal string as regular expression should probably part of the proposal for these operators; as this is the time we will know how we want the text to be interpreted.

I don't see any evidence of NSRegularExpression becoming part of any legacy. Given SE-005, SE-006, and SE-023, the name is probably changing from NSRegularExpression to RegularExpression. However, I don't think the definition of the class will change, only the name.

I would like to see an operator regular expression matching operator, like Ruby and Perl. I was trying to keep the proposal a minimal increment that would buy the biggest bang for the buck. We can already accomplish much of what other languages can do with regard to regular expression. However, the notion of a regular expression isn't something we can work around with custom library today. Can you suggest something addition that should be in the proposal?

Splitting proposal in smaller ones have its advantage, but here I am just wondering if we are sure that these future operation will use the NSRegularExpression/RegularExpression. And does the currently selected syntax allow for future expansion, it would be bad to introduce something that need to be torn away or changed in an incompatible way, once we really start to use them in their final location.

The proposal is focused on the search, but seem to skip the substitution; I am unable to see an option to replace all matches instead of the first one only in the proposal. I, as many other, would expect regular expression in a language to also support substitution.

As for addition to the proposal, the processing of the string could be support for any character (within some limit) for the slash delimiter. With sed, when replacing path component, one can do: echo $PWD | sed -e "s:^/usr/local/bin:/opt/share/bin:g", instead of escaping every single slashes. Which is really handy to make thing easier to read.

Also, putting aside that I think \(scheme) should not be interpreted in the example, with a syntax allowing such interpretation the variable should be processed to generate proper escaping. If one is to use \(filename) you get "main.c", but one must use \(filename.escaped()) to get the proper "main\.c" to avoid matching "mainac". The String.escaped() must be in a format compatible with the format used when converting the regular expression into NSRegularExpression (not sure if the two syntax are the same; I think that at least the handling of / may differ)

2. Easily create a String without escaping (\n is not linefeed, but \ and n)

The ability to not interpret the backslash as escape can be useful in other scenario that creating a NSRegularExpression; like creating a Windows pathname, or creating regular expression which are then given to external tool. So this part of the proposal should probably be generalized.

Generalize it for what? If you're thinking along the line of raw strings, I agree that we need this capability, as well as multi-line string literals. However, I just soon we have separate proposals for this.

My point/opinion here, is that a regular expressions are just a String which are then interpreted; the same way as "Good Morning", "Bonjour", or "Marhaba" (even when using the arabic script) are just String when you assign then to a variable in Swift, and then interpreted by the intended user. They are not String, frenchString, rigthToLeftString. So I do not see why a regular expression should have privileged treatment and have its own language level syntax. The only difference when writing regular expression, or Windows pathname, or any String with a syntax with heavily uses of backslashes, is that one may want to disable the special meaning of the backslashes, to make thing more readable.

On the page of geeky-ing the String there’s four main part IMHO
- multi-line support
- no backslash escaping version (which should include no processing the \(variable) format)
- inclusion of String delimiter inside the String
- concat of backslash/no backslash version. Bash example echo 'echo "$BASH" shows '"$BASH"

I’m still trying to find back the mail thread crumbs on these topics, since before restarting the discussion in these topics, the previous one should be properly summarized; unless such summary already exist.

Regards,
Dany

···

Le 31 janv. 2016 à 16:46, Patrick Gili <gili.patrick.r@gili-labs.com> a écrit :

On Jan 31, 2016, at 3:46 PM, Dany St-Amant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Dany

Le 31 janv. 2016 à 12:18, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Here is the link to the proposal on GitHub:

https://github.com/gili-patrick-r/swift-evolution/blob/master/proposals/NNNN-regular-expression-literals.md

Cheers,
-Patrick

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[David_Sweeris]

Yeah… that verbal expressions thing looks really cool, but it’s not a substitute for the “real thing”. If we put the testing bit in a protocol, anything that validates text could conform to it and automatically be usable with switches and such:
protocol RegExValidator {
    func validateRegEx(_: String) -> Bool
}
func ~= (lhs: String, rhs: RegExValidator) -> Bool {
    return rhs.validateRegEx(lhs)
}
func ~= (lhs: RegExValidator, rhs: String) -> Bool {
    return lhs.validateRegEx(rhs)
}

- Dave Sweeris

···

On Feb 1, 2016, at 02:02, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 1 Feb 2016, at 03:48, John Randolph via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Perl 6’s regex implementation looks like a logical progression of the grep style as we’ve come to know it over the years, but I’d really like to see Swift go with something like the Verbal Expressions approach.

GitHub - VerbalExpressions/SwiftVerbalExpressions: Swift Port of VerbalExpressions

All the power is there, but it’s far more readable.

I like the verbal expressions syntax, could we do both? i.e- instead of mapping straight onto NSRegularExpression, could we have a Swift RegularExpression struct that can either take a traditional regular expression, or be constructed via verbal expressions? It might be mapped onto NSRegularExpression behind the scenes, but could let us use both forms easily.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Patrick_Gili]

Agreed.

In addition, I would like to consider the direction suggested by Chris. I don't think something like Swift Verbal Expressions works well with this direction. However, I could be wrong. If someone can illustrate how to do this, I'm open the idea.

Cheers,
-Patrick

···

On Feb 1, 2016, at 5:22 AM, Gwendal Roué via swift-evolution <swift-evolution@swift.org> wrote:

Le 1 févr. 2016 à 04:48, John Randolph via swift-evolution <swift-evolution@swift.org> a écrit :

On Jan 31, 2016, at 7:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 31, 2016, at 8:32 AM, Patrick Gili via swift-evolution <swift-evolution@swift.org> wrote:

There have been several threads that have discussed the notion of a regular expression literals. However, I didn't see anyone putting together a formal proposal, and hence I took the liberty to do so. I would appreciate discussion and comments on the proposal:

I am +1 on the concept of adding regex literals to Swift, but -1 on this proposal.

Specifically, instead of introducing regex literals, I’d suggest that you investigate introducing regex’s to the pattern grammar, which is what Swift uses for matching already. Regex’s should be usable in the cases of a switch, for example. Similarly, they should be able to bind variables directly to subpatterns.

Further, I highly recommend checking out Perl 6’s regular expressions. They are a community that has had an obsessive passion for regular expressions, and in Perl 6 they were given the chance to reinvent the wheel based on what they learned. What they came up with is very powerful, and pretty good all around.

Perl 6’s regex implementation looks like a logical progression of the grep style as we’ve come to know it over the years, but I’d really like to see Swift go with something like the Verbal Expressions approach.

GitHub - VerbalExpressions/SwiftVerbalExpressions: Swift Port of VerbalExpressions

All the power is there, but it’s far more readable.

It depends who is the reader.

When the reader is an expert, `VerEx().startOfLine().then("http")` is much less readable than /^http/. It’s all about calling a spade a spade, and a regular expression, a regular expression. See Swift.org - API Design Guidelines.

Swift should aim at expert features: the great open source community will provide libraries as SwiftVerbalExpressions. Expert features don’t have to be complex. they just need to be comprehensive and well-exposed.

In a related topic, I much prefer a Swift wrapper for a SQL database that gives me *optional* sugar on top on a *solid* support for SQL.

Gwendal Roué

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Patrick_Gili]

Hi Chris,

Appreciate the pointer. Let me look at this further. Do you know of any open source effort that implements this?

Cheers,
-Patrick

···

On Feb 1, 2016, at 4:55 PM, Chris Lattner <clattner@apple.com> wrote:

On Feb 1, 2016, at 6:47 AM, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:

Hi Chris,

Thank you for the feedback; it is much appreciated.

I like the idea of folding this into the language's pattern grammar. It makes it more Swifty. I didn't see that direction, and I will investigate it further.

I have been looking a lot at Perl 6. In fact, a lot of languages these days use PCRE or PCRE2, which was based on Perl's implementation of regular expressions. Does this mean there is attitude to move away from the regular expression implementation used by the foundation today?

PCRE is based on Perl 5 regular expressions. You are correct that they are well known and widely used, but they also have a lot of problems, and Perl 6 made them a lot better.

This is the first hit I had for “Perl 6 regex”:
GitHub - Raku/old-design-docs: Raku language design documents

Things I like about them:
1) They mostly use the standard regex operator grammar x?, x*, x+, etc.
2) They allow free form style.
3) They allow comments within them.
4) Unicode aware and correct.
5) They are checked and validated by the compiler (not just a string fed into a runtime call).

etc.

-Chris

[Dany_St-Amant]

Dany,

When you say "sub patterns", do you mean "capture groups"?

Looks like my sub-patterns/matches are in Perl parlance capture groups, but it seems that this may need support from the compiler. Tuple have fixed length (no support for variadic tuple), could not get arrays to work in switch case, enum cannot reuse same name with different set of associated value.

···

Le 2 févr. 2016 à 07:43, Patrick Gili <gili.patrick.r@gili-labs.com> a écrit :

On Feb 1, 2016, at 10:43 PM, Dany St-Amant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Le 31 janv. 2016 à 22:39, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

On Jan 31, 2016, at 8:32 AM, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

There have been several threads that have discussed the notion of a regular expression literals. However, I didn't see anyone putting together a formal proposal, and hence I took the liberty to do so. I would appreciate discussion and comments on the proposal:

I am +1 on the concept of adding regex literals to Swift, but -1 on this proposal.

Specifically, instead of introducing regex literals, I’d suggest that you investigate introducing regex’s to the pattern grammar, which is what Swift uses for matching already. Regex’s should be usable in the cases of a switch, for example. Similarly, they should be able to bind variables directly to sub patterns.

I was seeing the sub patterns originally a bit like:
switch( string <match-op> regex) {
  case .matches(_, "http", let port):
  case .matches(_, let name, "8080"):
  case .matches(_, "\\smb\ <smb://smb/>"):
}
but the comment about the pattern grammar make me of:
switch( string ) {
  case regexp1: if ($0.1 = "http") { }
  case regexp2:
}
Both have their uses

Dany

Further, I highly recommend checking out Perl 6’s regular expressions. They are a community that has had an obsessive passion for regular expressions, and in Perl 6 they were given the chance to reinvent the wheel based on what they learned. What they came up with is very powerful, and pretty good all around.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Patrick_Gili]

Hi Dany,

My response is inline below.

Cheers,
-Patrick

Hi Dany,

Please find my response inline below.

Cheers,
-Patrick

This seem to be two proposals in one:
1. Initialize NSRegularExpression with a single String which includes options

The ultimate goal based on the earlier mail in the thread seems to be able in a future proposal do thing like: string ~= replacePattern, if string =~ pattern, decoupled from the legacy Obj-C. Isn’t NSRegularExpression part of the legacy? The conversion of the literal string as regular expression should probably part of the proposal for these operators; as this is the time we will know how we want the text to be interpreted.

I don't see any evidence of NSRegularExpression becoming part of any legacy. Given SE-005, SE-006, and SE-023, the name is probably changing from NSRegularExpression to RegularExpression. However, I don't think the definition of the class will change, only the name.

I would like to see an operator regular expression matching operator, like Ruby and Perl. I was trying to keep the proposal a minimal increment that would buy the biggest bang for the buck. We can already accomplish much of what other languages can do with regard to regular expression. However, the notion of a regular expression isn't something we can work around with custom library today. Can you suggest something addition that should be in the proposal?

Splitting proposal in smaller ones have its advantage, but here I am just wondering if we are sure that these future operation will use the NSRegularExpression/RegularExpression. And does the currently selected syntax allow for future expansion, it would be bad to introduce something that need to be torn away or changed in an incompatible way, once we really start to use them in their final location.

The proposal is focused on the search, but seem to skip the substitution; I am unable to see an option to replace all matches instead of the first one only in the proposal. I, as many other, would expect regular expression in a language to also support substitution.

As for addition to the proposal, the processing of the string could be support for any character (within some limit) for the slash delimiter. With sed, when replacing path component, one can do: echo $PWD | sed -e "s:^/usr/local/bin:/opt/share/bin:g", instead of escaping every single slashes. Which is really handy to make thing easier to read.

Also, putting aside that I think \(scheme) should not be interpreted in the example, with a syntax allowing such interpretation the variable should be processed to generate proper escaping. If one is to use \(filename) you get "main.c", but one must use \(filename.escaped()) to get the proper "main\.c" to avoid matching "mainac". The String.escaped() must be in a format compatible with the format used when converting the regular expression into NSRegularExpression (not sure if the two syntax are the same; I think that at least the handling of / may differ)

I agree. Perhaps I went too far with keeping the proposal short-and-sweet. Especially when you consider the rich syntax that Perl supports for substitution.

2. Easily create a String without escaping (\n is not linefeed, but \ and n)

The ability to not interpret the backslash as escape can be useful in other scenario that creating a NSRegularExpression; like creating a Windows pathname, or creating regular expression which are then given to external tool. So this part of the proposal should probably be generalized.

Generalize it for what? If you're thinking along the line of raw strings, I agree that we need this capability, as well as multi-line string literals. However, I just soon we have separate proposals for this.

My point/opinion here, is that a regular expressions are just a String which are then interpreted; the same way as "Good Morning", "Bonjour", or "Marhaba" (even when using the arabic script) are just String when you assign then to a variable in Swift, and then interpreted by the intended user. They are not String, frenchString, rigthToLeftString. So I do not see why a regular expression should have privileged treatment and have its own language level syntax. The only difference when writing regular expression, or Windows pathname, or any String with a syntax with heavily uses of backslashes, is that one may want to disable the special meaning of the backslashes, to make thing more readable.

On the page of geeky-ing the String there’s four main part IMHO
- multi-line support
- no backslash escaping version (which should include no processing the \(variable) format)
- inclusion of String delimiter inside the String
- concat of backslash/no backslash version. Bash example echo 'echo "$BASH" shows '"$BASH"

I’m still trying to find back the mail thread crumbs on these topics, since before restarting the discussion in these topics, the previous one should be properly summarized; unless such summary already exist.

I think supporting interpolation is important. Both Perl and Ruby support it, and I'm sure there are other languages. One thing I forgot to put into the proposal: an option to disable interpolation or limit it to single pass.

Looking ahead at the other responses, Chris Lattner has suggested that the proposal would have more traction if we can find a way to fold this into Swift's pattern matching. I can't say as I disagree, as this makes regular expression more Swifty.

···

On Jan 31, 2016, at 8:56 PM, Dany St-Amant <dsa.mls@icloud.com> wrote:

Le 31 janv. 2016 à 16:46, Patrick Gili <gili.patrick.r@gili-labs.com <mailto:gili.patrick.r@gili-labs.com>> a écrit :

On Jan 31, 2016, at 3:46 PM, Dany St-Amant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Regards,
Dany

Dany

Le 31 janv. 2016 à 12:18, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Here is the link to the proposal on GitHub:

https://github.com/gili-patrick-r/swift-evolution/blob/master/proposals/NNNN-regular-expression-literals.md

Cheers,
-Patrick

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Chris_Lattner]

Hi Chris,

Appreciate the pointer. Let me look at this further. Do you know of any open source effort that implements this?

I’m not sure what you mean. Perl 6 is a large effort and all of it is open source AFAIK.

-Chris

···

On Feb 1, 2016, at 2:03 PM, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:

Cheers,
-Patrick

On Feb 1, 2016, at 4:55 PM, Chris Lattner <clattner@apple.com> wrote:

On Feb 1, 2016, at 6:47 AM, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:

Hi Chris,

Thank you for the feedback; it is much appreciated.

I like the idea of folding this into the language's pattern grammar. It makes it more Swifty. I didn't see that direction, and I will investigate it further.

I have been looking a lot at Perl 6. In fact, a lot of languages these days use PCRE or PCRE2, which was based on Perl's implementation of regular expressions. Does this mean there is attitude to move away from the regular expression implementation used by the foundation today?

PCRE is based on Perl 5 regular expressions. You are correct that they are well known and widely used, but they also have a lot of problems, and Perl 6 made them a lot better.

This is the first hit I had for “Perl 6 regex”:
GitHub - Raku/old-design-docs: Raku language design documents

Things I like about them:
1) They mostly use the standard regex operator grammar x?, x*, x+, etc.
2) They allow free form style.
3) They allow comments within them.
4) Unicode aware and correct.
5) They are checked and validated by the compiler (not just a string fed into a runtime call).

etc.

-Chris

[Patrick_Gili]

Okay, I didn't know Perl was open source. I'll look at the Perl6 regular expression link you sent me.

Cheers,
-Patrick

···

On Feb 1, 2016, at 6:55 PM, Chris Lattner <clattner@apple.com> wrote:

On Feb 1, 2016, at 2:03 PM, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:

Hi Chris,

Appreciate the pointer. Let me look at this further. Do you know of any open source effort that implements this?

I’m not sure what you mean. Perl 6 is a large effort and all of it is open source AFAIK.

-Chris

Cheers,
-Patrick

On Feb 1, 2016, at 4:55 PM, Chris Lattner <clattner@apple.com> wrote:

On Feb 1, 2016, at 6:47 AM, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:

Hi Chris,

Thank you for the feedback; it is much appreciated.

I like the idea of folding this into the language's pattern grammar. It makes it more Swifty. I didn't see that direction, and I will investigate it further.

I have been looking a lot at Perl 6. In fact, a lot of languages these days use PCRE or PCRE2, which was based on Perl's implementation of regular expressions. Does this mean there is attitude to move away from the regular expression implementation used by the foundation today?

PCRE is based on Perl 5 regular expressions. You are correct that they are well known and widely used, but they also have a lot of problems, and Perl 6 made them a lot better.

This is the first hit I had for “Perl 6 regex”:
GitHub - Raku/old-design-docs: Raku language design documents

Things I like about them:
1) They mostly use the standard regex operator grammar x?, x*, x+, etc.
2) They allow free form style.
3) They allow comments within them.
4) Unicode aware and correct.
5) They are checked and validated by the compiler (not just a string fed into a runtime call).

etc.

-Chris

[James_Campbell]

It would be great if we could create a generic way of making this swifty.
You may let say want to implement a matching system for structure like JSON
or XML (i.e XQuery).

···

*___________________________________*

*James⎥Lead Engineer*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Mon, Feb 1, 2016 at 2:43 PM, Patrick Gili via swift-evolution < swift-evolution@swift.org> wrote:

Hi Dany,

My response is inline below.

Cheers,
-Patrick

On Jan 31, 2016, at 8:56 PM, Dany St-Amant <dsa.mls@icloud.com> wrote:

Le 31 janv. 2016 à 16:46, Patrick Gili <gili.patrick.r@gili-labs.com> a
écrit :

Hi Dany,

Please find my response inline below.

Cheers,
-Patrick

On Jan 31, 2016, at 3:46 PM, Dany St-Amant via swift-evolution < > swift-evolution@swift.org> wrote:

This seem to be two proposals in one:
1. Initialize NSRegularExpression with a single String which includes
options

The ultimate goal based on the earlier mail in the thread seems to be able
in a future proposal do thing like: string ~= replacePattern, if string =~
pattern, decoupled from the legacy Obj-C. Isn’t NSRegularExpression part of
the legacy? The conversion of the literal string as regular expression
should probably part of the proposal for these operators; as this is the
time we will know how we want the text to be interpreted.

I don't see any evidence of NSRegularExpression becoming part of any
legacy. Given SE-005, SE-006, and SE-023, the name is probably changing
from NSRegularExpression to RegularExpression. However, I don't think the
definition of the class will change, only the name.

I would like to see an operator regular expression matching operator, like
Ruby and Perl. I was trying to keep the proposal a minimal increment that
would buy the biggest bang for the buck. We can already accomplish much of
what other languages can do with regard to regular expression. However, the
notion of a regular expression isn't something we can work around with
custom library today. Can you suggest something addition that should be in
the proposal?

Splitting proposal in smaller ones have its advantage, but here I am just
wondering if we are sure that these future operation will use the
NSRegularExpression/RegularExpression. And does the currently selected
syntax allow for future expansion, it would be bad to introduce something
that need to be torn away or changed in an incompatible way, once we
really start to use them in their final location.

The proposal is focused on the search, but seem to skip the substitution;
I am unable to see an option to replace all matches instead of the first
one only in the proposal. I, as many other, would expect regular expression
in a language to also support substitution.

As for addition to the proposal, the processing of the string could be
support for any character (within some limit) for the slash delimiter. With
sed, when replacing path component, one can do: echo $PWD | sed -e
"s:^/usr/local/bin:/opt/share/bin:g", instead of escaping every single
slashes. Which is really handy to make thing easier to read.

Also, putting aside that I think \(scheme) should not be interpreted in
the example, with a syntax allowing such interpretation the variable should
be processed to generate proper escaping. If one is to use \(filename) you
get "main.c", but one must use \(filename.escaped()) to get the proper
"main\.c" to avoid matching "mainac". The String.escaped() must be in a
format compatible with the format used when converting the regular
expression into NSRegularExpression (not sure if the two syntax are the
same; I think that at least the handling of / may differ)

I agree. Perhaps I went too far with keeping the proposal short-and-sweet.
Especially when you consider the rich syntax that Perl supports for
substitution.

2. Easily create a String without escaping (\n is not linefeed, but \ and
n)

The ability to not interpret the backslash as escape can be useful in
other scenario that creating a NSRegularExpression; like creating a Windows
pathname, or creating regular expression which are then given to external
tool. So this part of the proposal should probably be generalized.

Generalize it for what? If you're thinking along the line of raw strings,
I agree that we need this capability, as well as multi-line string
literals. However, I just soon we have separate proposals for this.

My point/opinion here, is that a regular expressions are just a String
which are then interpreted; the same way as "Good Morning", "Bonjour", or
"Marhaba" (even when using the arabic script) are just String when you
assign then to a variable in Swift, and then interpreted by the intended
user. They are not String, frenchString, rigthToLeftString. So I do not see
why a regular expression should have privileged treatment and have its own
language level syntax. The only difference when writing regular expression,
or Windows pathname, or any String with a syntax with heavily uses of
backslashes, is that one may want to disable the special meaning of the
backslashes, to make thing more readable.

On the page of geeky-ing the String there’s four main part IMHO
- multi-line support
- no backslash escaping version (which should include no processing the
\(variable) format)
- inclusion of String delimiter inside the String
- concat of backslash/no backslash version. Bash example echo 'echo
"$BASH" shows '"$BASH"

I’m still trying to find back the mail thread crumbs on these topics,
since before restarting the discussion in these topics, the previous one
should be properly summarized; unless such summary already exist.

I think supporting interpolation is important. Both Perl and Ruby support
it, and I'm sure there are other languages. One thing I forgot to put into
the proposal: an option to disable interpolation or limit it to single pass.

Looking ahead at the other responses, Chris Lattner has suggested that the
proposal would have more traction if we can find a way to fold this into
Swift's pattern matching. I can't say as I disagree, as this makes regular
expression more Swifty.

Regards,
Dany

Dany

Le 31 janv. 2016 à 12:18, Patrick Gili via swift-evolution < > swift-evolution@swift.org> a écrit :

Here is the link to the proposal on GitHub:

https://github.com/gili-patrick-r/swift-evolution/blob/master/proposals/NNNN-regular-expression-literals.md

Cheers,
-Patrick

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Patrick_Gili]

Hi James,

While I'm familiar with Query, I am not familiar with matching in JSON. Can you provide me an example or a pointer to something I can read?

Cheers,
-Patrik

···

On Feb 1, 2016, at 9:46 AM, James Campbell <james@supmenow.com> wrote:

It would be great if we could create a generic way of making this swifty. You may let say want to implement a matching system for structure like JSON or XML (i.e XQuery).

___________________________________

James⎥Lead Engineer

james@supmenow.com <mailto:james@supmenow.com>⎥supmenow.com <http://supmenow.com/&gt;
Sup

Runway East >

10 Finsbury Square

London

> EC2A 1AF

On Mon, Feb 1, 2016 at 2:43 PM, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi Dany,

My response is inline below.

Cheers,
-Patrick

On Jan 31, 2016, at 8:56 PM, Dany St-Amant <dsa.mls@icloud.com <mailto:dsa.mls@icloud.com>> wrote:

Le 31 janv. 2016 à 16:46, Patrick Gili <gili.patrick.r@gili-labs.com <mailto:gili.patrick.r@gili-labs.com>> a écrit :

Hi Dany,

Please find my response inline below.

Cheers,
-Patrick

On Jan 31, 2016, at 3:46 PM, Dany St-Amant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This seem to be two proposals in one:
1. Initialize NSRegularExpression with a single String which includes options

The ultimate goal based on the earlier mail in the thread seems to be able in a future proposal do thing like: string ~= replacePattern, if string =~ pattern, decoupled from the legacy Obj-C. Isn’t NSRegularExpression part of the legacy? The conversion of the literal string as regular expression should probably part of the proposal for these operators; as this is the time we will know how we want the text to be interpreted.

I don't see any evidence of NSRegularExpression becoming part of any legacy. Given SE-005, SE-006, and SE-023, the name is probably changing from NSRegularExpression to RegularExpression. However, I don't think the definition of the class will change, only the name.

I would like to see an operator regular expression matching operator, like Ruby and Perl. I was trying to keep the proposal a minimal increment that would buy the biggest bang for the buck. We can already accomplish much of what other languages can do with regard to regular expression. However, the notion of a regular expression isn't something we can work around with custom library today. Can you suggest something addition that should be in the proposal?

Splitting proposal in smaller ones have its advantage, but here I am just wondering if we are sure that these future operation will use the NSRegularExpression/RegularExpression. And does the currently selected syntax allow for future expansion, it would be bad to introduce something that need to be torn away or changed in an incompatible way, once we really start to use them in their final location.

The proposal is focused on the search, but seem to skip the substitution; I am unable to see an option to replace all matches instead of the first one only in the proposal. I, as many other, would expect regular expression in a language to also support substitution.

As for addition to the proposal, the processing of the string could be support for any character (within some limit) for the slash delimiter. With sed, when replacing path component, one can do: echo $PWD | sed -e "s:^/usr/local/bin:/opt/share/bin:g", instead of escaping every single slashes. Which is really handy to make thing easier to read.

Also, putting aside that I think \(scheme) should not be interpreted in the example, with a syntax allowing such interpretation the variable should be processed to generate proper escaping. If one is to use \(filename) you get "main.c", but one must use \(filename.escaped()) to get the proper "main\.c" to avoid matching "mainac". The String.escaped() must be in a format compatible with the format used when converting the regular expression into NSRegularExpression (not sure if the two syntax are the same; I think that at least the handling of / may differ)

I agree. Perhaps I went too far with keeping the proposal short-and-sweet. Especially when you consider the rich syntax that Perl supports for substitution.

2. Easily create a String without escaping (\n is not linefeed, but \ and n)

The ability to not interpret the backslash as escape can be useful in other scenario that creating a NSRegularExpression; like creating a Windows pathname, or creating regular expression which are then given to external tool. So this part of the proposal should probably be generalized.

Generalize it for what? If you're thinking along the line of raw strings, I agree that we need this capability, as well as multi-line string literals. However, I just soon we have separate proposals for this.

My point/opinion here, is that a regular expressions are just a String which are then interpreted; the same way as "Good Morning", "Bonjour", or "Marhaba" (even when using the arabic script) are just String when you assign then to a variable in Swift, and then interpreted by the intended user. They are not String, frenchString, rigthToLeftString. So I do not see why a regular expression should have privileged treatment and have its own language level syntax. The only difference when writing regular expression, or Windows pathname, or any String with a syntax with heavily uses of backslashes, is that one may want to disable the special meaning of the backslashes, to make thing more readable.

On the page of geeky-ing the String there’s four main part IMHO
- multi-line support
- no backslash escaping version (which should include no processing the \(variable) format)
- inclusion of String delimiter inside the String
- concat of backslash/no backslash version. Bash example echo 'echo "$BASH" shows '"$BASH"

I’m still trying to find back the mail thread crumbs on these topics, since before restarting the discussion in these topics, the previous one should be properly summarized; unless such summary already exist.

I think supporting interpolation is important. Both Perl and Ruby support it, and I'm sure there are other languages. One thing I forgot to put into the proposal: an option to disable interpolation or limit it to single pass.

Looking ahead at the other responses, Chris Lattner has suggested that the proposal would have more traction if we can find a way to fold this into Swift's pattern matching. I can't say as I disagree, as this makes regular expression more Swifty.

Regards,
Dany

Dany

Le 31 janv. 2016 à 12:18, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Here is the link to the proposal on GitHub:

https://github.com/gili-patrick-r/swift-evolution/blob/master/proposals/NNNN-regular-expression-literals.md

Cheers,
-Patrick

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[James_Campbell]

There is path match

http://goessner.net/articles/JsonPath/

···

*___________________________________*

*James⎥Lead Engineer*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Mon, Feb 1, 2016 at 2:57 PM, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:

Hi James,

While I'm familiar with Query, I am not familiar with matching in JSON.
Can you provide me an example or a pointer to something I can read?

Cheers,
-Patrik

On Feb 1, 2016, at 9:46 AM, James Campbell <james@supmenow.com> wrote:

It would be great if we could create a generic way of making this swifty.
You may let say want to implement a matching system for structure like JSON
or XML (i.e XQuery).

*___________________________________*

*James⎥Lead Engineer*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com
<http://supmenow.com/&gt;\*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Mon, Feb 1, 2016 at 2:43 PM, Patrick Gili via swift-evolution < > swift-evolution@swift.org> wrote:

Hi Dany,

My response is inline below.

Cheers,
-Patrick

On Jan 31, 2016, at 8:56 PM, Dany St-Amant <dsa.mls@icloud.com> wrote:

Le 31 janv. 2016 à 16:46, Patrick Gili <gili.patrick.r@gili-labs.com> a
écrit :

Hi Dany,

Please find my response inline below.

Cheers,
-Patrick

On Jan 31, 2016, at 3:46 PM, Dany St-Amant via swift-evolution < >> swift-evolution@swift.org> wrote:

This seem to be two proposals in one:
1. Initialize NSRegularExpression with a single String which includes
options

The ultimate goal based on the earlier mail in the thread seems to be
able in a future proposal do thing like: string ~= replacePattern, if
string =~ pattern, decoupled from the legacy Obj-C. Isn’t
NSRegularExpression part of the legacy? The conversion of the literal
string as regular expression should probably part of the proposal for these
operators; as this is the time we will know how we want the text to be
interpreted.

I don't see any evidence of NSRegularExpression becoming part of any
legacy. Given SE-005, SE-006, and SE-023, the name is probably changing
from NSRegularExpression to RegularExpression. However, I don't think the
definition of the class will change, only the name.

I would like to see an operator regular expression matching operator,
like Ruby and Perl. I was trying to keep the proposal a minimal increment
that would buy the biggest bang for the buck. We can already accomplish
much of what other languages can do with regard to regular expression.
However, the notion of a regular expression isn't something we can work
around with custom library today. Can you suggest something addition that
should be in the proposal?

Splitting proposal in smaller ones have its advantage, but here I am just
wondering if we are sure that these future operation will use the
NSRegularExpression/RegularExpression. And does the currently selected
syntax allow for future expansion, it would be bad to introduce something
that need to be torn away or changed in an incompatible way, once we
really start to use them in their final location.

The proposal is focused on the search, but seem to skip the substitution;
I am unable to see an option to replace all matches instead of the first
one only in the proposal. I, as many other, would expect regular expression
in a language to also support substitution.

As for addition to the proposal, the processing of the string could be
support for any character (within some limit) for the slash delimiter. With
sed, when replacing path component, one can do: echo $PWD | sed -e
"s:^/usr/local/bin:/opt/share/bin:g", instead of escaping every single
slashes. Which is really handy to make thing easier to read.

Also, putting aside that I think \(scheme) should not be interpreted in
the example, with a syntax allowing such interpretation the variable should
be processed to generate proper escaping. If one is to use \(filename) you
get "main.c", but one must use \(filename.escaped()) to get the proper
"main\.c" to avoid matching "mainac". The String.escaped() must be in a
format compatible with the format used when converting the regular
expression into NSRegularExpression (not sure if the two syntax are the
same; I think that at least the handling of / may differ)

I agree. Perhaps I went too far with keeping the proposal
short-and-sweet. Especially when you consider the rich syntax that Perl
supports for substitution.

2. Easily create a String without escaping (\n is not linefeed, but \ and
n)

The ability to not interpret the backslash as escape can be useful in
other scenario that creating a NSRegularExpression; like creating a Windows
pathname, or creating regular expression which are then given to external
tool. So this part of the proposal should probably be generalized.

Generalize it for what? If you're thinking along the line of raw strings,
I agree that we need this capability, as well as multi-line string
literals. However, I just soon we have separate proposals for this.

My point/opinion here, is that a regular expressions are just a String
which are then interpreted; the same way as "Good Morning", "Bonjour", or
"Marhaba" (even when using the arabic script) are just String when you
assign then to a variable in Swift, and then interpreted by the intended
user. They are not String, frenchString, rigthToLeftString. So I do not see
why a regular expression should have privileged treatment and have its own
language level syntax. The only difference when writing regular expression,
or Windows pathname, or any String with a syntax with heavily uses of
backslashes, is that one may want to disable the special meaning of the
backslashes, to make thing more readable.

On the page of geeky-ing the String there’s four main part IMHO
- multi-line support
- no backslash escaping version (which should include no processing the
\(variable) format)
- inclusion of String delimiter inside the String
- concat of backslash/no backslash version. Bash example echo 'echo
"$BASH" shows '"$BASH"

I’m still trying to find back the mail thread crumbs on these topics,
since before restarting the discussion in these topics, the previous one
should be properly summarized; unless such summary already exist.

I think supporting interpolation is important. Both Perl and Ruby support
it, and I'm sure there are other languages. One thing I forgot to put into
the proposal: an option to disable interpolation or limit it to single pass.

Looking ahead at the other responses, Chris Lattner has suggested that
the proposal would have more traction if we can find a way to fold this
into Swift's pattern matching. I can't say as I disagree, as this makes
regular expression more Swifty.

Regards,
Dany

Dany

Le 31 janv. 2016 à 12:18, Patrick Gili via swift-evolution < >> swift-evolution@swift.org> a écrit :

Here is the link to the proposal on GitHub:

https://github.com/gili-patrick-r/swift-evolution/blob/master/proposals/NNNN-regular-expression-literals.md

Cheers,
-Patrick

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[trs (Thorsten Seitz)]

Something like Scala's extractors or F#'s Active Patterns would be most welcome to generalize pattern matching.

http://docs.scala-lang.org/tutorials/tour/extractor-objects.html
https://en.m.wikibooks.org/wiki/F_Sharp_Programming/Active_Patterns

-Thorsten

···

Am 01.02.2016 um 15:46 schrieb James Campbell via swift-evolution <swift-evolution@swift.org>:

It would be great if we could create a generic way of making this swifty. You may let say want to implement a matching system for structure like JSON or XML (i.e XQuery).

___________________________________

James⎥Lead Engineer

james@supmenow.com⎥supmenow.com

Sup

Runway East >

10 Finsbury Square

London

> EC2A 1AF

On Mon, Feb 1, 2016 at 2:43 PM, Patrick Gili via swift-evolution <swift-evolution@swift.org> wrote:
Hi Dany,

My response is inline below.

Cheers,
-Patrick

On Jan 31, 2016, at 8:56 PM, Dany St-Amant <dsa.mls@icloud.com> wrote:

Le 31 janv. 2016 à 16:46, Patrick Gili <gili.patrick.r@gili-labs.com> a écrit :

Hi Dany,

Please find my response inline below.

Cheers,
-Patrick

On Jan 31, 2016, at 3:46 PM, Dany St-Amant via swift-evolution <swift-evolution@swift.org> wrote:

This seem to be two proposals in one:
1. Initialize NSRegularExpression with a single String which includes options

The ultimate goal based on the earlier mail in the thread seems to be able in a future proposal do thing like: string ~= replacePattern, if string =~ pattern, decoupled from the legacy Obj-C. Isn’t NSRegularExpression part of the legacy? The conversion of the literal string as regular expression should probably part of the proposal for these operators; as this is the time we will know how we want the text to be interpreted.

I don't see any evidence of NSRegularExpression becoming part of any legacy. Given SE-005, SE-006, and SE-023, the name is probably changing from NSRegularExpression to RegularExpression. However, I don't think the definition of the class will change, only the name.

I would like to see an operator regular expression matching operator, like Ruby and Perl. I was trying to keep the proposal a minimal increment that would buy the biggest bang for the buck. We can already accomplish much of what other languages can do with regard to regular expression. However, the notion of a regular expression isn't something we can work around with custom library today. Can you suggest something addition that should be in the proposal?

Splitting proposal in smaller ones have its advantage, but here I am just wondering if we are sure that these future operation will use the NSRegularExpression/RegularExpression. And does the currently selected syntax allow for future expansion, it would be bad to introduce something that need to be torn away or changed in an incompatible way, once we really start to use them in their final location.

The proposal is focused on the search, but seem to skip the substitution; I am unable to see an option to replace all matches instead of the first one only in the proposal. I, as many other, would expect regular expression in a language to also support substitution.

As for addition to the proposal, the processing of the string could be support for any character (within some limit) for the slash delimiter. With sed, when replacing path component, one can do: echo $PWD | sed -e "s:^/usr/local/bin:/opt/share/bin:g", instead of escaping every single slashes. Which is really handy to make thing easier to read.

Also, putting aside that I think \(scheme) should not be interpreted in the example, with a syntax allowing such interpretation the variable should be processed to generate proper escaping. If one is to use \(filename) you get "main.c", but one must use \(filename.escaped()) to get the proper "main\.c" to avoid matching "mainac". The String.escaped() must be in a format compatible with the format used when converting the regular expression into NSRegularExpression (not sure if the two syntax are the same; I think that at least the handling of / may differ)

I agree. Perhaps I went too far with keeping the proposal short-and-sweet. Especially when you consider the rich syntax that Perl supports for substitution.

2. Easily create a String without escaping (\n is not linefeed, but \ and n)

The ability to not interpret the backslash as escape can be useful in other scenario that creating a NSRegularExpression; like creating a Windows pathname, or creating regular expression which are then given to external tool. So this part of the proposal should probably be generalized.

Generalize it for what? If you're thinking along the line of raw strings, I agree that we need this capability, as well as multi-line string literals. However, I just soon we have separate proposals for this.

My point/opinion here, is that a regular expressions are just a String which are then interpreted; the same way as "Good Morning", "Bonjour", or "Marhaba" (even when using the arabic script) are just String when you assign then to a variable in Swift, and then interpreted by the intended user. They are not String, frenchString, rigthToLeftString. So I do not see why a regular expression should have privileged treatment and have its own language level syntax. The only difference when writing regular expression, or Windows pathname, or any String with a syntax with heavily uses of backslashes, is that one may want to disable the special meaning of the backslashes, to make thing more readable.

On the page of geeky-ing the String there’s four main part IMHO
- multi-line support
- no backslash escaping version (which should include no processing the \(variable) format)
- inclusion of String delimiter inside the String
- concat of backslash/no backslash version. Bash example echo 'echo "$BASH" shows '"$BASH"

I’m still trying to find back the mail thread crumbs on these topics, since before restarting the discussion in these topics, the previous one should be properly summarized; unless such summary already exist.

I think supporting interpolation is important. Both Perl and Ruby support it, and I'm sure there are other languages. One thing I forgot to put into the proposal: an option to disable interpolation or limit it to single pass.

Looking ahead at the other responses, Chris Lattner has suggested that the proposal would have more traction if we can find a way to fold this into Swift's pattern matching. I can't say as I disagree, as this makes regular expression more Swifty.

Regards,
Dany

Dany

Le 31 janv. 2016 à 12:18, Patrick Gili via swift-evolution <swift-evolution@swift.org> a écrit :

Here is the link to the proposal on GitHub:

https://github.com/gili-patrick-r/swift-evolution/blob/master/proposals/NNNN-regular-expression-literals.md

Cheers,
-Patrick

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution