Zsh Mailing List Archive
Messages sorted by:
Re: Another push on declarednull branch
- X-seq: zsh-workers 47778
- From: Felipe Contreras <felipe.contreras@xxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: Another push on declarednull branch
- Date: Mon, 28 Dec 2020 18:43:20 -0600
- Archived-at: <https://zsh.org/workers/47778>
- Archived-at: <http://www.zsh.org/sympa/arcsearch_id/zsh-workers/2020-12/CAMP44s1X2PPv-hxCL4oqHu6VnkS755GJj%2B_zbFPfhBuC3zkBFQ%40mail.gmail.com>
- Authentication-results: zsh.org; iprev=pass (mail-wm1-f45.google.com) smtp.remote-ip=126.96.36.199; dkim=pass header.d=gmail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none
- Cc: "zsh-workers@xxxxxxx" <zsh-workers@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iv5k8vnL/xW6FXFveS4OUGHv3s8bS5Xxi6EgFQmXw7M=; b=TwcFxJn6/pnZjHf19pGhOFmcM7ZrFYm8KT+Q3EZZXnK2YWVECr2J1aBz5gnkzHLnoI IiaolW9KpaLBcWOhCagWO6Lpe3yxm4Z7lC9LiZwNCa/gZUthkFPNXlo2KJy1tH6PRoy7 hfD0AaHlhpioYg/EM9KTRQx2bje9WUUY95CuI1ZUlTlUilQjnrSk2wg9H6l5ylr0KUqT t/q8GS9JR92GxgDwzGWqkf2PFI2VkY8WnmBAxPLIP0P/STJGs/xGpmbKHJLwiPzmn29Q jYBB3NECXLUjtthd8X9tBlRM+5E1otjvUjMHQ30z98hRyjuEvmi95wafZ724rfK/5ZGB pcJA==
- In-reply-to: <CAH+w=7addhX4fzZkrOV266XLU_yW6bciiDi5aQreLjC-wGfirstname.lastname@example.org>
- List-archive: <http://www.zsh.org/sympa/arc/zsh-workers>
- List-help: <mailto:email@example.com?subject=help>
- List-id: <zsh-workers.zsh.org>
- List-owner: <mailto:firstname.lastname@example.org>
- List-post: <mailto:email@example.com>
- List-subscribe: <mailto:firstname.lastname@example.org?subject=subscribe%20zsh-workers>
- List-unsubscribe: <mailto:email@example.com?subject=unsubscribe%20zsh-workers>
- References: <firstname.lastname@example.org> <CAH+w=7ayKmgc3qPWLr8+NHLCmmhcQxo+n=cAO3pyriTjsNpTQQ@mail.gmail.com> <CAMP44s02TKNRHr6x5=noKsvxkKKtvUbdDb40_usfOzgn-Gnmbw@mail.gmail.com> <CAH+w=7a9P0+npTgJCzzF1eFt2KFjXNs+fL1K7CFRYiBFEEQTog@mail.gmail.com> <CAMP44s0jqp=irVq7JSFoUtfuj6XsOpur=y4EXNDxneRtH=oE4g@mail.gmail.com> <CAH+w=7addhX4fzZkrOV266XLU_yW6bciiDi5aQreLjC-wGemail@example.com>
- Sender: zsh-workers-request@xxxxxxx
On Mon, Dec 28, 2020 at 4:53 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Mon, Dec 28, 2020 at 1:46 PM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
> > On Mon, Dec 28, 2020 at 2:54 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > >
> > > Would it make more sense as PM_IMPLICIT, so PM_NULL = (PM_IMPLICIT|PM_UNSET)?
> > It's still the same problem isn't it? Why does typeset turn on
> > PM_IMPLICIT, and unset off?
> Typeset turns on PM_IMPLICIT because there's nowhere else that needs to.
Yes, but why PM_IMPLICIT?
The word "implicit" means unexpressed, or implied. There's nothing
implied about "typeset"; it's expressly declaring a variable.
> Unset turns it off because the variable explicitly ceases to exist;
> only its scope remains, if it had one.
Yes, the variable "ceases to exist", but it's not any less implicit.
> > Moreover, implicit what?
> Implicit(ly) whatever-other-flags-are-there.
I presume that doesn't apply to PM_INTEGER, PM_LOCAL, or pretty much
any flag that is not PM_UNSET.
In other words: PM_UNSET is the only flag that can be explicit, or implicit.
> > The true meaning is PM_UNSET_BUT_VALID, because the only time this
> > flag does something is when PM_UNSET is on.
> I don't think "valid" is a significantly more accurate description.
> $thing is "valid" whether or not you've declared "typeset thing".
Yes, but that's my point; currently (as in; in master) "valid"
variables are implicitly the ones that are !PM_UNSET, now that concept
> Anyway, I conceived PM_DECLARED (now for this discussion PM_IMPLICIT)
> as having a meaning independent of PM_UNSET; for example
> PM_IMPLICIT|PM_INTEGER means that if you assign to the variable, the
> value is interpreted as a number.
> That was before I realized that "unset foo" forgets everything about
> "foo" except its scope. That is, I began from the position that
> typeset -f foo
> unset foo
> needed to resurrect foo as a float rather than a string ... but it
> doesn't, in bash/ksh. Hence unset must erase PM_IMPLICIT along with
> everything else.
OK. So now it only makes sense with PM_UNSET.
> > I think that's a clear sign the logic is not correct.
> > It's the other way around
> Unfortunately given the bitwise implementation that condition is much
> more complicated to test for; the reversal is for convenience. Zsh is
> full of bitfield-like booleans that mean nothing unless combined with
> other such booleans.
Sure, but PM_NULL can fulfill that purpose perfectly fine (instead of
Messages sorted by: