Re: inf and nan in arithmetic expansions

[Stephane Chazelas <stephane.chazelas@xxxxxxxxx>]

2018-02-17 00:38:52 +0000, Daniel Shahaf:
> Oliver Kiddle wrote on Fri, 16 Feb 2018 17:51 +0100:
> > > 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...
> > 
> > I'm not sure about making them readonly simply because not doing so is
> > less likely to break an existing script.
> 
> After 42356 I am not sure whether I would prefer predefined variables
> (readonly or not) or recognising 'inf' and 'nan' (putting aside the
> question of case for a moment) as special constants in math contexts
> as 42356 suggests.
[...]

A note on top of what I said earlier on that. In ksh93, from a
syntax point of view, it does look a bit like ksh93 treats
"inf"/"nan" (with any variation of case) like if it was a
variable whose value resolved to infinity as seen when we use
inf[0] (but not ${inf[0]}) in arithmetic contexts:

$ ksh93 -c 'InF=(2 3); echo "$((InF[0])) $((${InF[0]}))"'
inf 2

Or with:

$ ksh93 -c 'inf=2; echo "$((inf = 1, inf))"'
ksh93: Inf: is read only

But:

$ ksh93 -c 'echo "$((${Inf=2}))"'
2
$ ksh93 -c 'echo "$((${Inf=2}, Inf))"'
inf

That does look bad to me.

I still think it doesn't make sense to treat inf/nan as
variables.

-- 
Stephane