[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: >= and <= for string comparison
From: |
Peng Yu |
Subject: |
Re: >= and <= for string comparison |
Date: |
Wed, 18 Jan 2023 07:52:26 -0600 |
On 1/18/23, Lawrence Velázquez <vq@larryv.me> wrote:
> On Wed, Jan 18, 2023, at 3:36 AM, Koichi Murase wrote:
>> If we decide to support `<=' and `>=' for strings, to me, the cleanest
>> solution seems to be reorganizing the lexical rule inside [[ ... ]] to
>> accept <= and >= as single tokens though it would introduce
>> incompatibilities. I'm currently not sure if it's worth it. We need
>> more real use cases.
>
> And remember that, as Kerin pointed out at the beginning of this
> thread, [[ ! x > y ]] and [[ ! x < y ]] are already available.
> (They're decently portable, too. The > and < operators are supported
> by many test(1) implementations and will even be in the next version
> of POSIX.) So the threshold for introducing backward-incompatible
> equivalents ought to be high.
I would never use [[ ! x > y ]] and [[ ! x < y ]] in my code. It will
make the code hard to read. If I have to, I will use [[ x > y && x = y
]] and [[ x < y && x = y ]] instead.
I don't think the slight compatibility problem that Koichi reminded is
that critical, after all, the new feature of <= => may be made to be
controlled by some switch or environmental variable and be tagged as
something like experimental. Gradually, such an experimental feature
can be turned into a permanent one, this will give the incompatible
code time to adapt. If the time is long enough, that will never be a
concern in practice.
https://lists.gnu.org/archive/html/help-bash/2023-01/msg00054.html
The real question is how much human time is required to add <= =>. If
it takes hours to add such a feature, I'd it is definitely worthwhile.
But it takes months, then one may need to weigh the pros and cons, for
example, there may be other more important things to do.
If it is in the middle, e.g, days, then it may still be worth it. One
may consider what benefit it will result in if the code structure for
[[ is changed. I don't know the answer to this question, and I don't
know how long it takes to change the code. Maybe someone who knows
more can provide more definitive answers.
In terms of real cases, because of the lack of the feature, you would
never find a real use for it. However, without the feature available,
you would never know. So I don't think that is a valid question to
ask.
In summary, I think there are only two questions important:
- the effort that takes to implement <= =>
- any additional benefit of the new code structure for lexical analysis in [[
--
Regards,
Peng
- Re: >= and <= for string comparison, (continued)
- Re: >= and <= for string comparison, Ruiyang Peng, 2023/01/18
- Re: >= and <= for string comparison, Koichi Murase, 2023/01/18
- Re: >= and <= for string comparison, Ruiyang Peng, 2023/01/18
- Re: >= and <= for string comparison, Ruiyang Peng, 2023/01/18
- Re: >= and <= for string comparison, Tapani Tarvainen, 2023/01/18
- Re: >= and <= for string comparison, Ruiyang Peng, 2023/01/18
- Re: >= and <= for string comparison, Lawrence Velázquez, 2023/01/18
- Re: >= and <= for string comparison,
Peng Yu <=
- Re: >= and <= for string comparison, Emanuele Torre, 2023/01/18
- Re: >= and <= for string comparison, Greg Wooledge, 2023/01/18
- Re: >= and <= for string comparison, alex xmb ratchev, 2023/01/18
- Re: >= and <= for string comparison, Peng Yu, 2023/01/18
- Re: >= and <= for string comparison, Eduardo Bustamante, 2023/01/18
- Re: >= and <= for string comparison, Peng Yu, 2023/01/19
- Re: >= and <= for string comparison, Lawrence Velázquez, 2023/01/18
- Re: >= and <= for string comparison, Peng Yu, 2023/01/19
- Re: >= and <= for string comparison, Chet Ramey, 2023/01/19
- Re: >= and <= for string comparison, Peng Yu, 2023/01/20