Re: namespaces limitation

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Thu, May 18, 2023 at 5:14 PM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> I came across the following when using the new namespaces:
>
>   integer .var.d=0
>   (( .var.d++ ))
>   zsh: bad floating point constant

There are three (mainly) places where I elected not to dive straight
in to changing the meaning of "identifier" ...
1) math variables
2) math function names
3) word completions

#3 is tricky (as in zle_tricky) because itype_end() is often being
used to determine whether a character is valid in an identifier, not
whether an entire word is an identifier; it would probably be wrong or
break some other constraint to skip across "." in that context.

#2 is ... well, function naming in general is a bit hard to deal with.
For example, out of math context, you can name a function pretty much
anything (using dots, slashes, hyphens, plus signs) but if you want to
use the function with the (+CMD) glob qualifier, the name has to be
strictly an identifier (alphanum and underscore).

#1 (and likely also #2) requires changing the math lexer, which I
didn't want to risk breaking until the rest had been thoroughly
tested.  E.g., --

> And should this be allowed or should it complain about the 3 part not
> being an identifier?
>
>   integer .3=67

Yes, the first character of a namespace identifier should probably be
an alphabetic.  Or an underscore?  That might really complicate math
lexing, given that we allow underscores in numeric constants.