From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1645 invoked from network); 25 May 2006 23:58:06 -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.5 required=5.0 tests=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 23:58:06 -0000 Received: (qmail 69286 invoked from network); 25 May 2006 23:58:00 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 25 May 2006 23:58:00 -0000 Received: (qmail 3975 invoked by alias); 25 May 2006 23:57:57 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 22460 Received: (qmail 3830 invoked from network); 25 May 2006 23:56:14 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 25 May 2006 23:56:14 -0000 Received: (qmail 68208 invoked from network); 25 May 2006 23:56:14 -0000 Received: from ug-out-1314.google.com (66.249.92.169) by a.mx.sunsite.dk with SMTP; 25 May 2006 23:56:13 -0000 Received: by ug-out-1314.google.com with SMTP id o2so2482374uge for ; Thu, 25 May 2006 16:56:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=L9fpvE8Oc7Uw8iLxUClPbkArmj9Ub1EXvJNf0cLK9Vmg2vbM0EbbCqTI00FNhXrL+bTiEvZu8g0HDuRYqH2pVzUmHfl/WsVkU3ooOqVL0rUhHTgL3P7UZAk2zYp+XKipQlqhCBjeqRMiidkLVqao1Yoomxplr2AmKjJ2TIfHCSg= Received: by 10.67.128.4 with SMTP id f4mr1072339ugn; Thu, 25 May 2006 16:56:13 -0700 (PDT) Received: by 10.67.88.14 with HTTP; Thu, 25 May 2006 16:56:13 -0700 (PDT) Message-ID: Date: Thu, 25 May 2006 16:56:13 -0700 From: "Bart Schaefer" Sender: schaefer.brasslantern@gmail.com To: "Zsh hackers list" Subject: Re: values of associations pointed by P flag In-Reply-To: <200605251515.k4PFFt92017392@news01.csr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060522205404.GA24028@ulpmm.u-strasbg.fr> <060523081402.ZM15072@torch.brasslantern.com> <200605251515.k4PFFt92017392@news01.csr.com> X-Google-Sender-Auth: 892863e40e9a9568 On 5/25/06, Peter Stephenson wrote: > > What I'd *really* like to be able to do is this: > > sub() { > local foo > > =3Dwhat_I_want_to_set > } > > fn() { > local foo > > sub > } Of course in ksh "generate_opaque_reference_to_my(foo)" is nameref opaque=3Dfoo which (if I understand it correctly, which I might not) acts roughly like "local -h opaque" does in zsh in terms of scoping, but makes the value of $opaque equivalent to the value of $foo and similarly causes any assignments to opaque to be assigned through to foo. > % 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 That's an interesting suggestion for a way to impement namerefs. Rather than really passing the reference around, which would require a massive rewrite of the parameter code, return as the value a magic string that gets processed "as if" with ${(P)...} at the critical juncture. The important bit is that such a string has to be impossible to create by any other means, and has to encode how to select both the paramscope and the parameter that are of interest. > % foo=3Dbar > % ref=3D > % print $ref > #4351267a:foo See, this should never happen. The parameter code should internally recognize the magic value of $ref and replace it with (in this case) "bar". The trick may be in knowing at when to do the conversion. Subscripts need to be applied to the referent, not to its value. (We have a bit of a complication in that plain arrays are subscriptable as compound values even after the referent is lost, but hashes are not.) > ... [foo goes out of scope] ... > % print $ > zsh: reference to variable "foo" no longer in scope This would never happen with the scheme I describe, because the named reference can never refer to a parameter at a "deeper" scope; that is, foo and its opaque reference could go out of scope at the same time, or the reference could go out of scope first, but foo could not go first. > 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. If the reference can't "look down", then it only requires the current state of the parameter table when creating one, right? You can get to wider scopes via existing references or through the current naming scope, but you don't need to enumerate *all* variables.