From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,RDNS_NONE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.4 Received: from authenticated user by zero.zsh.org with local id 1kilwq-0001nC-3e; Fri, 27 Nov 2020 22:10:36 +0000 Authentication-Results: zsh.org; iprev=pass (mail-wr1-f42.google.com) smtp.remote-ip=209.85.221.42; dkim=pass header.d=gmail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-wr1-f42.google.com ([209.85.221.42]:34725) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1kilwY-0001YZ-9q; Fri, 27 Nov 2020 22:10:18 +0000 Received: by mail-wr1-f42.google.com with SMTP id k14so7016208wrn.1 for ; Fri, 27 Nov 2020 14:10:18 -0800 (PST) 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=KjZBMz23b/hN7DRY0Ts66Y+ExuJkp0y/I/V5bjKTd3k=; b=EbNIQxpZk4IAaaq1ElUYYBShXOP7MhWRt3d0WqZCkDGzFUcl/r9KvucUvdcUpm/Xi/ Qb1BQTSDrNKtWl2szfoLwwhQx0HgXBfKOhQ1xQ+mx1Mh0IY3Xj/pcYdGFW7rd+jrnNso ytzI1++t6CIC6MxtWmFmeWp6O5rbwgfVl57pKcGES2NUlzUdo1F7nRVcrDTvcgpc7+0a BXpD/Nnt9n+Xryh4Mzyfik7WUV6HAIIw68VTLnrl+VlPZMuBAkiE/tVSRGMvjhRjcoau hyIR84O7LMDnPGcQYskIdNSKmNzcqdImt2GPQpBrppPsteo3ESQEHxBg5GQHZDv8jDhc 8LZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KjZBMz23b/hN7DRY0Ts66Y+ExuJkp0y/I/V5bjKTd3k=; b=jAxv1v2VCdtNKDV7CbuCi1ANKViL7n3/XTi7ywWuOBTaKQLb4sbcyu04d44D9xCX/U pajZTJe71cFWF9cx75R9mA6aD239p2RczY6h4BW+Pulo65vYprvW+Cn+nND86djFIXF7 Zy8IIMpmaIbOqKDqd9rEmp2xaMvzEOFS57/2UvWovnZrdzyP+dIm7yx611JMULW8UA04 wDkNpTmBBla3b4igPRB5MoAQiwWXZGTbiDGlZKBgPlyD5E+jGwu7kbQQh0I3MLt0HSrV jdCoO4j+ixL6w7M/+yqR6V1/897+2Jfqd+5ZqN/o/WMv9qoCIRpWpiGOzqCphO4krhxB ug1g== X-Gm-Message-State: AOAM531IayzGTlGr/3h7XXMwlWj8RA1lF80lH5j51OA8EDWrLavhAAFJ l2nxVTtOUtGkhGo9cDhzRvlSo+z1j8IyDkdSP8Y= X-Google-Smtp-Source: ABdhPJzYoIT0HDjlQlQSlNyQGI38NBj5FnUqdmtoWX7901EqqaBHxI/QPXlCSwKwRzuAvN2wNJ0l395X/uc4BBc16rQ= X-Received: by 2002:a5d:4349:: with SMTP id u9mr13044967wrr.319.1606515018053; Fri, 27 Nov 2020 14:10:18 -0800 (PST) MIME-Version: 1.0 References: <20201125131921.vay7h3xk5qn4odgg@chazelas.org> In-Reply-To: From: Felipe Contreras Date: Fri, 27 Nov 2020 16:10:06 -0600 Message-ID: Subject: Re: More rabbit-holes with unset variables To: Bart Schaefer Cc: Zsh hackers list Content-Type: text/plain; charset="UTF-8" X-Seq: 47679 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: On Fri, Nov 27, 2020 at 2:54 PM Bart Schaefer wrote: > > On Thu, Nov 26, 2020 at 5:30 PM Felipe Contreras > 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