From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29258 invoked by alias); 19 Jan 2017 16:08:55 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 40388 Received: (qmail 4541 invoked from network); 19 Jan 2017 16:08:54 -0000 X-Qmail-Scanner-Diagnostics: from mailout3.w1.samsung.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(210.118.77.13):SA:0(-8.2/5.0):. Processed in 1.412736 secs); 19 Jan 2017 16:08:54 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-8.2 required=5.0 tests=RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: p.stephenson@samsung.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at samsung.com does not designate permitted sender hosts) X-AuditID: cbfec7ef-f79d26d00000420c-c6-5880e48f8f17 Date: Thu, 19 Jan 2017 16:08:41 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: LOCAL_VARS option ? Message-id: <20170119160841.354ec75c@pwslap01u.europe.root.pri> In-reply-to: Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsWy7djPc7r9TxoiDDYuU7U42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGft+TmQpWCBecfOXbwPjLqEuRk4OCQETiRtvPrNA2GISF+6t Z+ti5OIQEljGKHH8ZQtYQkigl0ni8kJRmIZva06ywhX97FrMAuFMY5Lo29rLDuGcYZQ4tP46 M4RzllHi3MVbTF2MHBwsAqoSnfPZQEaxCRhKTN00mxHEFhEQlzi79jzYOmEBBYl1V24xg9i8 AvYSr9tngNVwCrhIzH82FayGX0Bf4urfT0wQJ9lLzLxyhhGiXlDix+R7YDXMAjoS27Y9Zoew 5SU2r3kLdo+EwH82ic7Nq1lA7pEQkJXYdIAZYo6LxIudm9khbGGJV8e3QNkyEpcnd0PDqJ9R 4km3L8ScGYwSp8/sYINIWEv03b7ICLGMT2LStunMEPN5JTrahCBMD4lNy9IhTEeJ+2dkJjAq zkJy9CwkR89CcvQCRuZVjCKppcW56anFhnrFibnFpXnpesn5uZsYgQng9L/j73cwPm0OOcQo wMGoxMO740RDhBBrYllxZe4hRgkOZiUR3jO3gUK8KYmVValF+fFFpTmpxYcYpTlYlMR59y64 Ei4kkJ5YkpqdmlqQWgSTZeLglGpgnJ4iFb1n0du2/rK/m9tPfY8tirTePLPDwI31eUes9/qG G7kPlY9V7NLXSWO8t3zLgQfuDbObVQ9FWZ2Z1pujd3ZHS0nVmfieGU94uK7+2bdEzaVtyu3r J20nvJCTE0lJiLGL2ti4tDJl5augdOc/vfu458jlW755PtFKr9qW/8q+60apaQ+mKrEUZyQa ajEXFScCAEegyCz8AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsVy+t/xa7rtTxoiDN73algcbH7I5MDoserg B6YAxig3m4zUxJTUIoXUvOT8lMy8dFul0BA3XQslhbzE3FRbpQhd35AgJYWyxJxSIM/IAA04 OAe4Byvp2yW4Zez7OZGlYIF4xc1fvg2Mu4S6GDk5JARMJL6tOckKYYtJXLi3nq2LkYtDSGAJ o8SnU1/ZIZwZTBKtx99AOecYJf58/8wC4ZxllLi5dRFTFyMHB4uAqkTnfDaQUWwChhJTN81m BLFFBMQlzq49zwJiCwsoSKy7cosZxOYVsJd43T4DrIZTwEVi/rOpUDOPM0pMPn8QrIhfQF/i 6t9PTBD32UvMvHKGEaJZUOLH5HtgQ5kFtCQ2b2tihbDlJTaveQvWKySgLnHj7m72CYzCs5C0 zELSMgtJywJG5lWMIqmlxbnpucVGesWJucWleel6yfm5mxiBUbTt2M8tOxi73gUfYhTgYFTi 4d1xoiFCiDWxrLgy9xCjBAezkgjvmdtAId6UxMqq1KL8+KLSnNTiQ4ymwICZyCwlmpwPjPC8 knhDE0NzS0MjYwsLcyMjJXHeqR+uhAsJpCeWpGanphakFsH0MXFwSjUwXo79IP39SJN5h7Gb xc7p5sLyfU4ShZUGNybm1LRlypq9WDst8ej5hU6PX/+0aM+LzTn0rjrno+7R7byT1Z2ORV3y e+Bkvvwh397VswwjvgWG2AitPScRo1ZuYxqi/WF+v/Tp7O6GoKNPxP8+0LIMaP535poEO8P/ mvNsIZXloasdOv4lbNFSYinOSDTUYi4qTgQALCsXM7gCAAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170119160844eucas1p15f44858c0185e554b5f2a7193ae09207 X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 X-Local-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUb?= =?UTF-8?B?7IK87ISx7KCE7J6QG1ByaW5jaXBhbCBFbmdpbmVlciwgU29mdHdhcmU=?= X-Global-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUbU2Ft?= =?UTF-8?B?c3VuZyBFbGVjdHJvbmljcxtQcmluY2lwYWwgRW5naW5lZXIsIFNvZnR3YXJl?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDA1Q0QwNTAwNTg=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20170119155014epcas1p3534510d7cf4809b97464615de3dd3544 X-RootMTR: 20170119155014epcas1p3534510d7cf4809b97464615de3dd3544 References: <20170119065408.GA5534@fujitsu.shahaf.local2> On Thu, 19 Jan 2017 07:47:53 -0800 Bart Schaefer wrote: > > Phil suggested on IRC a LOCAL_VARS option that has the effect of making > > all newly-declared variables local > > I believe we discussed this idea once before, and rejected it on several > grounds. However, I can't find the thread at the moment. From memory: > > 1. Once the option is set, it affects all functions called by (whether > directly or indirectly) the one that set the option. If set at the > top level, this results in a significant change in semantics. I suspect we'd even need "emulate -L zsh" to *un*set the option to restore sanity. Otherwise you're not emulating native zsh variable semantics. There's some prior art for resetting options at each function level, but it's another icky complexity. > 2. Unlike local_options, which applies when the function exits, this has > to be applied when the parameter is created. There's already a > mechanism to accomplish this, namely to declare the parameter. The > only reason to need local_vars is to change the semantics of *other* > functions [see (1)], which is generally a bad idea. Hmmm... I suspect people would want to set it to protect their own functions, rather than randomly assume what other functions they have are or are not doing with variable scoping, which would be a bad thing to assume. But other people's functions are likely to get caught in the crossfire anyway. > 3. If unset by a called function in order to prevent (2) and that called > function is NOT also using local_options, it can break the calling > function in unpredictable ways. I think that mostly means the way to turn this off (other than implicitly at each level) would be setopt localvars localoptions but if you have some reason for unsetting localoptions you are stuck. > 4. The semantics of the other LOCAL_* options are already problematic in > obscure ways, but just because we're stuck with them doesn't mean we > should add another potentially problematic variation. Well, the *reason* for adding them is a bit of extra safety, rather than creating problems as side-effects... but I agree about the potential problems. In fact, my best argument against this probably is the knock-on effects of everything that has to be made consistent, which I think is hard to foresee, and the variable code is famously complicated already. > 5. (New since the last time this was discussed) The type of problem this > "solves" is generally better addressed by WARN_CREATE_GLOBAL so that > proper use of parameter declarations can be applied. Yes, that makes a difference, but it doesn't detect the case where you re-use a variable in a nested function without redeclaring it. (That can be done, too, by comparing variable levels, but it's a significantly more intrusive option --- consider the completion system.) pws