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.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22226 invoked from network); 8 Feb 2023 04:59:56 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 8 Feb 2023 04:59:56 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1675832397; b=rZjI83kzTM+gHzYzmZn9BDvrrzULISOSCJ7Jkjv9jjdLcZys++iDno6DfcRFGB7VgzJYmP18ZJ KXIYCPeCGFV+5aSPGXTjoNda1+EPJZQmg16BeuqlX84IdDZtnMW0Ae+bMi2xYO/zMagNm4W4Wi n490bkM5dQ7EEGla0g8cr7ynP2iiySG9SNcI92vXJGTkSnXINYVKLSk6o403TxoApcRxq3Y8Ut /PjkMtmdFFNhPOKV1qNu1ODCl0CP2nxRQh4q+g8tWhyA/RbdV2XCQrEON+xf2IH8LoVSES4Yfd Esess3j25RqRDSnX76eALvzNwnRcXkbN9yd+IBAxbj1TYQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-ej1-f42.google.com) smtp.remote-ip=209.85.218.42; dkim=pass header.d=brasslantern-com.20210112.gappssmtp.com header.s=20210112 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1675832397; bh=U5QGGHut8ANFtuO91Pkw+LdeZ6t0YrZuqT5eRngyr7A=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=CBZeDSzBiD+80BTedTfH4U2Tv3n5nH4/2nxTwF8cpSwTxde/hv+cY2afq4Mll5XPMFJWHFte97 C12dyEr7sjC6PuqPG8fEwkJQhPl1Nal64wsjXLNiZoYNXN0G7PmIm76+sOYtkHs6Glbru3YwTp mBcOED9k6phRZv+NVZeFqpNNFLCYbUy2qlxQZOLswo/vT+0fPNOVcHJxCDpMSGP+C6XE7V77mj dyGuOsQRazQyoHpXXp70laBFyQf9jGCKIYbrfnLSveutYbaEuAr6+ICSLBpyKncoSvgTA6sjr2 YKKXnK3P/WVy9bdNnohPwSwGP+d5VzYmFDEzAndAcswdzw==; 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:Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=hZ7lfvamRAEaB3CbkhA4SgNRIZkUZTuh5R/lJEAvC1g=; b=ei3ZeDYwVps07uGqrSWsZ1+sUa iIPCplCPgmtMawYfaG6/7LEs6m3o1nEUBo4UFbVEFmcWlTCtUhZe4dp9KpCqJQ6GIyY2Bf32p5/ZF tPbbm2w2Zk8yXmYvdPMODJExI4c6ml0ALSYmMKcg7G6E30y/RuFOMSWIC1jSsM1IAzw3e0sBVBzUJ E8qY/EUT8GzHzBPSvu6lZsxVFRjeBDjWWRwrGEx7nmpF5cMCTW+PUdLQ0+yUrzQVMilaXcC0Ff19F DU4cGONz3lInQ2hKqR/Bz6vLk56d0jxKu1ciK/M5X0Zm8ayiV3rmW/bb0FbHX0DSJPFtIHdIfJQ7o C0p1jHZg==; Received: by zero.zsh.org with local id 1pPcYl-000OMA-Su; Wed, 08 Feb 2023 04:59:56 +0000 Authentication-Results: zsh.org; iprev=pass (mail-ej1-f42.google.com) smtp.remote-ip=209.85.218.42; dkim=pass header.d=brasslantern-com.20210112.gappssmtp.com header.s=20210112 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none Received: from mail-ej1-f42.google.com ([209.85.218.42]:45654) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1pPcYU-000O4X-Ps; Wed, 08 Feb 2023 04:59:40 +0000 Received: by mail-ej1-f42.google.com with SMTP id dr8so48245930ejc.12 for ; Tue, 07 Feb 2023 20:59:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hZ7lfvamRAEaB3CbkhA4SgNRIZkUZTuh5R/lJEAvC1g=; b=CUQFMx8jlSXlz2oB3PgrgLz4A67gbnqlEACFAuKjuRYbyZdfXNkxg1LFXOiS+pleRF qOepowLVBlO8BgsuVCXnLUVP4lpcemfqYwGimApFFquYxKFEjBx6uue8+Bl66eiMSQc8 l3QkT40VHjm9X+/834PIzJ9RR1v3tEjTjNyTkBGBjPGajjYujwUoqCkgCX/FXKO2n0uw BqQYnDL9YLFetUkUTpdoDd+09sJXbvH0Rst1c3bOw0Xvt3sdMuyJwG7gkiCZRZRMC+Oh aT1TDazcY1V6oSwvbbLiVZVzR81KJC9JuLzWaMIBpAFGwg5PembiTckkeFGeO5VNUswo aypw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hZ7lfvamRAEaB3CbkhA4SgNRIZkUZTuh5R/lJEAvC1g=; b=xFCDRwOFkLlJ5lnC71iRS8PkeIGdizNJsSLS6Vx424xqwNq8fJMz5zMBcsIIUbqVi8 uDitlZPU8I8vlmhTSdrHvGK1PNncO2bKP2FJoPsWvIlkmz6O5rhyCcjKdcAg04drL/Mg oejT0gFHQkcv92v/v4fU4gLu+ADrQKmNK1++efl/x/FfDn56TKtfgUy2J3p0lvqCgwYQ TB9LwjrYT9cJzjG38BRxBYA9KiG/PkumB5bjzyYKgLLk0JCUekqxEhEWapFczLoaQTxz QxDaE7SEhV5OPFTvqjOv3FsRiRO3JnQeiNVDG5UtUzaIOjzbpoS6sXS4uJpdwf+a1wlZ c2Tg== X-Gm-Message-State: AO0yUKXdJ+0Ihbwhy7VsyWrru+jP7neNJxqBYcgZE9XbrTqa1zOSnvZF XMqMLmlv8LyOckQHIjg1reyjllV34sKrWSxaL4UTFg== X-Google-Smtp-Source: AK7set8SaAMaoDDpHlWPI85D/DevTLjjOh2dcb7vYhLpo/ep0WJ1BCJABD6Cvz7OPfExPeyxu22tnxwJyNlLN2741lk= X-Received: by 2002:a17:906:4dc7:b0:877:e1ef:e49a with SMTP id f7-20020a1709064dc700b00877e1efe49amr1471824ejw.147.1675832378090; Tue, 07 Feb 2023 20:59:38 -0800 (PST) MIME-Version: 1.0 References: <67689-1675827940.088548@BxvG.D9_b.7RzI> In-Reply-To: <67689-1675827940.088548@BxvG.D9_b.7RzI> From: Bart Schaefer Date: Tue, 7 Feb 2023 20:59:26 -0800 Message-ID: Subject: Re: [PATCH 1/3]: Add named references To: Oliver Kiddle Cc: Zsh hackers list Content-Type: text/plain; charset="UTF-8" X-Seq: 51377 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: On Tue, Feb 7, 2023 at 7:45 PM Oliver Kiddle wrote: > > 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. This should work after patch 4/3 that I just sent. % typeset -n ptr=foo % typeset -A assoc % typeset -n ref=assoc[other] % ref=val % typeset -p assoc typeset -A assoc=( [other]=val ) > 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. Hmm, yes, that message should be changed if possible. > 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 should also work after patch 4/3. % typeset outside=OUTSIDE % () { typeset -n ref=$1 print $ref } outside OUTSIDE Or do I misunderstand? > The positional parameters are special-cased which I > find rather ugly. There's nothing explaining this in "man ksh93", can you point me somewhere? Not that your description makes this sound particular attractive. I think the positionals might actually be best handled by a new special parameter. Cogitation needed. > You could overload -u or -U for indicating Tcl-like > uplevel. It'd be easier to overload "-i N" for this since it already populates the "base" integer in Param. > 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. if the current locallevel were visible (cf. new special) then something like typeset -i $((locallevel-1)) -n up=argv could work. I think the current implementation of argv breaks this, tho. I'm still not entirely following what problem this solves. > 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. You're going to have to write out an example, sorry. > I can't see an actual conflict in permitting -r, making the reference > readonly not the target variable. I'm also thinking about that. The only use-case would be to prevent something from doing "typeset +n ref". > > 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. What purpose does it serve? How does it help to have two names for the same thing, one of which is "hidden" and the other isn't? The only analogy I can think of would be having a writable name for a read-only variable. > 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. You presently can't make anything that's private visible down-scope. If you mean you want a variable that is visible in exactly one nested scope, I'm back to asking for the use case. > > 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. In Test/V10private.ztst it's the test with F:See K01typeset.ztst up-reference part 5 F:Here ptr1 finds private ptr2 by scope mismatch, assignment silently fails > > 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. Except every letter in TYPESET_OPTSTR has to correspond to the PM_ flag at that same index position, and the PM_ flags matching the k and z options are way out of sequence for that. > Note that recent bash also has namerefs so should perhaps be compared. The special behavior of namerefs in "for" loops and implementing "unset -n" might be good; the latter isn't mentioned until the "unset" builtin in the ksh93 doc so I missed it entirely. > 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. And yet we implemented ${(P)...} which is actually a bit grottier. I did consider overloading pm->old but was leery of messing up locals so decided to leave it as a future optimization. > I did make a start at the time using reference counting That was the other part that worried me ... everything just went (relatively) smoothly if most of the code could continue pretending namerefs were scalars. > I think I also concluded that it > wouldn't work for private variables because of their somewhat too clever > implementation. They could be a lot less clever if they could move into the main shell. Most of the cleverness was necessary for making them modular.