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=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10663 invoked from network); 25 Nov 2020 08:47:20 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 25 Nov 2020 08:47:20 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20200801; t=1606294040; b=hlyPfJ8FpYh4smaEO+8LSo3ZmnBxz8RmHZ4CRcRp6sidqsDl/7luUsisp5n5ieVVTH5In+DI5z P/5djF5dQj0wqHHUF+8SVvDOY9wjoch7eL3JYUC3ZAft4mRZDpjuiwCSq+5ZpGqFX1ul2YfEAo lxY+fUdkUylG2RqCsl+Ot3yhlW8TJsvPivuQeGbzyhpW0CXaVETbfjTOHgNve1vmmd9G3vlVrI ZMHoobZji0D3NRzaSXoU0y4XK/V+gM5oL/FX+Q///Qi9SQaDclxyYHNWmJoulN/WYx3V8f/v43 BzjEJU+EawfZB/AtoxvC1Orb7TReSNWtkPARIzP9YLumUw==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-wr1-f52.google.com) smtp.remote-ip=209.85.221.52; dkim=pass header.d=gmail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20200801; t=1606294040; bh=P9VbIMc+XEoMAhlw+YAyK1EBel3qnjW5vi6+18/ceyg=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=Q86O5zLeLjmD2QuR7hD81yRMlOm103I9KBQEci4V6EzNU2TPb0oLT4DT9oZjLFE887liioNQ9U /ISaHEfp4mVlN2hoIGIzVkpfMUbiq1NH4t7GJljc7ExGR5MXU55DDcqcXrKfX3PRTdYfUrqzDI w2iJoFZ+AMjTJr5dpwATXT8iG7WAn2vjD4fmq8OLT0rdz4gw0opbJNKXmUpWu5kjJCw2Wod6JI WuhZVp6kr7k/ZwjBFtb3xM2IVmgf7vui4Wri7n1aIpg6O4dXJAkYV0Cw86/aZcUOLqj4dRHI8K HLv9CSP8/g9KlSD3rrWj5MHjhTpEIrKHkQvLMW9cAMDAgg==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=I86+Edw0nIapOR5Z4N71O8zTPC+/QRS1vk8H5Al0zzw=; b=FPG5g1uL2LNzpRaKSzf5gjz8+w 63wJhalLtGfDIE5S3WZxM4JSPzq8FbLsHYYU4Iy6XQHiSP9hZtz0FKKax/yKFQYYO10aqC3OwblEk UoGTdZtDNOxbB8i9kK+WuPfUkkaSnq+LxqtOWu0wvPhUs8AlRQ0J413CDmkA7tvuO3FURv7WgZJtU /p/imSx1vOVhA00ANsRd2FT5732B0gCJrtyILBHsZngIByHII2hVoLh2hASgPZoU9tcvFr60iVWTQ c2hLlKBah8B8yAh90cVLUAhsPsbsEGTKsGRq7ZoJ9+JNAfBG+3PMe3GQ1pYLmMrV7Lgyh+zyTk5lo cYM0hiQg==; Received: from authenticated user by zero.zsh.org with local id 1khqSM-000PCM-LA; Wed, 25 Nov 2020 08:47:18 +0000 Authentication-Results: zsh.org; iprev=pass (mail-wr1-f52.google.com) smtp.remote-ip=209.85.221.52; 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-f52.google.com ([209.85.221.52]:44519) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1khqRx-000Ovw-Jl; Wed, 25 Nov 2020 08:46:56 +0000 Received: by mail-wr1-f52.google.com with SMTP id 64so1032231wra.11 for ; Wed, 25 Nov 2020 00:46:53 -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=I86+Edw0nIapOR5Z4N71O8zTPC+/QRS1vk8H5Al0zzw=; b=PjSVdcmNuD4RjwUcgCS1CVwHP/b09nm/+NOllnFMiVsl4pwddYzkle16BZ9rWfC3Yy Lvt0AuQAY/6B03SOQPmQAIE2P1uuFSNuanfWJTgCz55sATD5EUNiSm89fPMxum4SJUU+ eG16AASR07HVUoMDVhJtJBGD/6sEshV4vcv/yTIPstK11EuASzfrd+Bz3I6AyjGLDIE5 +oZAYnHHHrneY0ChsLhixjc7IpcY2sbt0ff+rxjEKDsjXB5tcwpALdzwwiMNNZKeGNEo EGS9AAbbBe2ldVP1efuqYxAxE5EyUep0cBYSRu6ZoHhNBxoEPHr50/31AsSxdxFLuHkk nY8w== 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=I86+Edw0nIapOR5Z4N71O8zTPC+/QRS1vk8H5Al0zzw=; b=sNDy2bn4XxteBX/zB7PMEuC2AZUtYYHRjJs3kJFQ31iJ5A6RMvaOc46MKsU1MpJ9kw DQbXLHFWC817DAHIU4npiukfhVelWsz+CjdJS+BJDPodKJsd/EOeuwpjxcJYA58JcVXk pSB2D3Id64c3H7l5SyTzLfoRB/z7K7zEkiqMwDB31zXkfdqS5AO5F5AEv70Lc2lJWDwb x1ac9BnmT/5rNEXsfAtQULdIeNqOoGILT2lVISVE5X3vEnjTwHxncCZWWy96DghOPLHl 8Sgvzr6z1pQ/SKYYqbF59H1qwxAG4bggJFW7kKrplO1L9RVP4e1KBmWL1vgr1eU4Bxfj Ky9w== X-Gm-Message-State: AOAM532Accy2O6QUY7lueBTIJJWOv+ev34T4HvEeVN34cf2BHFQQnc25 VT89274Qs3r11IcreQYj4w7kCZBaQL0bcDZrU/f7cyVrizV14Q== X-Google-Smtp-Source: ABdhPJw7BvVBHirDrc46OeqZQfF64v7Hvzb2AAdbKa1XgwlNAayv6/6ugQxGWNZS8sskGXHGwgGfCCgCMRX35Fyz4yw= X-Received: by 2002:a5d:4349:: with SMTP id u9mr2680220wrr.319.1606294012917; Wed, 25 Nov 2020 00:46:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Felipe Contreras Date: Wed, 25 Nov 2020 02:46:40 -0600 Message-ID: Subject: Re: Bug with unset variables To: Bart Schaefer Cc: Zsh hackers list Content-Type: text/plain; charset="UTF-8" X-Seq: 47623 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 Mon, Nov 23, 2020 at 6:52 PM Bart Schaefer wrote: > > On Mon, Nov 23, 2020 at 3:39 PM Felipe Contreras > wrote: > > > > My argument is about the consistency from user's perspective. > > Consistent from what user's point of view? Any user. > One coming to zsh from > other languages or one long familiar with zsh? Because zsh > development has consistently (ahem) sided with the latter. Users can get accustomed to inconsistent behavior. The fact that some users have become accustomed to X doesn't mean X is consistent. > > This is the example I gave to Roman, which went completely unresponded: > > > > func () { > > [[ -n "$1" ]] && var=$1 > > dosomething ${var-other} > > } > > > > func () { > > typeset var > > [[ -n "$1" ]] && var=$1 > > dosomething ${var-other} > > } > > In the first case, $var is a global, so the behavior of ${var-other} > is unknown. It's not possible to write deterministic code. You are looking at the half of the picture that is irrelevant. The behavior of "func foobar" is deterministic, and you know what it will do. > In the second case, there's a knowable behavior of ${var-other}. That > behavior doesn't match your expectation, but it's well-defined. Nobody is saying it's not well-defined, we are talking about *consistency*. Only *one* change was added to B, and the behavior changed in *two* ways. > To make the first function deterministic, it is necessary to write: > > func () { > unset var > [[ -n "$1" ]] && var=$1 > dosomething ${var-other} > } > > Whether one should expect "typeset var" to imply "unset" is how we > ended up in this discussion. The only difference from A to B is that B has a line that says "declare 'var' as a local variable". That's a fact. And the behavior of the function changes in two ways (other than what was told to do). That's also a fact. It is a fact that the code is doing more than what it was told to do. If you have an operator called "declare_local_variable", and you do this: declare_local_variable var You run the code, and you find that declare_local_variable does indeed declare a local variable, but it *also* sets your cat on fire. You investigate, and you find out the documentation clearly states that declare_local_variable sets your cat on fire, so the behavior is "well-defined". But it's not what it says on the tin. Any normal person would expect such behavior to be enabled by: declare_local_variable var set_cat_on_fire And not have to type: delcare_local_variable_but_dont_set_cat_on_fire var Or worse: declare_local_variable var put_out_fire_from_cat It doesn't matter how well explained it is in the documentation, or how many people are accustomed to this behavior, it's still doing *more* than one thing. Now, you can call the fact that it's changing the behavior in more than one way any way you want. When most operators in most languages do one thing--and one thing only--and this operator does *two* things, I call that inconsistent. Maybe there's a better way to describe this fact. Maybe Git's notion of logically separate changes [1] helps (e.g. you should not mix whitespace cleanups with functional changes). But the fact is that in virtually all languages (and bash and ksh) there's an idiom to declare a local variable and *only* declare a local variable (not do anything else). Can we at least agree on that? In zsh typeset does *two* things. Cheers. [1] https://git-scm.com/docs/SubmittingPatches -- Felipe Contreras