Read on Twitter
Do you think pcre syntax was designed by humans, or was it machine evolved?
i am a regular expression syntax designed by:
https://abs.twimg.com/emoji/v2/... draggable="false" alt="⚪️" title="Weißer Kreis" aria-label="Emoji: Weißer Kreis"> humans
https://abs.twimg.com/emoji/v2/... draggable="false" alt="⚪️" title="Weißer Kreis" aria-label="Emoji: Weißer Kreis"> machines
https://abs.twimg.com/emoji/v2/... draggable="false" alt="🔘" title="Optionsfeld" aria-label="Emoji: Optionsfeld"> beelzebub, Lord of the flies (but not the one that& #39;s currently trending at the moment, that& #39;s a good fly brent)
okay, so we know pcre supports recursion, and that means it& #39;s a CFG with some other class of language that is a superset of regular languages, so pcre syntax isn& #39;t *regular* expressions. that& #39;s not news, that& #39;s a semantic choice. I don& #39;t have a syntatic beef with that.
would you like some syntatic beef? because I have some. oh goodness me do I have some
You know how some languages have a "everything is a ..." kind of approach? everything is a list, everything is an object, everything is a segfault. that sort of thing. pcre is essentially an experiment in "can we make a language where everything is a special case?"
for example:
for example:
So like you know backreferences exist. Those are famous. the syntax for them is like \n where n is a unsigned integer. That& #39;s not *regular*, but it& #39;s what pcre has. right? well let& #39;s see what the documentation says about that.
*MIGHT* be a backreference.
It& #39;s only a backreference if you have that many capturing groups! To parse this syntax, the meaning depends on the state you populate during parse.
It& #39;s like typedef when parsing C, where the lexical token depends on what& #39;s in your symbol table.
It& #39;s only a backreference if you have that many capturing groups! To parse this syntax, the meaning depends on the state you populate during parse.
It& #39;s like typedef when parsing C, where the lexical token depends on what& #39;s in your symbol table.
oh pcre documentation, I know the feeling
Is your syntax too difficult to remember? add 2× more syntax! parsing this is easy if you& #39;re a computer, they& #39;re aliases in the lexer. There are a *lot* of aliases in the lexer.
e.g. in our implementation, we have special tokens for the start and end of [xyz] classes:
& #39;[& #39; .. & #39;]& #39; — simple case, only ^ and - change meaning depending on their locations
& #39;[^& #39; .. & #39;]& #39;
& #39;[]& #39; .. & #39;]& #39; — A
& #39;[^]& #39; .. & #39;]& #39; — B
To have a CFG, ] needs a different token type for A and B
& #39;[& #39; .. & #39;]& #39; — simple case, only ^ and - change meaning depending on their locations
& #39;[^& #39; .. & #39;]& #39;
& #39;[]& #39; .. & #39;]& #39; — A
& #39;[^]& #39; .. & #39;]& #39; — B
To have a CFG, ] needs a different token type for A and B
This is bullshit nuts stuff, just to be clear. If someone asks you "what& #39;s the grammar for pcre? can you write it down as BNF please?" the answer is yes, you can write it down as BNF, but only as long as you don& #39;t also want the terminals for it.
All attempts to do this are lies.
All attempts to do this are lies.
perl and pcre disagree in a couple of places.
The first sentence here speaks for itself:
> the use of \K withn assertions is "not well defined"
Fantastic.
But I& #39;m here for the start of the match being after the end of the match. Great API! \10 out of \10 developer experience.
The first sentence here speaks for itself:
> the use of \K withn assertions is "not well defined"
Fantastic.
But I& #39;m here for the start of the match being after the end of the match. Great API! \10 out of \10 developer experience.
There are features that everybody agrees should not exist, \C is one of those. It matches *part* of a utf8 sequence (or whatever encoding).
So there& #39;s unity here. Unfortunately it does exist. But it& #39;s disallowed in lookbehind assertions because it& #39;s completely meaningless there.
So there& #39;s unity here. Unfortunately it does exist. But it& #39;s disallowed in lookbehind assertions because it& #39;s completely meaningless there.
There& #39;s a bunch of other little things that you probably know about, from being impossible to get right when using pcre. I didn& #39;t want to talk about that stuff here. Comment about them if you like.
My perspective is just about parsing pcre. I don& #39;t write regexps very often.
My perspective is just about parsing pcre. I don& #39;t write regexps very often.
I guess you can see why.
