zsh-workers
 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]: Add named references
Date: Sun, 12 Feb 2023 10:02:03 +0100	[thread overview]
Message-ID: <94092-1676192523.865597@yGHQ.rexg.4E4Z> (raw)
In-Reply-To: <CAH+w=7bcqc8SsRxsht0QFyXy=DYzj6nVaBFhdzQ5MrBB+yBz+A@mail.gmail.com>

On 9 Feb, Bart Schaefer wrote (I've reordered this):
> > This should be an error perhaps:
> >
> >   typeset -n ref=arr[1][2]
>
> Why?  ${ary[1][2]} isn't an error, it's the 2nd character of the first
> word in $ary.

Sorry, should have been clearer. Applying later subscripts is even
better than an error but the following is not ideal:

  % arr=( one two three )
  % typeset -n ref=arr[2][1]
  % echo $ref
  two[1]
  % ref=x
  % typeset -p arr
  typeset -a arr=( one x three )
  % echo $ref
  x[1]
  % typeset -n ref=arr[1]whatever
  % echo $ref
  onewhatever

> Yeah, I don't like the idea that a called function can arbitrarily
> grab parameters from its caller just by sticking & in front.  Caller
> needs to do do something (even if only make "normal" use of dynamic
> scope) to make the parameter "grabbable".

Allowing such things as uplevel statements (Tcl), special syntax, or
introspection modules (Python's inspect), is fairly normal for a
scripting language.

As I've mentioned, we already have the situation where the caller
needs nothing to make a private grabable by a builtin:
  private -a var
  compadd -O var one two three
And writing wrappers to e.g. compadd is useful.

But I don't think we need to address references to privates in other
scopes at this point before the other patches are even applied. May be
better to consider whether there are other advantages in moving private
to the main shell first as that may ease any implementation.

> > >   typeset -n ref
> > >   for ref in 'hash[(e)'${(k)^hash[(R)?*]}']'; do ...
> >
> > "just"!?
>
> Hah!  Point was that it's do-able without "for"-context-sensitive
> special subscript semantics.  I think it would be strange for

I can't think of a sensible way. Was just that it could be useful.
Best long term solution might be to allow arrays of references. Bash
does allow arrays of integers.

> The others would all have to be special-cased individually.  What is
> $+ ?  Do you mean $- ?

Yes.

Oliver


  parent reply	other threads:[~2023-02-12  9:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-06  2:21 Bart Schaefer
2023-02-08  3:45 ` Oliver Kiddle
2023-02-08  4:59   ` Bart Schaefer
2023-02-08 23:16     ` Bart Schaefer
2023-02-09  0:47     ` Oliver Kiddle
2023-02-09  2:01       ` Oliver Kiddle
2023-02-09  5:45         ` Bart Schaefer
2023-02-09  4:49       ` Bart Schaefer
2023-02-09 20:49         ` Oliver Kiddle
2023-02-09 23:07           ` Bart Schaefer
2023-02-11  3:04             ` Bart Schaefer
2023-02-11  3:55               ` Bart Schaefer
2023-02-11  5:36                 ` Speaking of dangerous referents Bart Schaefer
2023-02-12  8:00                   ` Oliver Kiddle
2023-02-12  8:34                     ` Bart Schaefer
2023-02-11  7:02               ` [PATCH 1/3]: Add named references Oliver Kiddle
2023-02-11  7:45                 ` Bart Schaefer
2023-02-11 23:43                   ` Bart Schaefer
2023-02-11 23:45                     ` Bart Schaefer
2023-02-12  7:38                     ` Oliver Kiddle
2023-02-12  9:02             ` Oliver Kiddle [this message]
2023-02-12 18:59               ` Bart Schaefer
2023-02-12 19:45                 ` PM_* flags in zsh.h (was Re: [PATCH 1/3]: Add named references) Bart Schaefer
2023-02-12 21:01                   ` Oliver Kiddle
2023-02-12 22:54                 ` [PATCH 1/3]: Add named references 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=94092-1676192523.865597@yGHQ.rexg.4E4Z \
    --to=opk@zsh.org \
    --cc=schaefer@brasslantern.com \
    --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).