^(?P<country_code>\+[0-9]{1,3}-?)?[0-9]{3}-[0-9]{3}-[0-9]{4}$
^
(
\+
[0-9]{1,3}
-?
)? # optional country code
[0-9]{3}
-
[0-9]{3}
-
[0-9]{4}
$
Ultimately it is a dsl. Should equations in math also use full words and comments?
No, they should not. Maybe a nice syntax for grammars like raku is a better approach.
I just care that things have readable text names rather than inscrutable punctuation and single letters.
Yes, it is a DSL. Just like, you know, Python or C or HTML or CSS. Just because it's a DSL doesn't mean it can't actually use keywords instead of punctuation.
> Should equations in math also use full words and comments?
My "also" referred not to have multiple representations but to also in math have prose instead of equations. I could have expressed it better. I did not think of that interpretation.
As for math, I really do not think that is true. Look at how this beautiful proof is so long in prose.
https://mathcs.clarku.edu/~djoyce/java/elements/bookI/propI4...
Is that better than a^2+b^2 = c^2 ?
https://en.wikipedia.org/wiki/Pythagorean_theorem
Notation helps to be concise. Imagine more complicated things without notation in maths. Of course if you look at Principia Matematica we see the limits of notation as well.
That's why a well-designed DSL tries to make its syntax as self-explanatory as possible. Using "start" instead of "^", or "digit" instead of "d".
We're not doing equations here, we're doing engineering. Analogies to proofs are not helpful. There is a very good reason why, in coding, we give descriptive variable names such as "accountBalance" rather than "b".
Conciseness is not a virtue in programming. Clarity is. Things should not be longer than they need to be -- but neither should they be shorter. The name of something should not be 100 characters long, but neither should it be 1 character long. A word or two is generally the sweet spot.
In languages with an expressive typesystem you see a lot more single letter variables.
> We're not doing equations here, we're doing engineering
This sentence is nonsense.
> Conciseness is not a virtue in programming. Clarity is
I see what you are saying, but conciseness is also related to clarity, as I showed with the theorem.
Personally, I like regexes, in the same way that I like shell string manipulation: it looks utterly inscrutable, and performs magic. If I write one in code meant for others, I usually use extended mode with each line commented.
It may feel silly to have a whole unit test for a one-line regex, but that one line can be really dense. If you wrote a function to parse the string without regex, that function would be complex enough to warrant a unit test, after all.
Introducing regressions when tweaking a regex in your application is also a big risk which unit tests can help mitigate.
grammar IniFile {
token key { \w+ }
token value { <-[\n;]>+ }
token pair { <key> \h* '=' \h* <value> \n+ }
token TOP { <pair>+ }
}
my $text = "user = alice\nrole = admin\n";
my $match = IniFile.parse($text);
if $match {
say "Parsed successfully!";
}
If you're not looking for that, and more specifically what you have shown above, there are often ways to accomplish that in certain languages. In Perl it's easy because you can use regex cars in a regex, so you can just assign `my $digit = qr/(? :0-9)/;` and then use it in the regex as you did (and Perl already supports non matching whitespace with a flag). For that matter, Perl regexes allow you to define chunks purely within the regex to be reused in a DEFINE block, so possibly that is a feature other regex engines have as well.
For example:
<start>;
option of "v";
capture major {
some of <digit>;
}
".";
capture minor {
some of <digit>;
}
".";
capture patch {
some of <digit>;
}
<end>;
patt <- country area "-" phone fin
country <- ("+" %digit^-3 "-")?
area <- %digit^3
phone <- %digit^3 "-" %digit^4
fin <- ! .
But regex is also syntactically designed by Satan himself.
Most programming languages use commands that are semantically understandable, like "for" and "let" and "return" and mostly symbols we already know like "+" and "=". They use newlines and indentation for organization. And they put multiple commands on multiple lines and you can add comments and everything.
Regex is exclusively punctuation, with its own idiosyncratic meanings, all compressed into a single line, zero organization, zero comments, and impossible to remember what each symbol does if you don't use it daily. Not to mention the nightmare of escaping regexes when expressed as strings, on top of escaping regex symbols within the regex itself.
I swear it's high time we come up with a regex replacement that looks like normal Python code or HTML or something. So instead of:
We would write something like: Same thing. But one is completely inscrutable to someone who hasn't learned regex, while with the other you can guess pretty easily how it works...