Re: inf and nan in arithmetic expansions

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Stephane Chazelas wrote on Thu, 08 Feb 2018 14:22 +0000:
> 2018-02-08 12:46:35 +0000, Daniel Shahaf:
> > And then we could add 'inf' and 'nan' as readonly variables initialised to
> > those respective values (as Oliver also suggests in the 19597 thread).  There
> > are compatibility implications for scripts that use these variable names, but
> > there is no way around them if we want to allow explicitly doing (( x = inf ))
> > in user code...
> 
> But what value would you use for those variables?

'inf' would be positive infinity. 'nan' would be a NaN (whichever flavour
thereof would be least surprising).

> Or do you mean that the shell arithmetic parser would understand
> "inf"/"nan" as the infinity and not-a-number numbers and not as the
> variable (otherwise with inf=inf, that would do infinite recursion)

Why would it be recursive?

> but just make inf/nan readonly so users not be tempted to use them as
> variables?

That would be the simplest implementation, yes.  It might suffice, or we might
prefer something more elaborate.

> I'd also rather "inf" be used instead of "inf." (would also
> align with ksh93), but the change could potentially break some
> scripts. If we also make $inf/$nan read-only variables, that
> would  also break scripts that use $inf/$nan variables but not
> in arithmetic contexts (like for inf in *.inf), so that doesn't
> sound like a good idea to me.

Yes, that would be backwards incompatible.  If we choose this path,
those people can use 'for inf in...' use 'local inf' or 'local -h inf'
to hide the float inf/nan.

One option that is compatible is to make 'inf' and 'nan' only declared
on an opt-in basis --- using some autoload/zmodload, or perhaps with
some "This script requires zsh 5.5 or greater" directive.

Cheers,

Daniel