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

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.


  reply	other threads:[~2023-03-05  9:11 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 [this message]
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
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=26170-1678007435.186071@mDq6.Euc0.bAwZ \
    --to=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).