How about something like http://www.inf.puc-rio.br/~roberto/lpeg/ ?
Since the optional pattern syntax doesn't use backslashes, they aren't a problem. I'd hack this up myself if Swift weren't Apple-only.
Regex in Swift
11–20 of 37 posts
Re: Regex in Swift
#12Custom operators for all things ! or how to make your code base unmaintainable
They should put big intrusive warnings on operator overloads to discourage their use, like "Warning, you are using the complement operator for an operation which does not appear to be a complement. Don't do this!" (or alternatively, drop operator overloads from the language, because they are abused more often than not).
I don't really see how `name =~ "somepat"` is any more readable or writable than something like `name.matches("somepat")`, which can be trivially added as an extension of String, and needs no special syntactic support. Something like this:
extension String {
func matches(pattern: String) -> Bool {
return Regex.new(pattern).test(self)
}
}Re: Regex in Swift
#13Custom operators for all things ! or how to make your code base unmaintainable
I've never understood this position. Why is a symbolic operator name so much more difficult to maintain than a name restricted to [a-zA-Z0-9_]?
Over the last decade I've heard this repeated (and been stuck in languages which don't support operator overloading), and by chance, the very first project I chose to try to implement in Swift and I found a valid use for operator overloading (manipulating coordinates in a simple 3D renderer).
foo = foo.add(bar)
baz = baz.div(car)
foo = foo + bar
baz = baz / car
foo += bar
baz /= car
edit: bug ;)
Re: Regex in Swift
#14The author is maybe not aware that there's already a convenience form that doesn't require explicitly making an NSRegularExpression object.
if name.rangeOfString("ski$", options: .RegularExpressionSearch).location != NSNotFound {
println("\(name) is probably polish")
}
if let match = name.rangeOfString("ski$", options: .RegularExpressionSearch) {
println("\(name) is probably polish")
}
Re: Regex in Swift
#15Custom operators for all things ! or how to make your code base unmaintainable
They should put big intrusive warnings on operator overloads to discourage their use, like "Warning, you are using the complement operator for an operation which does not appear to be a complement. Don't do this!" (or alternatively, drop operator overloads from the language, because they are abused more often than not). I don't really see how `name =~ "somepat"` is any more readable or writable than something like `n…
> They should put big intrusive warnings on operator
> overloads to discourage their use, like…
In Swift, operator overloading requires no special syntactic support. Since it's a supported language feature, don't be surprised to see people use it.
Re: Regex in Swift
#16"Please tack on this random application-specific feature that I like" Can we add supprt for overloading the comma operator? How about the mail function from PHP?
It could be less specific as a raw string literal, like python r"".
Yes, and you could also use it for other types of embedded programs, like OpenGL shaders.
Re: Regex in Swift
#17Custom operators for all things ! or how to make your code base unmaintainable
I've never understood this position. Why is a symbolic operator name so much more difficult to maintain than a name restricted to [a-zA-Z0-9_]? Over the last decade I've heard this repeated (and been stuck in languages which don't support operator overloading), and by chance, the very first project I chose to try to implement in Swift and I found a valid use for operator overloading (manipulating coordinates in a sim…
> I've never understood this position. Why is a symbolic operator name so much more difficult to maintain than a name restricted to [a-zA-Z0-9_]?
Several reasons:
It's not obvious what an operator does, whereas names are descriptive. Some operators are "obvious", because they're firmly ingrained into our culture - (+) for addition is an example, it's almost universally understood to mean that. On the other hand, where in tilde, ~, is it obvious that you meant to test if a string matches a regular pattern? It's only obvious to descendants of PERL, for the reason that Larry Wall decided arbitrarily to use it for such. If every programmer invented his own operators instead of using the common languages we share, we would get nowhere.
Indeed, operator overloads are really useful when you use them the right way, as per your own example, but the flaw in allowing people to overload operators arbitrarily is that they abuse them to mean something unexpected - we all expect + to mean addition, but when it's used to concatenate two strings, it's easy to get confused as to why the hell somebody thought that was a good idea.
A big hurdle is even figuring out what an operator means if you've never encountered it. Unless you have good IDE support to navigate to its definition, or a specialized search engine for searching your language, then a typical search is going to turn up naught. On the other hand, most search engines understand [a-ZA-Z]+.
We could argue that using "+" for string concatenation "is obvious", at least to other programmers - but only because they've encountered such usage before. We can't reasonably expect to learn, recall, and fluently read arbitrary operators for any conceivable operation you can think of. Well, unless you're a fan of Control.Lens.Operators (http://hackage.haskell.org/package/lens-4.1.2/docs/Control-L...), then nobody else is going to read your code.
Re: Regex in Swift
#18There is probably a good reason Swift doesn't have regex literals, regex operators, and other such things. These things are not common in statically, strongly typed languages with an emphasis on safety. That could be pure correlation. Perhaps it is just coincidence that JavaScript, PHP, Perl, and a handful of others happen to have a lot of "stringly typed" code, message passing using strings as data structures, and a…
Having amazing string capabilities is more important now than ever. But that actually argues against including regex in the language syntax itself. You want regular expressions to be able to evolve to become ever more powerful and useful.
So just include a literal string type in the language itself--one that minimizes the need for escapes and can be used for all sorts of protocols--and use a regex library. The syntaxes of the library and the language can then evolve somewhat independently, and if it reaches a point where you need a non-backwards-compatible change in the regular expression syntax for some great new innovation, people who still need the old one can continue to import the old library, while others can import the new one.
The freedom of technologies to work together yet evolve independently is an important "feature" that's worth protecting.
Re: Regex in Swift
#19From the radar issue submission:
>Any modern language should natively support regular expression literals
Regex literals add needless complexity to the language, and tie it with a specific regex implementation, with no real benefit.
Just because Perl/JS/Ruby have this kludge, doesn't mean a modern language "should" have it.
Now, a way to write unescaped strings (e.g not having to escape all the regex operators like \ etc), that I can stand behind.
Re: Regex in Swift
#20> once Apple reads my radar and implements /regex/ literal syntax
jesus, get over yourself.