Re: [PATCH 1/3] Extended ksh compatibility: namespace parameter syntax

[Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>]

On 2023-03-05 at 14:42 -0800, Bart Schaefer wrote:
> On Sun, Mar 5, 2023 at 2:25 PM Oliver Kiddle <opk@xxxxxxx> wrote:
> > There must be an off-by-one error in a check:
> >
> >   a.b=c
> >   zsh: command not found: a.b=c
> 
> Ah, thanks.  It was assuming there would be a leading ".".

AFAICT, in zsh, .a.b=c is assigning to var b in namespace a, while a.b=c
is setting the b attribute of the compound variable a.

> Hmm, but ... if we change these to .zle.bracketed_paste etc., at what
> point to deprecate the current names?

I hadn't realized ksh had namespaces or I'd have looked before, but at
some point I started thinking through how namespaces could benefit a
shell design (I was going to call them varspaces to avoid confusion on
Linux).

I think that you can use a set of namespaces for subsystems and have
bound names (aliases) from the main namespace to those for existing
behavior, unless an emulate directive says to be particularly strict.

Then you could have the completion system switch away from littering the
main namespace with _foo functions, by moving completion functions into
the namespace, and all sorts of cache variables there, which has the
added bonus that leaks in user written completions won't pollute the
main namespace.

Once you have binding names (one level "deeper" than a ksh/bash
nameref in that it's not repointable by the user, only something you can
omit from the namespace, and can be for commands, not just variables)
you can move all the builtin and module-loadable commands into one
namespace, builtin variables into another, and then lock all existing
variables into a "legacy" mapping to make them available in other
namespaces.  By default the legacy mapping would be on in the main
namespace.

To some extent, the problems we faced with modules such as zsh/files and
zsh/stat are because everything sits in one global namespace, so we
ended up with Peter writing neat extensions to zmodload so we can
selectively load feature-sets, to try to work around this.

Why are infix operators in conditional expressions not just callables in
an infix namespace, where people can write their own functions or load
modules?

-Phil