help / color / mirror / code / Atom feed
From: Sebastian Gniazdowski <sgniazdowski@gmail.com>
To: Oliver Kiddle <opk@zsh.org>
Cc: Bart Schaefer <schaefer@brasslantern.com>,
	Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [PATCH 1/3] Extended ksh compatibility: namespace parameter syntax
Date: Sun, 5 Mar 2023 09:57:10 +0000	[thread overview]
Message-ID: <CAKc7PVB=cbu6OBN7GMB31SNzXsMO4V5E+rQifJpg4uvZtUU=WA@mail.gmail.com> (raw)
In-Reply-To: <26170-1678007435.186071@mDq6.Euc0.bAwZ>

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

I wonder, how far is this from supporting a nested arrays? Like arr[2][3]
or assoc[a][c]?

On Sun, 5 Mar 2023 at 09:11, 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}.
> > As yet, there's no special significance to use of this syntax, that
> > is, parameters having such a prefix are ordinary parameters like any
> > others, with the usual dynamic scoping rules, etc.  Each of namespace
> > and param must be an identifier in the original zsh semantics of
> > identifiers.
> 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.
> 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}. 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. I'm not sure how ksh implements the initial dot. It effectively
> blocks consecutive dots because you have to declare the parent first.
> Ksh uses dots both for namespaces and compound variables. Of the two,
> compound variables are definitely the most useful. The namespace { ... }
> syntax of ksh was not designed with the interactive nature of the shell
> being considered foremost. I like the aspect of hiding shell specific
> variables away below .sh - could also be good for .zle.
> I think it is a mistake to not make compound variables, namespaces and
> associative arrays merely different facets of the exact same underlying
> thing. 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.
> Oliver

Best regards,
Sebastian Gniazdowski

[-- Attachment #2: Type: text/html, Size: 2870 bytes --]

  reply	other threads:[~2023-03-05  9:57 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 [this message]
2023-03-05 20:20     ` Bart Schaefer
2023-03-05 21:11       ` Bart Schaefer
2023-03-05 20:16   ` Bart Schaefer
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='CAKc7PVB=cbu6OBN7GMB31SNzXsMO4V5E+rQifJpg4uvZtUU=WA@mail.gmail.com' \
    --to=sgniazdowski@gmail.com \
    --cc=opk@zsh.org \
    --cc=schaefer@brasslantern.com \
    --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).