namespaces limitation

namespaces limitation

[Oliver Kiddle]

I came across the following when using the new namespaces:

  integer .var.d=0
  (( .var.d++ ))
  zsh: bad floating point constant

It'd be good if it could identify this as a namespace variable.

And should this be allowed or should it complain about the 3 part not
being an identifier?

  integer .3=67

Oliver

Re: namespaces limitation

[Bart Schaefer]

On Thu, May 18, 2023 at 5:14 PM Oliver Kiddle <opk@zsh.org> 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.

Re: namespaces limitation

[Oliver Kiddle]

Bart Schaefer wrote:
> 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.

What's allowed in math context can be (and already is) more restrictive
that what it's possible to declare.

One option might be to disallow bare namespaces, so

  integer .var=56

would be disallowed. Where .3 just looks really wrong, .3.var feels
innocuous.

In ksh93:

  $ .var=23
  $ typeset -p .var
  .var=23
  $ namespace var { val=78; }
  $ typeset -p .var
  namespace var
  {
	  val=78
  }

Also questionable is the following which currently works:

  .a.=ddd

The ksh error for this is 'no parent' even if you create an "a"
namespace first. We also currently allow a.=ddd but I think that is less
questionable. We allow empty association elements.

Oliver

Re: namespaces limitation

[Bart Schaefer]

On Wed, May 24, 2023 at 9:41 AM Oliver Kiddle <opk@zsh.org> 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.

Re: namespaces limitation

[Bart Schaefer]

On Thu, May 25, 2023 at 3:09 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> I still haven't worked out how to deal correctly with .var.3x -- ksh
> allows .var.3 but rejects .var.3x

Also, paramsubst() doesn't apply the same rules in the same way as
assignments, so getting both .var.3x=y and ${.var.3x} to be rejected
is annoyingly complex.

Even rejecting .var.3x=y in zsh produces "not an identifier" whereas
ksh attempts to run a command of that name ... that may not be worth
tackling.