Regex features missing readable version

[matter123]

Because of the maximal munch rule lex.pptoken/3.3 The grammar needs a way to mark quantifiers as possessive or lazy.

I had some thoughts for what the call would look like

possessive(oneOrMoreOf(/foo/))

oneOrMoreOf(/foo/).posessive()

oneOrMoreOf(match: /foo/, type: :posessive)

oneOrMoreOfPosessive(/foo/)

Advantages:
1 & 2. minimizes code repetition
3. one of the cleanest looking
4. matches the pattern established by lookarounds

Disadvantages:
1 & 2. requires unwrapping the non-capturing group
2. confusing that .posessive() applies to the preceding element
3. requires specifying match: unlinks the fact that possessive applies to the match not the pattern
4. create a total of 9 functions for qualifiers

@jeff-hykin thoughts?

[matter123]

For reference number 2 is

    def posessive()
        self_as_string = self.without_default_mode_modifiers
        index = self_as_string[-1] == ')' ? -2 : -1
        if not /[+*?}]/ =~ self_as_string[index]
            raise "\n\n attempted to make a non quantifier pattern posessive\npattern is #{self_as_string}"
        end
        new_regex = /#{self_as_string.insert(index, '+')}/
        
        new_regex.group_attributes = self.group_attributes
        return new_regex
    end

number 3 is

modifier = ""
if attributes[:type] == nil or attributes[:type] == :greedy
    # pass
elsif attributes[:type] == :posessive
    modifier = "+"
elsif attributes[:type] == :lazy
    modifier = "?"
else
    raise "\n\n argument :type is not :posessive, :greedy :lazy\nregex: #{self.without_default_mode_modifiers}\arguments: #{attributes}"
end
attributes.delete(:type)

then interpolating modifer into maybe, oneOrMoreOf, and zeroOrMoreOf's constructed regexps

1 &4 should just be modifications upon those

[matter123]

This is blocking some aspects of #135 as :scope_resolution can backtrack and cause the lookBehindToAvoids to succeed when it shouldn't.

[jeff-hykin]

Sorry, I haven't gotten to this yet. My finals end on Tue so hopefully I'll be able to find more time after they're over.

[jeff-hykin]

I'm going to explore this on the plane ride, its a tough choice between them. I'd like there to be an explicit way of doing it, even though right now all of them are implicitly greedy by default. It is probably too wordy for them to all be explicit though.

I'm also going to think about a way to handle repetition ranges like a{1,3}

[matter123]

For repetition I was thinking:

For exactly 3 times

.many(
    count: 3,
)

For up to 3 times

.many(
    max: 3,
)

For 3 or more times

.many(
    min: 3,
)

For 1 to 3 times

.many(
    min: 1,
    max: 3,
)

[jeff-hykin]

That looks great. My only concern with the .many() and the oneOrMoreOf(/foo/).posessive() is that its a bit confusing that some of the .things are like a sentence /thing/.then().then() but then these (the .many() and .posessive()) are going to be an anti-pattern to sentence-like-methods.

If there was a way to distinguish them syntactically it would be great.

[matter123]

I should have been more clear, sorry. I was thinking that many follows the way zeroOrMoreOf and maybe do.

Example.

ref_deref_pattern = zeroOrMoreOf (/\*/).many(match: /&/, max: 2)

[matter123]

As far as distinguishing maybe .posessive!() to mark that the method modifies the regex "more" than the normal helpers do.

Edit: this is a bad choice, because .posessive() ultimately is a functional function`

In the example below:

a = oneOrMoreOf(/foo/)
b = a.posessive!

One would expect a to be posessive as well.

[matter123]

Alternatively, functions that modify the previous pattern could be an adjective e.g .posessively(). as in "match zero or more of /foo/, possessively"

[matter123]

The following features from Oniguruma Regular Expressions do have a readable version:

• repetition
  • currently needed
• reluctant/possessive modifiers
  • currently needed
• Last match anchor (\G)
  • currently used
  • not sure it can be made more readable).
• start/end of line anchors (^$)
  • used
  • pretty readable if you know regex
  • not sure $ even works, \n is used everywere instead, might be a reason to have a readable version
• Other anchors (\A, \Z, \z, \b, \B)
  • not really used
• character class
  • used
  • pretty readable, would be hard to make more readable
• comments
  • not needed
• atomic groups
  • could be useful
• subexp calls
  • useful (see Bad coloring of CRTP inheritance with templated child class #314)