Re: math operations with base#prefix

[Kerin Millar]

On Tue, 19 Sep 2023 20:00:13 +0700
Robert Elz <kre@munnari.OZ.AU> wrote:

>     Date:        Tue, 19 Sep 2023 09:52:21 +0100
>     From:        "Kerin Millar" <kfm@plushkava.net>
>     Message-ID:  <4c2e3d39-0392-41ae-b73c-3e17296a949c@app.fastmail.com>
> 
>   | On Tue, 19 Sep 2023, at 8:40 AM, Victor Pasko wrote:
>   | > Thanks for your response.
>   | > In my opinion, in let "<>" and $((<>)) constructs all variables should 
> be
>   | > evaluated, so that $-sign for them is to be  just optional
>   |
>   | You haven't thought this through.
> 
> You didn't think that through.

This assertion would be more compelling had you explained at some point during 
the ensuing treatise how to potentially square the request being made with the 
base#n notation, as presently implemented by bash.

> 
>   | It would amount to an egregious break of backward compatibility,
> 
> That's correct, but
> 
>   | How would you expect for digits above 9 to be expressed for bases above 
> 10?
> 
> that's completely missing the point Victor was making.
> 
> But Victor, they are all evaluated (in many shells, just once), if you
> have
> 
>       a=10
> 
> then
>       $(( a + 5 )) and $(( $a + 5 ))
> 
> achieve exactly the same thing.    To be postable however if we also
> have
> 
>       b=a
> 
> then
>       $(( b + 5 )) is quite likely to fail, whereas $(( $b + 5 )) will
> work fine (after expansions it becomes $(( a + 5 )) which is evaluated as
> above.
> 
> However, where the expansions are really needed is with
> 
>       o1=+
>       o2=*
> 
> used in
> 
>       $(( 10 $o1 5 $o2 6 ))
> 
> If we were to write it instead as
> 
>       $(( 10 o1 5 o2 6 ))
> 
> then the expression parser would have no idea at all how to
> interpret that, as var names are not evaluated until needed in
> the expression - what's there is just meaningless nonsense.  But
> when the variables have the $ ahead of them, the expression parser
> sees
>       $(( 10 + 5 * 6 ))
> 
> and can build the correct evaluation tree to generate 40 as the answer.
> (The "10" could have been any of 'a' '$a' or '$b' given the values assigned
> earlier, that would make no difference, the ' chars there are just for
> clarity in this e-mail, not to be included).
> 
> Much more complex expressions, which rely upon vars being expanded before
> the expression is parsed, can also be created, but not really needed here.

So, how would you accommodate Victor's request, theoretically speaking?

Permitting n as an identifier for bases between 11 and 64 seems out of the 
question; there would be no reasonable way to disambiguate them from legitimate 
integer constants. Could they be tolerated for bases between 2 and 10? Perhaps. 
At that point they would no longer be integer constants and the interface 
fundamentally changes. To my mind, it would make for yet another exception to 
the rule to be borne in mind, and to potentially confound the expectations of 
those acquainted with the notation from having used it in other shells. However 
one might go about it, it requires for more thought to be invested than to 
simply state that $ be "optional" for the let builtin and for arithmetic 
expansion.

-- 
Kerin Millar