Re: namespaces limitation

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Wed, May 24, 2023 at 9:41 AM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> One option might be to disallow bare namespaces, so
>
>   integer .var=56
>
> would be disallowed.

I had it that way at one point and backed off because ksh allows it.

> Where .3 just looks really wrong, .3.var feels
> innocuous.

Strictly speaking (to the extent that any of this is strict),
namespaces are supposed to otherwise obey the rules for identifiers,
which with the exception of positional parameters are not allowed to
begin with a digit ... so I think I'll just go with that.

I still haven't worked out how to deal correctly with .var.3x -- ksh
allows .var.3 but rejects .var.3x so although it's a simple !idigit()
test to disallow anything starting with a digit, it's more work to
allow numbers but not strings that begin with a number.  Currently
that's handled in isident() at a point which precedes the check for
presence of a namespace.  Hrm.

> Also questionable is the following which currently works:
>
>   .a.=ddd
>
> The ksh error for this is 'no parent'

That probably should be rejected, yeah.

> We also currently allow a.=ddd but I think that is less
> questionable. We allow empty association elements.

I'm still not entirely sold on the x.y <=> x[y] mapping idea, but if
we follow JavaScript's (somewhat questionable) lead on this, empty
elements have to use bracket-notation rather than dot-notation.