Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH 1/3] Extended ksh compatibility: namespace parameter syntax
- X-seq: zsh-workers 51781
- From: Oliver Kiddle <opk@xxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: [PATCH 1/3] Extended ksh compatibility: namespace parameter syntax
- Date: Wed, 24 May 2023 17:57:58 +0200
- Archived-at: <https://zsh.org/workers/51781>
- In-reply-to: <ZGvYU//xw/ZLjWOK@fullerene.field.pennock-tech.net>
- List-id: <zsh-workers.zsh.org>
- References: <CAH+w=7aV2s_+79eCPuavRTiR5wRTwDtTjYxP_VN8HNtL2R5iXw@mail.gmail.com> <26170-1678007435.186071@mDq6.Euc0.bAwZ> <CAH+w=7aqU8B8NAJYD3iAiMRDpGMY=G4oAv6+B+rbdVd_yt6Kyg@mail.gmail.com> <52850-1678055097.553101@HAUa.4aGe.fmcC> <CAH+w=7ZrEFRuswLd6jpAx5YE7X62vrQeuCn9v9EQAgbUVRGVgg@mail.gmail.com> <ZGgq/syXoXQF/pLl@fullerene.field.pennock-tech.net> <CAH+w=7bjStThTiTpEgem636Hr3Uev9CjLMUBhR1OWGNOvsfq4Q@mail.gmail.com> <ZGkEJ5ue3SJnbQ3f@fullerene.field.pennock-tech.net> <CAHYJk3SMqNPBKzkAGReS-KJ0P6qVgYPh1yJ7P8T1GDC1QMbN5w@mail.gmail.com> <CAH+w=7a8Um9QJK_QnkMEKnAxcKJOce_cfDXFfKmTnNo5V56d5g@mail.gmail.com> <ZGvYU//xw/ZLjWOK@fullerene.field.pennock-tech.net>
Phil Pennock wrote:
> On 2023-05-21 at 21:35 -0700, Bart Schaefer wrote:
> > On Sun, May 21, 2023 at 7:36 PM Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
> > > > So, to match the intent of ksh as I understand it:
> > > > * .identifier.x is always treating identifier as a namespace
> > > > * identifier.x is always treating identifier as a compound var
> > > > * this is consistent across assignment LHS and expansion
> > >
> > > Does this mean compound vars can't be namespaced?
> >
> > No, but it does mean namespaces can't be nested.
That naming system alone wouldn't necessarily preclude nesting of
namespaces if you allow for consecutive runs of dots - something like:
.identifier..identifier
The current code doesn't allow that and I'm not even remotely suggesting
it should. Namespaces at the top-level only seems fine.
> Bart is (as per 99.9% of the time) correct. The examples below might
> make it clearer (and are original to me so fine to grab into the test
> suite). Note though that ksh does have nested collection types, which
> would make full zsh compatibility trickier:
Compatibility with ksh93 has limited value. What is useful should be
priority. As I've mentioned before, my main wish is that we keep our
options open for the compound variable syntax to be nothing more than
an alternative syntax for associative arrays. I'd ideally like it if
we could somehow stick everything the shell has - keymaps, functions,
aliases, options styles etc into the variable hierarchy so that features
like references, scoping etc might be usable with all. The current
associative array syntax is at least compatible with the fact that
functions have different naming rules because you can use
.sh.function[.a/b] for a function named .a/b
While we can't remove the underscore, it isn't necessarily too late for
us to remove completion functions from polluting the global namespace.
There's a lot of pieces that we'd need in place first but it could be
done.
Oliver
Messages sorted by:
Reverse Date,
Date,
Thread,
Author