zsh-workers
 help / color / mirror / code / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: More rabbit-holes with unset variables
Date: Fri, 27 Nov 2020 16:10:06 -0600	[thread overview]
Message-ID: <CAMP44s1i6uC72LhqGmt_hg-YUoFtJTKcC6o2qTGLHZJ3tB56CA@mail.gmail.com> (raw)
In-Reply-To: <CAH+w=7arBoRxmFRH7wL_Sh-0tRe1Xyo_GKze+jkSdvYep7NMWg@mail.gmail.com>

On Fri, Nov 27, 2020 at 2:54 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Thu, Nov 26, 2020 at 5:30 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > What zsh refers to as "scalar" internally is a string:
> >
> >   char *str; /* value if declared string  (PM_SCALAR)  */
> >
> > From Src/zsh.h (struct param).
>
> This is exactly the discussion I was trying to avoid when I said "in
> the abstract that doesn't matter".
>
> You can't just pull one field out of a union inside a struct and
> ignore the struct itself and the API for field access that goes with
> it.

I am not. I have been looking at the code and fixing some inconsistencies.

From what I can see PM_SCALAR is considered a string, and the thing
I'm putting more emphasis on is the comment: "value if declared
string".

> > So if you didn't mean string, what did you mean?
>
> I meant a struct param, containing the least specific thing so
> represented, as interpreted through all the layers of code that
> implement a dereference of its value when you write $var or any of its
> variations.  Again this doesn't actually matter, which is why I didn't
> spell it out.

The least specific thing--which happens when you do "static struct
param p"--sets the type to PM_SCALAR (0), which from what I can see
for all intents and purposes is a string.

> > And what did you mean by 'so a the only useful "declared but not set"
> > variable is a simple scalar'?
>
> As the very first message in this thread demonstrated, in both bash
> and ksh (call this "example one", and to be pedantic assume that X is
> not inheriting its name or value from somewhere):
>
> typeset -i X
> echo ${X-nil}
> X="garbage"
> echo ${X-nil}
>
> will output
>
> nil
> 0
>
> However (call this "example two"):
>
> typeset -i X
> unset X
> X="garbage"
> echo ${X-nil}
>
> outputs
>
> garbage
>
> The language you quoted from the posix proposal says "otherwise, the
> variable is initially unset".  Given that proposed language, example
> one is incorrect, because an "unset" variable should not retain its
> (in this example) integer properties when assigned a string.

I agree. I would say "imprecise" rather than "incorrect", since if all
these threads taught us anything is that it's not so clear to define
what we mean by "unset", "nil value", or "no value".

> > What simple scalar other than a string is useful "declared but not set"?
>
> Under this interpretation, there isn't any.  That's what I said.  In
> fact the last paragraph of the very first message in this thread:
>
> "Therefore, this isn't as simple as having zsh create an unset
> variable when typeset is given no assignment, because subsequent
> assignment has to preserve the type of the variable, which normally
> does not apply after unset."

So we can interpret what you said as 'so the only useful "declared but
not set" variable is a string' without losing any meaning.

Cheers.

-- 
Felipe Contreras



  reply	other threads:[~2020-11-27 22:10 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-25  7:02 Bart Schaefer
2020-11-25 13:19 ` Stephane Chazelas
2020-11-25 22:17   ` Felipe Contreras
2020-11-26  6:10     ` Stephane Chazelas
2020-11-26  7:20       ` Felipe Contreras
2020-11-26 11:21         ` Oliver Kiddle
2020-11-26 11:29           ` Roman Perepelitsa
2020-11-26 19:08             ` Felipe Contreras
2020-11-26 19:29           ` Felipe Contreras
2020-11-26 21:13           ` Bart Schaefer
2020-11-26 21:31             ` Felipe Contreras
2020-11-26 23:29               ` Bart Schaefer
2020-11-26 23:32                 ` Bart Schaefer
2020-11-26 23:53                 ` Felipe Contreras
2020-11-27  0:23                   ` Bart Schaefer
2020-11-27  1:51                     ` Felipe Contreras
2020-11-27 20:01                       ` Bart Schaefer
2020-11-27 21:49                         ` Felipe Contreras
2020-11-27 22:06                           ` Bart Schaefer
2020-11-27 23:35                             ` Felipe Contreras
2020-11-26 22:07       ` Bart Schaefer
2020-11-26 20:41     ` Bart Schaefer
2020-11-26 20:49       ` Stephane Chazelas
2020-11-26 21:20       ` Felipe Contreras
2020-11-26 22:41         ` Bart Schaefer
2020-11-26 23:45           ` Felipe Contreras
2020-11-27  0:09             ` Bart Schaefer
2020-11-27  0:30               ` Felipe Contreras
2020-11-27  0:51                 ` Bart Schaefer
2020-11-27  1:30                   ` Felipe Contreras
2020-11-27 20:54                     ` Bart Schaefer
2020-11-27 22:10                       ` Felipe Contreras [this message]
2020-11-27 22:39                         ` Bart Schaefer
2020-11-28  0:00                           ` Felipe Contreras
2020-11-28  0:04                             ` Bart Schaefer
2020-11-28 10:52                               ` Felipe Contreras
2020-11-28  0:36                             ` The emulation rabbit-hole RE typeset/unset Bart Schaefer
2020-11-28 11:35                               ` Felipe Contreras
2020-11-28 16:56                                 ` Bart Schaefer
2020-12-01  8:49                                   ` Felipe Contreras

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=CAMP44s1i6uC72LhqGmt_hg-YUoFtJTKcC6o2qTGLHZJ3tB56CA@mail.gmail.com \
    --to=felipe.contreras@gmail.com \
    --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).