From: "Daniel Shahaf" <d.s@daniel.shahaf.name>
To: "Bart Schaefer" <schaefer@brasslantern.com>
Cc: "zsh-workers@zsh.org" <zsh-workers@zsh.org>
Subject: Re: [PATCH] declarednull: rename DECLARED to NULL
Date: Wed, 06 Jan 2021 16:02:12 +0000 [thread overview]
Message-ID: <4e9d7283-94fa-4862-ab04-8c3294f3876c@www.fastmail.com> (raw)
In-Reply-To: <CAH+w=7ZX8ddgLH3DdsrCg6pgxY8KbRo1nqF5qLxZ2HL0JtcWNw@mail.gmail.com>
Bart Schaefer wrote on Mon, 04 Jan 2021 21:57 +00:00:
> On Sun, Jan 3, 2021 at 10:17 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > Could you summarize the bits that need to be named and the corresponding shell
> > language incantations/semantics?
>
> There has been a series of threads about this, but to try to summarize:
>
> In current zsh,
> typeset -i var
> typeset -p var
> print ${var-foo}
> produces the output
> typeset -i var=0
> 0
⋮
> This disagrees with e.g. bash/ksh, so the proposal is that with
> POSIXBUILTINS set, the same three commands would output
> typeset -i var
> foo
>
Thanks for the summary.
> So the "bits that need to be named" are:
> 1) the bit representing "remember that this was declared but no value
> was assigned"
> 2) the combination of that with PM_UNSET that represents "functionally
> behaves like NULL"
>
> We could of course simply never name #2 and always write out the
> bitwise-OR, but that seems cumbersome.
>
To be clear, (2) would generally be used as testing whether _either_
PM_UNSET or the bit from #1 is set, right?
How about, for #1, PM_BEEN_ASSIGNED or PM_INITIALIZED?
As to the combination, my first inclination would have been to leave it
unnamed so that it's obvious PM_UNSET is being inspected, but if the
combination merits being named, then perhaps PM_HAS_VALUE(pm).
> As I understand it, the objection to PM_DECLARED for #1 is that the
> name implies that only "unset var" should ever turn that bit off
> again, but the implementation requires that assignment also turns it
> off. Similar objections of English language semantics conflicting
> with the implementation have been raised to other names I've
> suggested.
*nod*
Cheers,
Daniel
next prev parent reply other threads:[~2021-01-06 16:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-28 22:13 Felipe Contreras
2021-01-03 1:18 ` Bart Schaefer
2021-01-03 2:38 ` Felipe Contreras
2021-01-03 18:26 ` Bart Schaefer
2021-01-04 6:17 ` Daniel Shahaf
2021-01-04 21:57 ` Bart Schaefer
2021-01-06 16:02 ` Daniel Shahaf [this message]
2021-01-06 17:33 ` Bart Schaefer
2021-01-07 15:48 ` Daniel Shahaf
2021-01-07 22:29 ` Bart Schaefer
2021-03-27 19:24 ` Lawrence Velázquez
2021-03-27 20:42 ` Bart Schaefer
2021-03-29 0:44 ` Oliver Kiddle
2021-04-10 18:56 ` Bart Schaefer
2021-04-10 21:58 ` Oliver Kiddle
2021-04-10 22:35 ` 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=4e9d7283-94fa-4862-ab04-8c3294f3876c@www.fastmail.com \
--to=d.s@daniel.shahaf.name \
--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).