[swift-evolution] Empower String type with regular expression

Mon Feb 1 09:59:10 CST 2016

There is path match

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

*___________________________________*

*James⎥Lead Engineer*

*james at supmenow.com <james at 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 at 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 at 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 at supmenow.com <james at 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 at 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 at icloud.com> wrote:
>>
>>
>> Le 31 janv. 2016 à 16:46, Patrick Gili <gili.patrick.r at 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 at 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 at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160201/a63acc8a/attachment.html>