Sujet : Re: Command Languages Versus Programming Languages
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.unix.shell comp.unix.programmer comp.lang.miscDate : 21. Nov 2024, 20:12:03
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20241121110710.49@kylheku.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2024-11-20, Janis Papanagnou <janis_papanagnou+
ng@hotmail.com> wrote:
On 20.11.2024 09:21, Muttley@DastartdlyHQ.org wrote:
Regex itself is clumsy beyond simple search and replace patterns. A lot of
stuff I've seen done in regex would have better done procedurally at the
expense of slightly more code but a LOT more readability. Also given its
effectively a compact language with its own grammar and syntax IMO it should
not be the core part of any language as it can lead to a syntatic mess, which
is what often happens with Perl.
>
I wouldn't look at it that way. I've seen Regexps as part of languages
usually in well defined syntactical contexts. For example, like strings
are enclosed in "...", Regexps could be seen within /.../ delimiters.
GNU Awk (in recent versions) went towards first class "strongly typed"
Regexps which are then denoted by the @/.../ syntax.
These features solve the problem of regexes being stored as character
strings not being recognized by the language compiler and then having
to be compiled at run-time.
They don't solve all the ergonomics of regexes that Muttley is talking
about.
I'm curious what you mean by Regexps presented in a "procedural" form.
Can you give some examples?
Here is an example: using a regex match to capture a C comment /* ... */
in Lex compared to just recognizing the start sequence /* and handling
the discarding of the comment in the action.
Without non-greedy repetition matching, the regex for a C comment is
quite obtuse. The procedural handling is straightforward: read
characters until you see a * immediately followed by a /.
In the wild, you see regexes being used for all sorts of stupid stuff,
like checking whether numeric input is in a certain range, rather than
converting it to a number and doing an arithmetic check.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca