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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sun, Mar 5, 2023 at 1:10 AM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> On 26 Feb, Bart Schaefer wrote:
> > The attached patch enables assignment of and reference to parameters
> > prefixed with ksh-style namespace syntax, e.g., ${.namespace.param}.
>
> I've been running this patch since you posted it and haven't found it to
> cause any problems as such. It also holds up to testing but with no way
> to assign to variables with a dot in their name, there's a limit to
> what's possible to test.

Assignment should be possible.

% .foo.bar=something
% print ${.foo.bar}
something
% print ${.foo.bar::=otherthing}
otherthing
% typeset -m .foo.\*
.foo.bar=otherthing

> My main concern is that in the absence of special significance to the
> syntax up-front it could be harder to add later. At least the
> documentation should warn so users should not be surprised if e.g, in the
> future, `local foo` will hide a ${foo.bar}.

Yes, I've been working on doc and tests.  One difference that I want
to add is that parameters starting with "." are omitted from the
default output of "set" and "typeset" (with no arguments).

> But every new module like ksh93
> could need reworking if the implementation changes so that this is a bar
> entry in a foo hash table instead of a foo.bar entry in a global hash
> table.

Exactly how far we (or I) want to go with this is still an open
question.  Namespaces do not nest, so anything with a leading "." (and
exactly one further ".") is in the global hash table.

> Ksh uses dots both for namespaces and compound variables. Of the two,
> compound variables are definitely the most useful.

In ksh (based on doc and some testing, I'm not a ksh expert)
${foo.bar} might be a reference to ${foo[bar]} or it might be a call
to the function named foo.bar to invoke the "bar" property of "foo"
(or it might even be that ksh implements the former as the latter).
In the foregoing patch I have allowed the syntax without the leading
"." to be parsed, but so far not ${foo.bar.baz} etc., so the doc I've
written so far does warn that that leaving off the first "." might do
something different later.  Patch following soon.

> I like the aspect of hiding shell specific
> variables away below .sh - could also be good for .zle.

Given zsh dynamic scoping, it works reasonably well to have ZLE
variables behave like locals -- you can't access them outside a shell
function (widget) anyway.  If there were controls we wanted to expose
higher up -- such as, perhaps, fiddling with keymaps without having to
invoke "zle -K" or "bindkey -[eva]") then yes, a ".zle" namespace
could be handy.

> I think it is a mistake to not make compound variables, namespaces and
> associative arrays merely different facets of the exact same underlying
> thing.

Agreed with respect to associative arrays and compound variables
(whatever that ends up meaning to us, I find the ksh implementation
rather grotty especially from a syntax standpoint, and there are some
significant conflicts with existing zsh idioms).  Namespaces actually
are a slightly different thing because the variety of "objects" in a
namespace isn't limited to parameters.  If we were already using a
global hash table to contain as its elements the parameters, commands,
aliases, functions, etc. hash tables, that might be a different
matter, but we're pretty far from that now.

> I'd like to be able to dump variables out as json/xml/yaml and
> reimport them back without the loss of detail of which type they started
> out as.

For that, there are other obstacles (not related to namespaces or
compound variables) remaining to be overcome, but it's worth keeping
in mind.