zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: One possible answer to typeset vs. unset
Date: Fri, 4 Dec 2020 07:49:54 -0800	[thread overview]
Message-ID: <CAH+w=7YxvpfjxCP9i9fHSfu0TWXpiCqXrmLkiVDDiDjZWLC8xQ@mail.gmail.com> (raw)
In-Reply-To: <CAMP44s3y2zqbG=8Zxqmn5RcwHC-CF2VaiwADhUbj2AokRKndkA@mail.gmail.com>

On Fri, Dec 4, 2020 at 3:04 AM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> On Thu, Dec 3, 2020 at 3:19 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > I looked at this for a while yesterday evening.  My conclusion is that
> > tied variables are already a bit of a hack.

Part of my latest commit log on the declarednull branch:

The scalar struct param of a tied pair stores a direct pointer to the
internal array value of the array struct param, and upon assignment
modifies it without referring to the containing struct. This means
that there's no opportunity to clear the PM_DECLAREDNULL bits on both
structs when the scalar is assigned. Conversely, assigning to the
array does use the struct for the scalar.

I think this can be fixed but I don't want it to become inefficient.
OTOH, tied parameters (other than specials, which are different in
several ways) may not be used (or updated when they are) very much.

> > Consequently I don't know if your patch would cause a different test
> > for unset-ness (that hasn't been written yet) to fail, but something
> > like that patch may be unavoidable.
>
> I can't parse that. What would such unset-ness test do?

Check that both elements of the pair appear to be unset when neither
has been initialized.

As it currently stands on the branch, following

typeset -T TIED_SCALAR tied_array

These

typeset -p TIED_SCALAR
typeset -p tied_array

print differing initializers.


  reply	other threads:[~2020-12-04 15:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-28 19:49 Bart Schaefer
2020-11-28 20:00 ` Bart Schaefer
2020-11-28 20:21 ` Bart Schaefer
2020-12-01  8:54 ` Felipe Contreras
2020-12-03 21:19   ` Bart Schaefer
2020-12-04 11:04     ` Felipe Contreras
2020-12-04 15:49       ` Bart Schaefer [this message]
2020-12-04 19:47         ` Bart Schaefer
2020-12-05  0:22           ` Bart Schaefer
2020-12-05  0:28         ` Bart Schaefer
2020-12-05  0:51       ` Bart Schaefer
2020-12-05 22:17         ` Bart Schaefer
2020-12-23 23:00         ` Felipe Contreras
2020-12-02 17:18 ` Vincent Lefevre
2020-12-02 18:03   ` Bart Schaefer

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=7YxvpfjxCP9i9fHSfu0TWXpiCqXrmLkiVDDiDjZWLC8xQ@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=felipe.contreras@gmail.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).