Regex flags

Any flag can be specified inside pattern:

"(?i)hello".r

creates regex that matches both "hello" and "HELLO". Look at
java.util.Pattern spec.

S.

On Sat, Dec 20, 2008 at 19:09, Matt Weaver wrote:
> Hi,
>
> I'm trying to create a combinator parser with a case-insensitive rule. It
> seems to me like the easiest way to accomplish this should be to create a
> regex rule with the case insensitive flag set. Unfortunately, the
> scala.util.matching.Regex class doesn't seem to have any way to pass flags
> into the underlying java Parser. I created this workaround:
>
> class FlaggedRegex(regex: String, flags: Int)
> extends Regex(regex) {
> override val pattern = Pattern.compile(regex, flags)
> }
>
> object FlaggedRegex {
> val UnixLines: Int = 1
> val CaseInsensitive: Int = 2
> val Comments: Int = 4
> val MultiLine: Int = 8
> val Literal: Int = 16
> val DotAll: Int = 32
> val UnicodeCase: Int = 64
> val CanonEq: Int = 128
> }
>
> class FlaggedRegexString(value: String) {
> def rf(flags: Int): FlaggedRegex = new FlaggedRegex(value, flags)
> }
>
> object FlaggedRegexString {
> implicit def stringToFlaggedRegexString(value: String): FlaggedRegexString
> =
> new FlaggedRegexString(value)
> }
>
> This works, but it would be nice if it were built into the standard
> library. Specifically, it would be cleaner if RichString's r method were
> overloaded to optionally allow flags to be passed; I couldn't name the rf
> method r because it makes the conversion ambiguous.
>
> I can't think of any reason this functionality couldn't be rolled into the
> built-in Regex class, with an extra constructor so that existing code
> doesn't break. Is there any chance of this happening in a future version?
>

Thanks, that's a lot simpler than what I was attempting.

This solves my problem, but there are two flags (LITERAL and CANON_EQ)
that cannot be embedded. My personal opinion is still that there should
be a built-in way to pass explicitly pass flags, but I guess there are
plenty of workarounds so that it's not a big deal.

Thanks again for the help

Stepan Koltsov wrote:
> Any flag can be specified inside pattern:
>
> "(?i)hello".r
>
> creates regex that matches both "hello" and "HELLO". Look at
> java.util.Pattern spec.
>
> S.
>
> On Sat, Dec 20, 2008 at 19:09, Matt Weaver wrote:
>
>> Hi,
>>
>> I'm trying to create a combinator parser with a case-insensitive rule. It
>> seems to me like the easiest way to accomplish this should be to create a
>> regex rule with the case insensitive flag set. Unfortunately, the
>> scala.util.matching.Regex class doesn't seem to have any way to pass flags
>> into the underlying java Parser. I created this workaround:
>>
>> class FlaggedRegex(regex: String, flags: Int)
>> extends Regex(regex) {
>> override val pattern = Pattern.compile(regex, flags)
>> }
>>
>> object FlaggedRegex {
>> val UnixLines: Int = 1
>> val CaseInsensitive: Int = 2
>> val Comments: Int = 4
>> val MultiLine: Int = 8
>> val Literal: Int = 16
>> val DotAll: Int = 32
>> val UnicodeCase: Int = 64
>> val CanonEq: Int = 128
>> }
>>
>> class FlaggedRegexString(value: String) {
>> def rf(flags: Int): FlaggedRegex = new FlaggedRegex(value, flags)
>> }
>>
>> object FlaggedRegexString {
>> implicit def stringToFlaggedRegexString(value: String): FlaggedRegexString
>> =
>> new FlaggedRegexString(value)
>> }
>>
>> This works, but it would be nice if it were built into the standard
>> library. Specifically, it would be cleaner if RichString's r method were
>> overloaded to optionally allow flags to be passed; I couldn't name the rf
>> method r because it makes the conversion ambiguous.
>>
>> I can't think of any reason this functionality couldn't be rolled into the
>> built-in Regex class, with an extra constructor so that existing code
>> doesn't break. Is there any chance of this happening in a future version?
>>
>>

The second that, also see http://lampsvn.epfl.ch/trac/scala/ticket/1482.

Matt Weaver wrote:
> I can't think of any reason this functionality couldn't be rolled into
> the built-in Regex class, with an extra constructor so that existing
> code doesn't break. Is there any chance of this happening in a future
> version?