From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13530 invoked by alias); 25 Jun 2015 09:29:39 -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: 35601 Received: (qmail 12948 invoked from network); 25 Jun 2015 09:29:36 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS autolearn=ham autolearn_force=no version=3.4.0 X-AuditID: cbfec7f4-f79c56d0000012ee-da-558bc9fcee2f Date: Thu, 25 Jun 2015 10:29:23 +0100 From: Peter Stephenson To: Zsh Hackers' List Subject: Re: Typeset with array Message-id: <20150625102923.1dc227ff@pwslap01u.europe.root.pri> In-reply-to: <7337.1434735386@thecus.kiddle.eu> References: <5578996E.3080700@thequod.de> <150610191427.ZM30841@torch.brasslantern.com> <5579C247.1060800@thequod.de> <150611183639.ZM32247@torch.brasslantern.com> <20150612094237.338f79d5@pwslap01u.europe.root.pri> <20150619123930.2688d9e3@pwslap01u.europe.root.pri> <7337.1434735386@thecus.kiddle.eu> 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+NgFjrMLMWRmVeSWpSXmKPExsVy+t/xK7p/TnaHGizoFLc42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGY8nTWcpOCdecWbOKqYGxtVCXYwcHBICJhJHDrp1MXICmWIS F+6tZ+ti5OIQEljKKNG6Yg87hDODSaL/9i1GCGcbo8SUdVeZQFpYBFQl3u9ZzgJiswkYSkzd NJsRZKqIgLZE+0cxkLCwgLzE7pP7mUFsXgF7if2POsDKOQX0JX5eOcwEMXMHk8Tj2/1sIAl+ oMTVv5+YIE6yl5h55QwjRLOgxI/J98CamQW0JDZva2KFsOUlNq95C7ZASEBd4sbd3ewTGIVm IWmZhaRlFpKWBYzMqxhFU0uTC4qT0nMN9YoTc4tL89L1kvNzNzFCgvbLDsbFx6wOMQpwMCrx 8FbYdocKsSaWFVfmHmKU4GBWEuHtOggU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzjt31/sQIYH0 xJLU7NTUgtQimCwTB6dUAyOvxgduAbtWxTUFC2M3Tl+7cit//63Lei4LP2/+8vrn3HW7Fmy7 2c2xsYZ74v2lhz10hKfm3vhbLrAt7fb2KXKJlecXcy/eX5A2KabWqvdEgU/RloytsiL9EY/3 VFmY/rC3UP/r/HSV7JXfWU0CiziZZHlmfOxelvpvdjXLnpJ5KvWGtQv1jD2VWIozEg21mIuK EwG5tR42VgIAAA== On Fri, 19 Jun 2015 19:36:26 +0200 Oliver Kiddle wrote: > local -a foo=one > So scope needs to be handled first and array conversion later. > Similarly: typeset -i foo=(23) I decided to make these errors --- the user is in a good position to do the right thing here since it's staring them in the face and fixing things up in typeset by guessing what the user actually meant is (you can trust me on this :-/) very messy, so I think this is reasonable. > I did something like the following in _git recently. It works > arr=( one two three ) > local $arr > There is also > local $^arr=foo > and > local $^^arr=foo > The nearest in bash would be: > declare {a,b,c}=foo > which works, but not: > declare {a,b,c}=(one two) I think this is now working as expected and documented. > Bash apparently lets you use += with declare but it seems to be > meaningless because it is not using the value from the outer scope: > $ foo=hello > $ function foo { > > local foo+=bye > > echo $foo > > } > $ foo > bye > $ echo $foo > hello > Ksh doesn't allow it. Printing an error in this case seems best which is > what you have: typeset: not valid in this context: var+ This is still the case. > Bash allows array element assignments: > typeset var[4]=hello > Zsh now prints "can't create local array elements" > Including when not in a function. The problem isn't the assignment but you haven't yet told the shell that "var" is a (local?) variable or what type it is. So it's claiming to be a bit confused. Do you really mean it to update an existing array var, as it looks like, or don't you? Or are you replacing the 4th character of a scalar (which doesn't actually exist yet) with a string? Both work if var already exists, but if it doesn't it's syntactically ambiguous even if you could probably guess that it should create ('' '' '' hello). We could tweak this, but it's at the point where I'm not 100% convinced it's the right thing to do. > That could also be extended to something like var[2,7]=(1 2) Extending assignments (at least to existing arrays) to handle array slices would certainly be natural, yes. I hope must of the mechanism is already present and just needs borrowing from addvars(). > This is perhaps jumping ahead a bit but for completion, it seems we now > get -command- context after typeset. As long as -var- context is applied > inside the actual contexts, having -command- context otherwise for > typeset would probably work fine. That still needs looking at --- as this is a rather grungy interface into the main shell it's a bit of a dark art whether this should be tweaked by fixing up the context or fixing up the handler, or whether it's one of the cases where the Red Death holds illimitable sway and dominion. With any luck one of the first two is possible. Scalar and array contexts after typeset assignment seem to be working OK as a -value-. pws