no it's genius
there is nothing wrong with backtracking implementations but most pattern matching tasks don't locaically require a lot of backtracking
additionally, regex engine with a backtracking implementations have some control over how backtracking is done and you can use that, so if your regex matches take too long it's a skill issue
it's not different that for loops or recursion, you can easily conceive a shitty program with polynomial or exponential time but that does not mean it will be good. with regex it's extremely easy to write a pattern requiring an exponential amount of time, it's your job to make it smaller than that, don't blame the tool
>regex be made high level
what do you mean? I mean regex are already declarative, they can't be more higher level than that
however, if regex engines were augmented to be instead proper parsers I think it would make a night and day difference because then you would use it for "completely" parsing entire strings and the patterns would be saner and it would require way way less backtracking. When you switch your brain to parsing logic, most of them time when you want to match several subpatterns, the quantifier is implicity possessive (+ possessive quantifier modifier) and when you "call" a pattern/rule that rule is also implicity surounded by (?> ), that is, if you have the sequence A B C, and that the subrules A and B matches but C fails, the entire sequence A B C fails and you do not backtrack back into B and then A.
2 weeks ago
Anonymous
i mean high level as in programming languages ment to be human readable.
2 weeks ago
Anonymous
it is human readable, it's just that there is a special expression syntax with special operators and precedences
the syntax is basically the same as the one of PEG parsers and I've never heard anyone complain about them, on the contrary. if you can't read them it's either that you don't have the basics or that the regex you're trying to understand are messy, or that you don't recognize the few common regex patterns/idioms
2 weeks ago
Anonymous
no it isn;t.
2 weeks ago
Anonymous
there are only 3 precedence levels, arithmetic expressions have more than that
2 weeks ago
Anonymous
high and low level language are not just about how they are computed they are about the end user experiance. A high level language needs to be human readable, regex is not, you cannot intuit the logical meaning of regex, you just have to learn what everything means. meanwhile I may not be a math major and a complete codlet besides but I can still understand what an if statement looks like in almost every high level language. it's going to start with the words IF, and then go on to have some kind of operation, using some kind of operators.
then it passes the output.
this is HUMAN readable. in other words I dont have to know any of the syntax rules to pick out what it means.
Regex on the other hand is all archaic syntax rules designed to be operated on in systems with a very limited amount of ram and character space. it is basically the assembly if filtering shit.
2 weeks ago
Anonymous
>I've never heard anyone complain about them
Midwits filtered by regex don't even try to use more advanced parsing tools.
The syntax. Making the "language" a mess of special characters. The syntax at the very least shouldn't mix text to be matched and control characters, just like you have to quote strings in every sane programming language.
2 weeks ago
Anonymous
>quoted strings
I can agree to that. Quoted string + non significant whitespace by default would be nice, like in perl6's regexes.
high and low level language are not just about how they are computed they are about the end user experiance. A high level language needs to be human readable, regex is not, you cannot intuit the logical meaning of regex, you just have to learn what everything means. meanwhile I may not be a math major and a complete codlet besides but I can still understand what an if statement looks like in almost every high level language. it's going to start with the words IF, and then go on to have some kind of operation, using some kind of operators.
then it passes the output.
this is HUMAN readable. in other words I dont have to know any of the syntax rules to pick out what it means.
Regex on the other hand is all archaic syntax rules designed to be operated on in systems with a very limited amount of ram and character space. it is basically the assembly if filtering shit.
so your major problem is syntax and no semantics?
imo you haven't use them enough, it becomes intuitive after a while. you must use the extended syntax though it makes a night and day difference, like here
based fellow perl chad
perl make it so easy to use them, practice them and reuse them
the qr// construct make the control flow super clear and super easy to modify
my $re_url = qr{
A
(?:https?://)?
(?:www.)?
......
.*
z
}x;
while (@ARGV) {
$_ = shift;
if (/$re_url/) {
push @urls, {
url => "https://www.....com/../$1",
id => $1,
};
}
...
}
I don't agree with you about an alternate syntax using if keywords because then literally 80% of the letters would be if-s or and-s because that's what regex, parsing and logic DSL do. It's a shit loads of IF, AND and OR and JUMP (for quantifiers). There is no point in writing IF because every single regex subexpression except is capturing groups is a conditional and thise conditionals are all ANDed together. Quantifiers are loops so they also contain a conditional just like C for/while loops contain a conditional if you look at the assembly.
Here's what it looks like with IFs everywhere (ANDs are implicit)
/^ab(c|d)$/
if (!(ptr < end && *ptr == 'a')) {
return false;
}
ptr++;
if (!(ptr < end && *ptr == 'b')) {
return false;
}
ptr++;
if (ptr < end && *ptr == 'c') {
ptr++;
}
else if (ptr < end && *ptr == 'd') {
ptr++;
}
else {
return false;
}
if (ptr != end) {
return false;
}
return true;
}
2 weeks ago
Anonymous
>imo you haven't use them enough!!!!
tools are meant to be easy to use.
2 weeks ago
Anonymous
well go ahead and describe the syntax you want for a search tool that would have the same semantics as regexes
2 weeks ago
Anonymous
I already told you. there are literally too many examples to be worth listing, you are simply determined to be aloof and standoffish.
2 weeks ago
Anonymous
you only told me about quoted strings and that you'd like 'if' keywords, nothing more precise than that
I mean I challenge you to come up with a good alternative syntax for regexes. I've seen libraries on github that use a function-like syntax instead of quantifiers and the whole thing is unreadable, unlike regexes where with a quick glance you know the basic structure of the pattern
say, how much regexes did you wrote and for how long?
2 weeks ago
Anonymous
>yeah, and I'm gonna KEEP being standoffish and aloof regardless of how obvious it is that I am right next to the water and wont drink it
Okay, but for everyone else ,it's abjectly obvious what I meant, to the point that others in the thread said the same thing, while you try to weave obsfucation and circles. it's that The syntax and readability is bad, and that you need to be able to use it like a high level programming language, of which there are hundreds of examples I wont bother listing.
Except for very simple cases (which can be done with glob matching) we don't have anything better for what it does. Once things get more complicated than what a regex does, it's probably time to put on the big boy pants and use a true parser.
Technically there are levels of complexity between those two, but they're not usually useful in practice. And are very easy to code up with some regexes and a counter or stack.
I've never understood all the b***hing about regex, it's not that hard. If you are dealing with a super hard problem in regex, the problem probably lies upstream and isn't regex's fault.
regex dindu nuffin'
based fellow perl chad
perl make it so easy to use them, practice them and reuse them
the qr// construct make the control flow super clear and super easy to modify
my $re_url = qr{
A
(?:https?://)?
(?:www.)?
......
.*
z
}x;
based fellow perl chad
perl make it so easy to use them, practice them and reuse them
the qr// construct make the control flow super clear and super easy to modify
my $re_url = qr{
A
(?:https?://)?
(?:www.)?
......
.*
z
}x;
sure
I'll ask chat
(([^()]*+(?:(?R)[^()]*)*+))
heres the regex
heres the human readable output.
function match_nested_parentheses(expression):
function match_nested_parentheses(expression):
# Initialize a stack to keep track of opening parentheses
stack = []
# Iterate through each character in the expression
for character in expression:
if character == '(':
# Push to stack when an opening parenthesis is found
stack.append(character)
elif character == ')':
if not stack:
# If stack is empty and a closing parenthesis is found, it's unbalanced
return False
# Pop from stack when a closing parenthesis matches an opening one
stack.pop()
# If stack is empty, all parentheses are matched correctly
return len(stack) == 0
# Example usage
expression = "(a(b)c(d(e)f)g)"
result = match_nested_parentheses(expression)
print("Balanced parentheses:", result)
the language used was instructed to be psuedocode but it should suffice for simply demonstrating what readable programming looks like. now that chat exists unless I'm searching for e-girlvorepic555 I probably wont have need to learn regex anyway but you get the idea
>yeah, and I'm gonna KEEP being standoffish and aloof regardless of how obvious it is that I am right next to the water and wont drink it
Okay, but for everyone else ,it's abjectly obvious what I meant, to the point that others in the thread said the same thing, while you try to weave obsfucation and circles. it's that The syntax and readability is bad, and that you need to be able to use it like a high level programming language, of which there are hundreds of examples I wont bother listing.
yes I think regex syntax is mostly nice obviously
you think it's gross which is your right, I'm asking you to come up with an alternative syntax
I've took the effort to show you what it looks like when you write ifs manually
>quoted strings
I can agree to that. Quoted string + non significant whitespace by default would be nice, like in perl6's regexes.
[...]
so your major problem is syntax and no semantics?
imo you haven't use them enough, it becomes intuitive after a while. you must use the extended syntax though it makes a night and day difference, like here [...]
I don't agree with you about an alternate syntax using if keywords because then literally 80% of the letters would be if-s or and-s because that's what regex, parsing and logic DSL do. It's a shit loads of IF, AND and OR and JUMP (for quantifiers). There is no point in writing IF because every single regex subexpression except is capturing groups is a conditional and thise conditionals are all ANDed together. Quantifiers are loops so they also contain a conditional just like C for/while loops contain a conditional if you look at the assembly.
Here's what it looks like with IFs everywhere (ANDs are implicit)
/^ab(c|d)$/
if (!(ptr < end && *ptr == 'a')) {
return false;
}
ptr++;
if (!(ptr < end && *ptr == 'b')) {
return false;
}
ptr++;
if (ptr < end && *ptr == 'c') {
ptr++;
}
else if (ptr < end && *ptr == 'd') {
ptr++;
}
else {
return false;
}
if (ptr != end) {
return false;
}
return true;
}
>you need to be able to use it like a high level programming language, of which there are hundreds of examples I wont bother listing.
you won't bother listing because, unless you prove me wrong, the various syntax families of exising languages (C-like syntax, ML/Haskell-like syntax, etc...) would look horrible for regexes and in the case of a C-like syntax, the regex syntax would become... a C-like syntax.
Like I said, try to write 'if' everytime the regex engine does a comparison and the resulting "regex" will be exactly an imperative program, aka no syntax sugar at all, which also mean that you do all the work.
If you don't like the operator syntax, there isn't much else to do to replace them with a S-exp or function-style syntax.
>you think it's gross which is your right, I'm asking you to come up with an alternative syntax
not my problem.
2 weeks ago
Anonymous
>not my problem.
but it is your problem, it's you who want something better
2 weeks ago
Anonymous
no, like I said, I have a better tool now. you slept on your arrogance like most autistic holier than thou tards and someone you couldn't have predicted made your tool obsolete. I am just here to tell you where the weaknesses are.
2 weeks ago
Anonymous
if you have something to say about semantics go ahead already. it's eas to ramble about syntax but in the end it's not that interesting >I am just here to tell you where the weaknesses are.
right now you talked about nothing except syntax, so if the big weakness is the syntax, whatever
2 weeks ago
Anonymous
>nooo you need to answer MY specific question
your question doesn't matter because I cant understand it, remove the spike sticking out of the handle of your tool, or i'll just get my robot to use it for me, she's immune to spikes being made of metal.
2 weeks ago
Anonymous
I'm not asking you any question you tard. You say you have something interesting to say so say it already BEFORE I PISS MYSELF
2 weeks ago
Anonymous
Feel free to urinate all you want, its not my floor.
>(([^()]*+(?:(?R)[^()]*)*+))
the absence of whitespace and of identifiers is what make it unreadable, and when all that is covered you need to know a normal parser matching this would work which can be hard if you're not well versed in parsing and in recursion. if you're not good with both then you are simply not logically equiped with understanding this regex and this has nothing to do with regexes
#!/usr/bin/perl
use strict;
use warnings;
use v5.10;
my $re = qr{
A (?¬_parens) (?&parens) (?¬_parens) z
(?(DEFINE)
(?<parens>
( (?¬_parens) (?: (?&parens) (?¬_parens) )*+ )
)
i must empty my balls in her womb
this
>her
its an empty picture
Regex is a really shitty DSL. The concept is good, the implementation is most awful.
no it's genius
there is nothing wrong with backtracking implementations but most pattern matching tasks don't locaically require a lot of backtracking
additionally, regex engine with a backtracking implementations have some control over how backtracking is done and you can use that, so if your regex matches take too long it's a skill issue
it's not different that for loops or recursion, you can easily conceive a shitty program with polynomial or exponential time but that does not mean it will be good. with regex it's extremely easy to write a pattern requiring an exponential amount of time, it's your job to make it smaller than that, don't blame the tool
I would much prefer regex be made high level.
>regex be made high level
what do you mean? I mean regex are already declarative, they can't be more higher level than that
however, if regex engines were augmented to be instead proper parsers I think it would make a night and day difference because then you would use it for "completely" parsing entire strings and the patterns would be saner and it would require way way less backtracking. When you switch your brain to parsing logic, most of them time when you want to match several subpatterns, the quantifier is implicity possessive (+ possessive quantifier modifier) and when you "call" a pattern/rule that rule is also implicity surounded by (?> ), that is, if you have the sequence A B C, and that the subrules A and B matches but C fails, the entire sequence A B C fails and you do not backtrack back into B and then A.
i mean high level as in programming languages ment to be human readable.
it is human readable, it's just that there is a special expression syntax with special operators and precedences
the syntax is basically the same as the one of PEG parsers and I've never heard anyone complain about them, on the contrary. if you can't read them it's either that you don't have the basics or that the regex you're trying to understand are messy, or that you don't recognize the few common regex patterns/idioms
no it isn;t.
there are only 3 precedence levels, arithmetic expressions have more than that
high and low level language are not just about how they are computed they are about the end user experiance. A high level language needs to be human readable, regex is not, you cannot intuit the logical meaning of regex, you just have to learn what everything means. meanwhile I may not be a math major and a complete codlet besides but I can still understand what an if statement looks like in almost every high level language. it's going to start with the words IF, and then go on to have some kind of operation, using some kind of operators.
then it passes the output.
this is HUMAN readable. in other words I dont have to know any of the syntax rules to pick out what it means.
Regex on the other hand is all archaic syntax rules designed to be operated on in systems with a very limited amount of ram and character space. it is basically the assembly if filtering shit.
>I've never heard anyone complain about them
Midwits filtered by regex don't even try to use more advanced parsing tools.
I didn't talk about backtracking. Though I prefer predictable performance of true regexes to that nightmare.
then wdym by "the implementation is most awful"?
The syntax. Making the "language" a mess of special characters. The syntax at the very least shouldn't mix text to be matched and control characters, just like you have to quote strings in every sane programming language.
>quoted strings
I can agree to that. Quoted string + non significant whitespace by default would be nice, like in perl6's regexes.
so your major problem is syntax and no semantics?
imo you haven't use them enough, it becomes intuitive after a while. you must use the extended syntax though it makes a night and day difference, like here
I don't agree with you about an alternate syntax using if keywords because then literally 80% of the letters would be if-s or and-s because that's what regex, parsing and logic DSL do. It's a shit loads of IF, AND and OR and JUMP (for quantifiers). There is no point in writing IF because every single regex subexpression except is capturing groups is a conditional and thise conditionals are all ANDed together. Quantifiers are loops so they also contain a conditional just like C for/while loops contain a conditional if you look at the assembly.
Here's what it looks like with IFs everywhere (ANDs are implicit)
/^ab(c|d)$/
bool match_pattern(char *input, size_t length) {
char *ptr = input;
char *end = input + lenght;
if (!(ptr < end && *ptr == 'a')) {
return false;
}
ptr++;
if (!(ptr < end && *ptr == 'b')) {
return false;
}
ptr++;
if (ptr < end && *ptr == 'c') {
ptr++;
}
else if (ptr < end && *ptr == 'd') {
ptr++;
}
else {
return false;
}
if (ptr != end) {
return false;
}
return true;
}
>imo you haven't use them enough!!!!
tools are meant to be easy to use.
well go ahead and describe the syntax you want for a search tool that would have the same semantics as regexes
I already told you. there are literally too many examples to be worth listing, you are simply determined to be aloof and standoffish.
you only told me about quoted strings and that you'd like 'if' keywords, nothing more precise than that
I mean I challenge you to come up with a good alternative syntax for regexes. I've seen libraries on github that use a function-like syntax instead of quantifiers and the whole thing is unreadable, unlike regexes where with a quick glance you know the basic structure of the pattern
say, how much regexes did you wrote and for how long?
>yeah, and I'm gonna KEEP being standoffish and aloof regardless of how obvious it is that I am right next to the water and wont drink it
Okay, but for everyone else ,it's abjectly obvious what I meant, to the point that others in the thread said the same thing, while you try to weave obsfucation and circles. it's that The syntax and readability is bad, and that you need to be able to use it like a high level programming language, of which there are hundreds of examples I wont bother listing.
Except for very simple cases (which can be done with glob matching) we don't have anything better for what it does. Once things get more complicated than what a regex does, it's probably time to put on the big boy pants and use a true parser.
Technically there are levels of complexity between those two, but they're not usually useful in practice. And are very easy to code up with some regexes and a counter or stack.
thank you eric and advent of parsing for teaching me proper regex
Sex with akari
who?
I've never understood all the b***hing about regex, it's not that hard. If you are dealing with a super hard problem in regex, the problem probably lies upstream and isn't regex's fault.
regex dindu nuffin'
I may be a brainlet but I will never undestand regex. I had to parse URL and it was easier without regex.
how are you guys so bad at this?
t. perl chad
based fellow perl chad
perl make it so easy to use them, practice them and reuse them
the qr// construct make the control flow super clear and super easy to modify
my $re_url = qr{
A
(?:https?://)?
(?:www.)?
......
.*
z
}x;
my $yt_video = qr{
(?: https? :// )?
(?: www. )?
(?:
youtu.be
/
(?<id> [w-]{11})
(?: ? S+)?
|
youtube.com
(?: /watch?v= | (?<short> /shorts/ ))
(?<id> [w-]{11})
(?: & S+)?
)
}x;
my $yt_playlist = qr{
(?: https? :// )?
(?: www. )?
youtube.com
/playlist?list= (?<id> [w-]+ )
(?: & S+)?
}x;
while (@ARGV) {
$_ = shift;
if (/$re_url/) {
push @urls, {
url => "https://www.....com/../$1",
id => $1,
};
}
...
}
isn't it called raku now?
no and no u pytoddler/rubygay/lispgay/luagay/phptard motherfricker
wow, regex so hard...
const regularExpression = /foo/g;
const string = 'table football, foosball';
let array1;
while ((array1 = regularExpression.exec(string)) !== null) {
console.log('Found ${array1[0]}');
}
I feel like such a chad for having no problems with regex and even enjoying it
also post an unreadable regex (the email one doesn't count)
sure
I'll ask chat
(([^()]*+(?:(?R)[^()]*)*+))
heres the regex
heres the human readable output.
function match_nested_parentheses(expression):
function match_nested_parentheses(expression):
# Initialize a stack to keep track of opening parentheses
stack = []
# Iterate through each character in the expression
for character in expression:
if character == '(':
# Push to stack when an opening parenthesis is found
stack.append(character)
elif character == ')':
if not stack:
# If stack is empty and a closing parenthesis is found, it's unbalanced
return False
# Pop from stack when a closing parenthesis matches an opening one
stack.pop()
# If stack is empty, all parentheses are matched correctly
return len(stack) == 0
# Example usage
expression = "(a(b)c(d(e)f)g)"
result = match_nested_parentheses(expression)
print("Balanced parentheses:", result)
the language used was instructed to be psuedocode but it should suffice for simply demonstrating what readable programming looks like. now that chat exists unless I'm searching for e-girlvorepic555 I probably wont have need to learn regex anyway but you get the idea
yes I think regex syntax is mostly nice obviously
you think it's gross which is your right, I'm asking you to come up with an alternative syntax
I've took the effort to show you what it looks like when you write ifs manually
>you need to be able to use it like a high level programming language, of which there are hundreds of examples I wont bother listing.
you won't bother listing because, unless you prove me wrong, the various syntax families of exising languages (C-like syntax, ML/Haskell-like syntax, etc...) would look horrible for regexes and in the case of a C-like syntax, the regex syntax would become... a C-like syntax.
Like I said, try to write 'if' everytime the regex engine does a comparison and the resulting "regex" will be exactly an imperative program, aka no syntax sugar at all, which also mean that you do all the work.
If you don't like the operator syntax, there isn't much else to do to replace them with a S-exp or function-style syntax.
>you think it's gross which is your right, I'm asking you to come up with an alternative syntax
not my problem.
>not my problem.
but it is your problem, it's you who want something better
no, like I said, I have a better tool now. you slept on your arrogance like most autistic holier than thou tards and someone you couldn't have predicted made your tool obsolete. I am just here to tell you where the weaknesses are.
if you have something to say about semantics go ahead already. it's eas to ramble about syntax but in the end it's not that interesting
>I am just here to tell you where the weaknesses are.
right now you talked about nothing except syntax, so if the big weakness is the syntax, whatever
>nooo you need to answer MY specific question
your question doesn't matter because I cant understand it, remove the spike sticking out of the handle of your tool, or i'll just get my robot to use it for me, she's immune to spikes being made of metal.
I'm not asking you any question you tard. You say you have something interesting to say so say it already BEFORE I PISS MYSELF
Feel free to urinate all you want, its not my floor.
I quite like RX which just sexp-ifies regex.
https://www.emacswiki.org/emacs/Rx_Notation
>(([^()]*+(?:(?R)[^()]*)*+))
the absence of whitespace and of identifiers is what make it unreadable, and when all that is covered you need to know a normal parser matching this would work which can be hard if you're not well versed in parsing and in recursion. if you're not good with both then you are simply not logically equiped with understanding this regex and this has nothing to do with regexes
#!/usr/bin/perl
use strict;
use warnings;
use v5.10;
my $re = qr{
A (?¬_parens) (?&parens) (?¬_parens) z
(?(DEFINE)
(?<parens>
( (?¬_parens) (?: (?&parens) (?¬_parens) )*+ )
)
(?<not_parens> [^()]*+ )
)
}x;
my @test = (
"",
"()",
"(() () (()()(*~~",
"(()",
"())",
);
for (@test) {
say ""$_"";
say /$re/ ? "match" : "fail";
say "";
}
cute and funny moron, made me laugh
i want to mating press moronic akariposter