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}
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.
next prev 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* 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 \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.vuxu.org/mirror/zsh/
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).