On Fri, 22 Nov 2024 12:47:16 +0100, Janis Papanagnou wrote:

> On 21.11.2024 23:05, Lawrence D'Oliveiro wrote:
>
>> Another handy one is “\b” for word boundaries.
>
> I prefer \< and \> (that are quite commonly used) for such structural
> things ...

“\<” only matches the beginning of a word, “\>” only matches the end,
“\b” matches both
<https://www.gnu.org/software/emacs/manual/html_node/emacs/Regexp-Backslash.html>.

On Fri, 22 Nov 2024 18:18:04 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> gabbled:
>On 2024-11-22, Muttley@DastartdlyHQ.org <Muttley@DastartdlyHQ.org> wrote:
>> Its not that simple I'm afraid since comments can be commented out.
>
>Umm, no.

Umm, yes, they can.

>> eg:
>>
>> // int i; /*
>
>This /* sequence is inside a // comment, and so the machinery that
>recognizes /* as the start of a comment would never see it.

Yes, thats kind of the point. You seem to be arguing against yourself.

>> A C99 and C++ compiler would see "int j" and compile it, a regex would
>> simply remove everything from the first /* to */.
>
>No, it won't, because that's not how regexes are used in a lexical

Yes, it will.

>> Also the same probably applies to #ifdef's.
>
>Lexically analyzing C requires implementing the translation phases
>as described in the standard. There are preprocessor phases which
>delimit the input into preprocessor tokens (pp-tokens). Comments
>are stripped in preprocessing. But logical lines (backslash
>continuations) are recognized below comments; i.e. this is one
>comment:

Not sure what your point is. A regex cannot be used to parse C comments because
its doesn't know C/C++ grammar.

On 11/20/2024 9:53 AM, Janis Papanagnou wrote:
> On 20.11.2024 12:46, Ed Morton wrote:
>>
>> Definitely. The most relevant statement about regexps is this:
>>
>>> Some people, when confronted with a problem, think "I know, I'll use
>>> regular expressions." Now they have two problems.
>
> (Worth a scribbling on a WC wall.)
>
>>
>> Obviously regexps are very useful and commonplace but if you find you
>> have to use some online site or other tools to help you write/understand
>> one or just generally need more than a couple of minutes to
>> write/understand it then it's time to back off and figure out a better
>> way to write your code for the sake of whoever has to read it 6 months
>> later (and usually for robustness too as it's hard to be sure all rainy
>> day cases are handled correctly in a lengthy and/or complicated regexp).
>
> Regexps are nothing for newbies.
>
> The inherent fine thing with Regexps is that you can incrementally
> compose them[*].[**]
>
> It seems you haven't found a sensible way to work with them?
> (And I'm really astonished about that since I know you worked with
> Regexps for years if not decades.)

I have no problem working with regexps, I just don't write lengthy or
complicated regexps, just brief, simple BREs or EREs, and I don't
restrict myself to trying to solve problems with a single regexp.

> In those cases where Regexps *are* the tool for a specific task -
> I don't expect you to use them where they are inappropriate?! -

Right, I don't, but I see many people using them for tasks that could be
done more clearly and robustly if not done with a single regexp.

> what would be the better solution[***] then?

It all depends on the problem. For example, if you need to match an
input string that must contain each of a, b, and c in any order then you
could do that in awk with this regexp or similar:

awk '/(a.*(b.*c|c.*b))|(b.*(a.*c|c.*a))|(c.*(a.*b|b.*a))/'

or you could do it with this condition comprised of regexp segments:

awk '/a/ && /b/ && /c/'

I would prefer the second solution as it's more concise and easier to
enhance (try adding "and d" to both).

As another example, someone on StackOverflow recently said they had
written the following regexp to isolate the last string before a set of
parens in a line that contains multiple such strings, some of them
nested, and they said it works in python:

^(?:^[^(]+\([^)]+\)
\(([^(]+)\([^)]+\)\))|[^(]+\(([^(]+)\([^)]+\),\s([^\(]+)\([^)]+\)\s\([^\)]+\)\)|(?:(?:.*?)\((.*?)\(.*?\)\))|(?:[^(]+\(([^)]+)\))$

I personally wouldn't consider anything remotely as lengthy or
complicated as that regexp despite their assurances that it works, I'd
use this any-awk script or similar instead:

{
rec = $0
while ( match(rec, /\([^()]*)/) ) {
tgt = substr($0,RSTART+1,RLENGTH-2)
rec = substr(rec,1,RSTART-1) RS substr(rec,RSTART+1,RLENGTH-2)
RS substr(rec,RSTART+RLENGTH)
}
gsub(/ *\([^()]*) */, "", tgt)
print tgt
}

It's a bit more code but, unlike that regexp, anyone assigned to
maintain this code in future can tell what it does with just a little
thought (and maybe adding a debugging print in the loop if they aren't
very familiar with awk), can then be sure it does what is required and
nothing else, and could easily maintain/enhance it if necessary.

Ed.

>
> Janis
>
> [*] Like the corresponding FSMs.
>
> [**] And you can also decompose them if they are merged in a huge
> expression, too large for you to grasp it. (BTW, I'm doing such
> decompositions also with other expressions in program code that
> are too bulky.)
>
> [***] Can you answer the question that another poster failed to do?
>