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,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13260 invoked from network); 8 Feb 2023 03:46:16 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 8 Feb 2023 03:46:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Message-ID:Date:Content-ID: Content-Type:MIME-Version:Subject:To:References:From:In-reply-to:cc:Reply-To: Content-Transfer-Encoding:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=rgKQ+/NFAuT2I3hCeurCK6K4wzDNWG+71VtxIXg8ORc=; b=htCH9rJiXv267IyLzksxx1jxdU a0LQ7Vf9ZAwPUL0NOcZiItAidaWBL2bk2R4gzCbrw+7NUdfz2t/fpBVdtqo5IJ2HRBj7fKwUUf7hm quU918K0UPNS0Nh1QkFGjmi0MyIKiquuMKfNWv3W1LGgHQvTKy+OdULp605sgfUtgDU8f1hPZqdpX 8LNgD3OOcP5KhsUwyf8oeYFEYJSOD6EhFIewySMw0yssD0+8dRq/v5K5mEkpmOUPjaMAaIk1xTT66 /9uA/s6otIsdwZuy0gtBGcC3sL6JXJsz8xAoG48yHvRqzM21MA+Q+XKpmJpRhRnQRqPU5VvjtVLQF SIJTa2gQ==; Received: by zero.zsh.org with local id 1pPbPR-000Lx7-Ik; Wed, 08 Feb 2023 03:46:13 +0000 Received: by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1pPbOu-000LdR-HU; Wed, 08 Feb 2023 03:45:40 +0000 Received: from [192.168.178.21] (helo=hydra) by mail.kiddle.eu with esmtp(Exim 4.95) (envelope-from ) id 1pPbOu-000Hbm-2y; Wed, 08 Feb 2023 04:45:40 +0100 cc: Zsh hackers list In-reply-to: From: Oliver Kiddle References: To: Bart Schaefer Subject: Re: [PATCH 1/3]: Add named references MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67688.1675827940.1@hydra> Date: Wed, 08 Feb 2023 04:45:40 +0100 Message-ID: <67689-1675827940.088548@BxvG.D9_b.7RzI> X-Seq: 51376 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: Bart Schaefer wrote: > When a reference is created, it's necessary to determine the scope in I've run some tests and this looks good. The main issue I noticed was with a reference to associative array elements. typeset -A assoc typeset -n ref=assoc[other] ref=val This does work if assoc is assigned an initial value. The error message from, e.g. `typeset -Z2 ref` is "can't change type of a named reference". However, this is normally an attempt to change the type of the target of a reference (-n is not specified). It works fine for a scalar. So perhaps the error message should complain about changing the type of [associative] array elements instead. One ksh feature which this doesn't cover is the special behaviour in ksh that `typeset -n ref=$1` will use the calling function scope to resolve the target. This is necessary with the lexical (private) scoping of ksh93 functions. The positional parameters are special-cased which I find rather ugly. You could overload -u or -U for indicating Tcl-like uplevel. The trouble with uplevel is that a called function can't know how many levels up to specify if people are allowed to write wrappers. I think a better solution is to take some syntax that isn't a valid variable name. e.g typeset -n ref=\&1 Repeated use of an initial & would indicate where another level of scope should be ascended. Wrapper functions then don't need their own nameref and can just pass, e.g. \&var as the variable parameter. > One difference from ksh93 is that you can't convert scalars into > namerefs, e.g., both with this and in ksh93: That seems reasonable enough. > Named references can't have any other attributes, and attempting to > add an attribute to a named reference generates a warning. However, I can't see an actual conflict in permitting -r, making the reference readonly not the target variable. > With respect to zsh/param/private parameters, it's presently > prohibited to have a "public" reference to a private parameter. It > might be possible to change this if someone can think of a use case. To a user it would seem like a fairly arbitrary restriction. Coming back to the uplevel question, for private to be more useful it'd be really great to be able to have a private reference to a private variable from the calling function scope. I'm not sure how easy that even is with the current implementation of private. > There is one glitch: if the reference is created before the parameter > is declared private, and the private local is NOT hiding something in > an outer scope, then the reference does not retroactively generate an > error and assignments to the reference are silent no-ops. Not sure I follow. Sounds like something that ought to be fixed. > I also removed "kz" from TYPESET_OPTSTR in zsh.h -- as far as I can > tell they should never have been there in the first place. typeset -fu is like autoload. I think it was intentional. Note that recent bash also has namerefs so should perhaps be compared. They only resolve in local scope and don't include the local level with the reference. Oliver PS. The basic approach is much the same as that which was rejected many years back with consensus at that time being that a C pointer reference should be used. I did make a start at the time using reference counting but real life stuff got in the way and it was never completed. Zsh's code does a lot of deleting and recreating parameter structures which is problematic with that approach. I do still have an old patch that last got rebased as recently as only 7 years ago if you're interested. Aside from not working with array subscripts, I think I also concluded that it wouldn't work for private variables because of their somewhat too clever implementation.