From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1439 invoked from network); 25 May 2006 15:16:11 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 25 May 2006 15:16:11 -0000 Received: (qmail 56920 invoked from network); 25 May 2006 15:16:05 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 25 May 2006 15:16:05 -0000 Received: (qmail 21899 invoked by alias); 25 May 2006 15:16:03 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 22459 Received: (qmail 21890 invoked from network); 25 May 2006 15:16:02 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 25 May 2006 15:16:02 -0000 Received: (qmail 56636 invoked from network); 25 May 2006 15:16:02 -0000 Received: from cluster-c.mailcontrol.com (168.143.177.190) by a.mx.sunsite.dk with SMTP; 25 May 2006 15:16:00 -0000 Received: from cameurexb01.EUROPE.ROOT.PRI ([62.189.241.200]) by rly13c.srv.mailcontrol.com (MailControl) with ESMTP id k4PFFrWn004546 for ; Thu, 25 May 2006 16:15:57 +0100 Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 16:15:20 +0100 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.13.4/8.13.4) with ESMTP id k4PFFuWI017396 for ; Thu, 25 May 2006 16:15:56 +0100 Received: from csr.com (pws@localhost) by news01.csr.com (8.13.4/8.13.4/Submit) with ESMTP id k4PFFt92017392 for ; Thu, 25 May 2006 16:15:56 +0100 Message-Id: <200605251515.k4PFFt92017392@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: Re: values of associations pointed by P flag In-reply-to: <060523081402.ZM15072@torch.brasslantern.com> References: <20060522205404.GA24028@ulpmm.u-strasbg.fr> <060523081402.ZM15072@torch.brasslantern.com> Comments: In-reply-to Bart Schaefer message dated "Tue, 23 May 2006 08:14:00 -0700." Date: Thu, 25 May 2006 16:15:55 +0100 From: Peter Stephenson X-OriginalArrivalTime: 25 May 2006 15:15:20.0656 (UTC) FILETIME=[09A84D00:01C6800E] Content-Type: text/plain MIME-Version: 1.0 X-Scanned-By: MailControl A-07-00-01 (www.mailcontrol.com) on 10.67.0.123 Bart Schaefer wrote: > (And the doc could be > clearer, but it all stems from the fact that zsh parameter expansion > works by passing values of parameters, not references to parameters.) [Moved to zsh-workers in order to ramble aimlessly.] We really need passing by reference, though, not just for confusing cases like this (I don't think I'd have guessed that you could use "hash[key]" as an indirect reference, either), but for plenty of other uses. One place I get into trouble all the time is passing back values, where I'm always falling over the namespace problem: sub() { local foo foo=something_i_needed_to_work_out if [[ $1 = foo ]]; then print "Oops, I've got my own foo." >&2 return 1 else foo[thiskey]=some_expression_that_needs_passing_back_involving_$foo foo[thatkey]=another_one fi } fn() { local -A foo sub foo do_something_with ${(kv)foo} } This sort of thing is the bread and butter of programming languages, yet zsh has no good way of coping. Something hacked up with "reply" as an associative array is the best I can think of at the moment. What I'd *really* like to be able to do is this: sub() { local foo =what_I_want_to_set } fn() { local foo sub } In other words, there would be something to generate an opaque reference (a hard, rather than a symbolic) link to foo as found in fn(), and then another mechanism for using that reference somewhere else. fn and sub would need to collaborate to use this, but if you can test for parameters containing opaque references you can add backward compatible code. In fact, it could be as simple as using a hash code in a form that can't be a parameter name: % print #4351267a The opaque reference could be exactly that string, as long as we've got a way of turning it back internally a struct pm which isn't necessarily the current entry in the parameter table for whatever the parameter is named. This could be made safe, for example this could be a pointer with a parameter name; we would search through all parameters of that name, and extract one with the address given by that pointer: % foo=bar % ref= % print $ref #4351267a:foo % print $ bar ... [foo goes out of scope] ... % print $ zsh: reference to variable "foo" no longer in scope This isn't *completely* safe, in that you could get a chance match with a pointer to a later instance of foo; but that isn't catastrophic and it's you're own fault for allowing it to go out of scope. The check at least it ensures it won't crash the shell. However, that requires a complete list of all currently defined variables even if they're not currently in scope, and unfortunately in some cases we remove them temporarily from the parameter table. Ordinary local variables are relatively straightforward since they're on a linked list tied to the same entry in the parameter table. If we can resolve this problem there might be some mileage in the idea. -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php