From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from zero.zsh.org (zero.zsh.org [IPv6:2a02:898:31:0:48:4558:7a:7368]) by inbox.vuxu.org (Postfix) with ESMTP id 7A457211FF for ; Sun, 10 Mar 2024 21:08:59 +0100 (CET) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1710101339; b=JhHlqtLLBtHopi414GeRB8loA7G7eSYcaaS6kI4xSrUJDH+aolSz/cIrd93/WTgsF1fjD5l9Mw MQ9gP8BnAETBx64AQ9plgBsfYLGv7WEZVDI1IWp0GMfAQ8TRUPIB1/kFsToj5q7cdvmjLiRW7d aadxgeipLDSILgBgTscWPyxXxtg1Zq4pFWurlMGfiqxSqkomt+g6q4dhsgNx0OQiu1YBjNyfEf LQ4c8Fx1Ygdqf97aVPlZ93i2wggYYi4e/ePkFvnNOyFlKDRmM/DIDIl9//2vQ0/f0Q6IRKjXfd XYTcaOe4vCwhismQnVVjHbIKNQNWmg2apLH5zwtMcxLpuA==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-ej1-f50.google.com) smtp.remote-ip=209.85.218.50; dkim=pass header.d=brasslantern-com.20230601.gappssmtp.com header.s=20230601 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=1710101339; bh=f1MSBFOMbv0FecGr6BLOfYrZDcPZeaf+kDawi/LYYEc=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Transfer-Encoding:Content-Type:To:Subject:Message-ID: Date:From:In-Reply-To:References:MIME-Version:DKIM-Signature:DKIM-Signature; b=TGB9zqiR8eOfb4sWhW/vKjI2AvTQHh0qvaMPxHEqCgp5pBevnFhoM4sVLyQUVQJatAE94CnCax zH5snHOs4CmV2weqHE5DvRoTee7ojKWRQkBU/H/P99YkRi77debl+x3nVAJJogPkLRiWHZaTHK LQNMPst6XMacTeHm3GlcA9/zXe3TaAxKcc13WkmifPHLDmPjuGrFMax+0xYofJPqtxkB1ZJw30 6Mh6NYxjCd3NAZuIUFwMiCQ00Bm5+zvVgsaf/J5Nz3fNhk18OnpDPVBJIj6J4r25qKGsW7stJw 83zRNExgVnVgRR7oLclRrs4vkyw+SAlUy25IV+iWeO3swg==; 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-Transfer-Encoding: Content-Type:To:Subject:Message-ID:Date:From:In-Reply-To:References: MIME-Version:Reply-To:Cc:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=nbQeX9eb9kTA1Vhrsrat7AvdIYmDpU4fPi34n0pnOY4=; b=j1lR1tDHopOs4hQV80Q0mqn002 8Uu35CsuYXToY/ex6ELPFW6eqJFWWs0zjR/0sF13OVJjqcGs12fDy8Temsts4wNhGfoved1HJ034E iChLXnZcQDYbELgb2/+RjP/ZVxckKayn9c8GwBn7HhV+mKdf1oKTYOGmTbYb0Cc9vftkVqVXOV77l erKTrYv8TgsesghhhWbR33xAaQOz4cgr+XQNPF+FVE48mjIgvx9S6QFNXW3LNQqvFwYsHrRLfMETM UkAnwohQdPSetpqlHNsL0VKn2N+k8cOHzkCmPNiJEYphJaveQw66loYyKgeSxSztRe6RKPn34A/71 Z5MrpKwg==; Received: by zero.zsh.org with local id 1rjPTf-000HS9-18; Sun, 10 Mar 2024 20:08:59 +0000 Authentication-Results: zsh.org; iprev=pass (mail-ej1-f50.google.com) smtp.remote-ip=209.85.218.50; dkim=pass header.d=brasslantern-com.20230601.gappssmtp.com header.s=20230601 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none Received: from mail-ej1-f50.google.com ([209.85.218.50]:43081) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1rjPT7-000GkO-La; Sun, 10 Mar 2024 20:08:26 +0000 Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-a3ddc13bbb3so854919166b.0 for ; Sun, 10 Mar 2024 13:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20230601.gappssmtp.com; s=20230601; t=1710101305; x=1710706105; darn=zsh.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=nbQeX9eb9kTA1Vhrsrat7AvdIYmDpU4fPi34n0pnOY4=; b=jjZ/wy5+QM0tbnx9uvXrvwFoZnJJxGbqSAZHRf8tq4iM2smv8EiPY/lcJ/9KwuaQQf SaZlsCjNhGk+T5MnAk4BP8wg/rh/inH+vYXSs3SrIvR+D5aiVYJA3r5WjUcoXfothWtk cUDPFzjqH4VtLhmjlB5zVTaFLbMRuFNNKV03wAhjvO3zIs7xGA5KhouMKLUfLo+fypOw z1APeKroYvO4gs4Yw7qW/TknUMgW5+FAlsfEujTO+Ev+KZfoLkYqUYhWO+NBpsuKFZvL BPHgNlwNbjvBlM026Mrd+9Vpk5OpDUg1haYgpT44j+lt3N3pf7G1661zb/y8ZsUrckf4 ou+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710101305; x=1710706105; h=content-transfer-encoding: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=nbQeX9eb9kTA1Vhrsrat7AvdIYmDpU4fPi34n0pnOY4=; b=UdAAjU3sZgpOGPjV1ziEbcC9yDOrBvqMgXAkohz2J5ZFef42vmlnpSK2kqnSGJ/ZcC GGzHr6G4/ICcnZoQACvbi9AjQO1q3C41bVWToAUxwTjN1w6pvUXu2vvuAGvdMyXvWFgX E0M6BARkqamnuFCt7UiklwTL2BNaXKM35ItF50jFfl6B23d/R9CPnAWU4XOo4AcoMYYW yj0sbKHCPpFDtBXFSclaqfdkXhkZpzKQ04xejvcSKoKXAuOwT8XuaEs1tsNOtii0mXJz 8svjhPP+FdIZzomPjX08cV/uKY+Ow4v1bqcFjzG5G43SqGfgSRn+3OUIeEI4Mq4hNVEG WDCg== X-Gm-Message-State: AOJu0YwjqGyays7sP4jHTXVztHAP0cBV/vaxlDIs1TZuWMttEEtKLfQh XQP0wUlcjRFXWXk3EcRekRfg5+Hdm0I/pg1Nv4KeUf2LFoTg+sxeoxszPiONABePZpSRx3eV8/6 Us1TYaw5kaMULDMrPBMwFrZ8a/Yv7vu9Gv1vQZEyfhlPw8v7VFQ== X-Google-Smtp-Source: AGHT+IFccPXe1bb2PhaYeOA3l/b8OYzMvN2dg+pJNkJgv6AeiX3Kl1ghJiLpOeZ7eVF6EkKQQM0qfSgkiBt9a4FJ9mo= X-Received: by 2002:a17:907:868a:b0:a45:b616:29fc with SMTP id qa10-20020a170907868a00b00a45b61629fcmr5045857ejc.0.1710101304553; Sun, 10 Mar 2024 13:08:24 -0700 (PDT) MIME-Version: 1.0 References: <20240309143036.xwqm234mtu5wqh2r@chazelas.org> <20240310121359.iuhmf5renmuf6y4z@chazelas.org> In-Reply-To: <20240310121359.iuhmf5renmuf6y4z@chazelas.org> From: Bart Schaefer Date: Sun, 10 Mar 2024 13:08:13 -0700 Message-ID: Subject: Re: Why would I use .namespace.myvar? To: Zsh Users List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Seq: 29725 Archived-At: X-Loop: zsh-users@zsh.org Errors-To: zsh-users-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-users-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: On Sun, Mar 10, 2024 at 5:14=E2=80=AFAM Stephane Chazelas wrote: > > 2024-03-09 14:58:10 -0800, Bart Schaefer: > [...] > > > except with things like: > > > > > > typeset -p ${(kM)parameters:#.*} > > > > Also "typeset -pm pattern" > > Thanks, that makes it significantly easier to list variables in > a namespace. I note in passing that "typeset -pm" does unexpected things if the GLOBALEXPORT option is NOT set ... I'll start another -workers thread when I have a better idea what's going on. > Would it be correct to say that the main goal for introducing > namespaces then would be to tidy-up the output of typeset -p/set > for all the subsystems of zsh written in zsh (completion, > zle...) and third party plugins? No, actually, my main goal for introducing namespaces was to be able to write the zsh/ksh93 module, and because lack of parameter names containing a dot has popped up several times (at widely scattered intervals) over the past multiple years. "Invisible" parameters was an unexpected benefit, I didn't even know ksh did that until I was mostly done with the rest. It would be nice to make function names starting with a dot "invisible" as well, but that needs wider discussion. > Wouldn't having the .space.var variables and namespace {...} in > two separate releases be counter-productive [for] plugin authors I'm a little more concerned with internal uses like zsh/hlgroup than with shell-code plugins. After all if you've once changed shell code to use .myplugin.myglobal there's no requirement to rewrite it with "namespace". And you can do something along the lines of: typeset -g .myplugin.myglobal .myplugin.otherglobal typeset -nu mygobal=3D.myplugin.myglobal otherglobal=3D.myplugin.othergl= obal myglobal=3Dwhatever otherglobal=3Dsomething and then replace those two typesets with "namespace myglobal { ... }" later= . Implementing the "namespace" keyword means a bunch of fairly deep changes, including adding more wordcode elements as the output of new parsing routine besides figuring out the logic for inserting the current namespace (at both definition and expansion) and trying again without it (at expansion). I'm not (yet at least) familiar enough with the wordcode implementation to attempt the first part, and I'd rather have any kinks worked out of the underlying syntactic implementation before trying the rest. > Like if we allow ${.space} and ${.space.1} now but we find that > it prevents adding namespace {...} in the future, it will be > harder then to say "oh you can't do that anymore". There shouldn't be any clash with ${.space} because anything declared with the "namespace" keyword will get dots both before and after. If you attempt either of namespace newspace { .space=3Dvalue } or namespace newspace { .otherspace.place=3Dvalue } -- I believe (given the ban on nested namespaces) that both of those would simply skip prefixing with ".newspace." during assignment/reference. The potential clash with ${.space.1} is in practice I think also a non-issue, because ksh doesn't allow a direct assignment "1=3Done" anyway, so there's no incompatibility in declaring positional parameters exempt from auto-prefixing the same way that ${.space} is exempt. If you want ${.space.1} you have to always write that out. There are a bunch of questions to be resolved about how namespaces actually work. Ksh doc says "Commands and functions ... that modify variables or create new ones, create a new variable" -- does "modify" there mean that if I do -- namespace foo { PATH=3D"/usr/local/bin:${PATH}"; } -- that I now have a (useless, as it doesn't affect path search?) new global variable ${.foo.PATH}? Alternately, does that mean that we now have to alter the environment PATH by copy of ${.foo.PATH} and restore again, on every entry/exit of any subsequent "namespace foo" block? What about locals? Do they get auto-prefixed with the namespace too? What about: inner() { local foo; bar=3D$1; ... } namespace outer { inner whatever; ... } Is "inner" now implicitly using ${outer.foo} during that call? Did it create global ${.outer.bar} rather than (as the writer of "inner" may have expected) creating an actual global ${bar}? How could the writer of "inner" protect the function from this effect? E.g., would/should using "typeset -g bar=3D$1" be different? Given all this uncertainty and that we're already more than 2 years past the 5.9 release, I'd rather get the tractable parts out there sooner.