[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bash "extglob" needs to upgrade at least like zsh "kshglob"
From: |
Oğuz İsmail Uysal |
Subject: |
Re: bash "extglob" needs to upgrade at least like zsh "kshglob" |
Date: |
Sun, 30 Oct 2022 16:35:29 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 |
On 10/30/22 3:25 PM, Martin D Kealey wrote:
How much faster do you think it can be made?
I don't know, irrelevant though.
The problem is not that individual steps are slow, but rather that it
takes at least a higher-order-polynomial number of steps, possibly
more (such as exponential or factorial).
Speeding up the individual steps will make no practical difference,
while pin-hole optimisations may dramatically speed up some common
cases, but still leave the most general cases catastrophically slow.
These are technical details; no user cares about them.
The purpose of my suggestions was to /minimize/ the complexity that
becomes part of Bash's codebase, while leaving as few pathological
cases as possible - preferably none.
I meant complexity of the language, not the codebase.
In my opinion "make the existing extglob code faster" is a wasted
effort if it doesn't get us to "run in at-most quadratic time" and
preferably "run in regular (linear) time", and so that basically
amounts to "write our own regex state machine compiler and regex
engine". This is a non-trivial task, and would fairly obviously add
*more* complex code into Bash's codebase than any of my suggested
alternatives.
extglobs are already a part of the bash language. All of your suggested
alternatives involve expanding the language in question. That's why I
disagree with all of them.
(Even my options of "postprocess the codebase" or "modify an existing
regex compiler" would leave their execution components untouched; only
the compilation phase would be modified, and a modified regex compiler
would at least stand a chance of existing as a stand-alone library
project.)
If you mean bash should start shipping a huge library like pcre for
solving an edge case, I don't think that's reasonable at all; why take
on such a burden when you already have something that works fine in
practice?
- bash "extglob" needs to upgrade at least like zsh "kshglob", Hyunho Cho, 2022/10/28
- Re: bash "extglob" needs to upgrade at least like zsh "kshglob", Greg Wooledge, 2022/10/28
- Re: bash "extglob" needs to upgrade at least like zsh "kshglob", Martin D Kealey, 2022/10/29
- Re: bash "extglob" needs to upgrade at least like zsh "kshglob", Greg Wooledge, 2022/10/29
- Re: bash "extglob" needs to upgrade at least like zsh "kshglob", Martin D Kealey, 2022/10/30
- Re: bash "extglob" needs to upgrade at least like zsh "kshglob", Oğuz, 2022/10/30
- Re: bash "extglob" needs to upgrade at least like zsh "kshglob", Alex fxmbsw7 Ratchev, 2022/10/30
- Re: bash "extglob" needs to upgrade at least like zsh "kshglob", Chet Ramey, 2022/10/31
- Re: bash "extglob" needs to upgrade at least like zsh "kshglob",
Oğuz İsmail Uysal <=
- Re: bash "extglob" needs to upgrade at least like zsh "kshglob", Martin D Kealey, 2022/10/30
- Re: bash "extglob" needs to upgrade at least like zsh "kshglob", Oğuz, 2022/10/30
- Re: bash "extglob" needs to upgrade at least like zsh "kshglob", Greg Wooledge, 2022/10/31
- Re: bash "extglob" needs to upgrade at least like zsh "kshglob", Oğuz İsmail Uysal, 2022/10/31
- Re: bash "extglob" needs to upgrade at least like zsh "kshglob", Chet Ramey, 2022/10/31
- Re: bash "extglob" needs to upgrade at least like zsh "kshglob", Chet Ramey, 2022/10/31
Re: bash "extglob" needs to upgrade at least like zsh "kshglob", Chet Ramey, 2022/10/31