help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Oliver Kiddle <opk@zsh.org>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [PATCH 1/3] Extended ksh compatibility: namespace parameter syntax
Date: Sun, 5 Mar 2023 12:16:36 -0800	[thread overview]
Message-ID: <CAH+w=7aqU8B8NAJYD3iAiMRDpGMY=G4oAv6+B+rbdVd_yt6Kyg@mail.gmail.com> (raw)
In-Reply-To: <26170-1678007435.186071@mDq6.Euc0.bAwZ>

On Sun, Mar 5, 2023 at 1:10 AM Oliver Kiddle <opk@zsh.org> 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}
% print ${.foo.bar::=otherthing}
% typeset -m .foo.\*

> 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.

  parent reply	other threads:[~2023-03-05 20:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-27  3:56 Bart Schaefer
2023-03-05  9:10 ` Oliver Kiddle
2023-03-05  9:57   ` Sebastian Gniazdowski
2023-03-05 20:20     ` Bart Schaefer
2023-03-05 21:11       ` Bart Schaefer
2023-03-05 20:16   ` Bart Schaefer [this message]
2023-03-05 22:24     ` Oliver Kiddle
2023-03-05 22:42       ` Bart Schaefer
2023-05-20  2:05         ` Phil Pennock
2023-05-20  6:54           ` Bart Schaefer
2023-05-20 17:32             ` Phil Pennock
2023-05-22  2:36               ` Mikael Magnusson
2023-05-22  4:35                 ` Bart Schaefer
2023-05-22 21:02                   ` Phil Pennock
2023-05-24 15:57                     ` Oliver Kiddle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH+w=7aqU8B8NAJYD3iAiMRDpGMY=G4oAv6+B+rbdVd_yt6Kyg@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=opk@zsh.org \
    --cc=zsh-workers@zsh.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).