Regex in Swift • Hacker News Board

Re: Regex in Swift

#21

Post by kbenson » Fri, Jun 13, 2014, 6:45 PM UTC

jonhohle wrote: post #13

solomone wrote: post #7

Custom 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 think the divide has a lot to do with those who have written or encountered codebases where operator overloading was used in well-meaning but ultimately confusing and error prone ways, and how they reacted to that.

Like many language arguments, I think it distills down to those that believe that when looking at any piece of code, it should be immediately apparent what's going on or where to look to find that out even without much knowledge about the codebase even at the expense of more code and having to scroll around to see it all, and those that believe that reducing the overall size of the code to be seen to it's more concise if better, even at the expense of requiring a bit more foreknowledge of the codebase.

The extreme examples of this are probably Java at one end, and APL on the other. Less extreme examples are probably Python and Perl.

I don't think it's right to say either is better than the other. They both have obvious benefits and costs. Unfortunately, I think those cost/benefit ratios are often changed because of outside forces, such as business demands that change how much time or how often a codebase is worked on and by who, so the initial impression of the programmers accessing this code is greatly swayed by the circumstances that they first see it in.

Re: Regex in Swift

#22

Post by rz2k » Fri, Jun 13, 2014, 6:57 PM UTC

chc wrote: post #4

AaronFriel wrote: post #2

There 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…

I don't think regexp support has a lot to do with being "stringly typed". In fact, regular expressions are one of the best tools to avoid that antipattern in scripting languages, because they allow you to easily analyze string input and construct an internal representation from it. I think it's more that most of the scripting languages originally grew around the task of text processing (e.g. as system scripts), so th…

I think that is a good point, and one that comes up when working with SQL. Even though the relational algebra does joins by the name of attributes, and it's common to filter according to patterns, parameterized statements are an important best practice.

Re: Regex in Swift

#23

Post by kbenson » Fri, Jun 13, 2014, 7:00 PM UTC

sparkie wrote: post #17

jonhohle wrote: post #13

Earlier quoted context omitted.

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, wher…

Like everything, it's a trade-off. Here's an example of something I've been envious of Haskell about for a while: https://bitbucket.org/xnyhps/haskell-unittyped/wiki/Examples

There's times where it really does make stuff much more readable. It's about finding and taking advantage of those times.

Re: Regex in Swift

#24

Post by ewindisch » Fri, Jun 13, 2014, 7:03 PM UTC

AaronFriel wrote: post #2

There 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…

I'm only aware of TCL being the great "stringly typed" language. In TCL, everything is a string.

http://en.wikibooks.org/wiki/Tcl_Programming/Introduction#Da...

Re: Regex in Swift

#25

Post by eridius » Fri, Jun 13, 2014, 7:06 PM UTC

This feature is crying out for procedural macro support, not for being built into the language. For comparison, Rust has compile-time regular expressions (which, I will note, this blog post does not do; it's all runtime-parsed), implemented as a separate library that ships with Rust, using the procedural macro support (also called syntax extensions). This means the compiler and the language spec knows _nothing_ about regular expressions, and only the library libregex knows anything about it, and if you don't link against libregex, your program has no knowledge about it.

This ends up looking like the following:

    #![feature(phase)] // feature-gate for syntax extensions
    #[phase(plugin)] // tells the compiler the following crate has syntax extensions
    extern crate regex_macros; // a crate is a rust library. this one provides the syntax extension
    extern crate regex; // this one provides the runtime support for regular expressions

    fn main() {
        let re = regex!(r"^\d{4}-\d{2}-\d{2}$"); // compile-time regular expression
        assert_eq!(re.is_match("2014-01-01"), true);
    }

That `regex!(...)` call will trigger the compile-time syntax extension to parse the regular expression, throw a compile-time error if the parsing fails, and otherwise expand to an inline data structure that contains the runtime representation of the parsed regular expression. Even better, it generates native Rust code for various bits of the matching process, instead of relying on the generalized implementation used for runtime-parsed regular expressions, which means it's actually faster to use a compile-time regex. The downside is, of course, that it's generating specialized code for each one, so this can bloat your binary if you use a lot of regular expressions, but on the upside turning on Link-Time Optimization can get rid of a lot of this overhead.

Re: Regex in Swift

#26

Post by mopsled » Fri, Jun 13, 2014, 7:09 PM UTC

zemo wrote: post #20

> once Apple reads my radar and implements /regex/ literal syntax jesus, get over yourself.

That seemed tongue-in-cheek to me.

Re: Regex in Swift

#27

Post by danudey » Fri, Jun 13, 2014, 7:21 PM UTC

SiVal wrote: post #18

AaronFriel wrote: post #2

There 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 syntax…

Aside from these reasons, you also have the case of performance optimization. In Perl, for example, pretty much all string parsing (that I've ever seen done in Perl code) is done via regular expressions. Regular expressions in Perl are such a thing that most software I've used that uses regular expressions uses the Perl-compatible regular expression library (libpcre).

The issue is that if you provide developers with a simple method of e.g. splitting a string using regular expressions, then they will always split their strings with regular expressions. This is rarely the most optimal way of doing it, however, and it requires more memory and more overhead than e.g. splitting a string by simply scanning it.

The reason this is a problem for Swift in particular is mobile devices, where memory and CPU use is more costly than on desktop software.

I don't think it's coincidence that all the languages I'm aware of which natively support regexes as part of the language syntax are interpreted/scripting languages where performance is not the language's primary concern (Python being one such language with this syntax notably absent), whereas the language that the grandparent comment listed for 'safer languages' which do not have regex literal support ("Java, C#, Go, Rust, Haskell, or to be charitable, C++") are all compiled languages where performance is assumed to be part of the primary concern for the language design and for developers in the language.

Re: Regex in Swift

#28

Post by subdigital » Fri, Jun 13, 2014, 7:26 PM UTC

kenferry wrote: post #14

The 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") } That's existing Cocoa API; in Swift (hopefully!) the API can be updated to return nil if there's no match, so that it can read if let match = name.ran…

Thanks, included this in the post.

Re: Regex in Swift

#29

Post by benniw » Fri, Jun 13, 2014, 9:28 PM UTC

coldtea wrote: post #19

From 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…

There are real benefits, they're called convenience and compatibility.

And what's wrong with tying a language to a specific regex syntax? After all, you're also tying it top a specific outside-of-regexes syntax.

Regexes are also code, they just happens to be written in a different sub-language than the rest of the program.

Re: Regex in Swift

#30

Post by Someone » Fri, Jun 13, 2014, 11:29 PM UTC

jonhohle wrote: post #13

solomone wrote: post #7

Custom 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…

Because function calls all are prefix and all use exactly the same way to indicate nesting (parentheses) and argument separation.

I am in the camp that wants the power to define operators on new types, but I am not that sure about new operators.

For example, if Swift's implementation matches its documentation, one could make /"\\d{3,6}"/ a way to specify a regex:

- define a prefix operator /

- define a suffix operator /

- define prefix /(string s) to return some builder object that remembers that string

- define suffix /(builder b) to take the string that the builder remembered and produce a regex from it.

With appropriate precedence, that makes

   /"\\d{3,6}"/

parse as

  - Take the string "\\d{3,6}"

  - Send it to the prefix operator /

  - Send what comes out to suffix operator /

Unfortunately, that's all done at run time (or at least, users cannot enforce that the compiler does it at compile time), and of course, it would work with any string, for example:

   /"\\d{3,6}" + myStringFunction("test")/

(Again, with good choice for operator precedence)

Ugly or genius? That is all in the eye of the beholder.

I am sure that techniques like this can earn you high marks in obfuscated Swift competitions, however (tip for beginners: one can define prefix operators // and /* that allow one to hide code in what look like comments)