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 25762 invoked from network); 5 Mar 2023 20:17:13 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 5 Mar 2023 20:17:13 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1678047433; b=SxqaLEmG8EuY2CX7cuVdtewNv15YTqSmE0gWEgLKlaAcCShRtXr7+jYMPWO3dV5f76pAc71/F1 Pigfd1FTmDGNLciMsf8W78rFTAjdEeNY6Nvn9iuvt9W6GCcgdAFxU8RAbzYSaXVsQH5g5Kg2YS Rshp9Tw2WLpwqYT9D/b1iGaz9jt41A7DLPb3GRlEaHumpPA2B6waLBrZJ5CVLwknC4jwH3/cB6 ezs9bzM6PIfwQq7Cmgs46RZNYSFuM8TIVHIFECXxjknnauM9TJphQdjaYXLYb42VnGRKzj3R3j MotkHc3M0sBaxGzHu6ZEd6bZk6cLzb0oLoV6CqNIxB9Cfw==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-ed1-f50.google.com) smtp.remote-ip=209.85.208.50; 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=1678047433; bh=sGnULHfvsoWXYtZJJqvjf8thmM0whn7BPa6lzipv9xI=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Transfer-Encoding:Content-Type:Cc:To:Subject: Message-ID:Date:From:In-Reply-To:References:MIME-Version:DKIM-Signature: DKIM-Signature; b=GDmmMYITDLYzLDUpcfzDFsjNtg4nrTzuub8BEId9HNQxu5xNFEq0NAzPImHfP1TMrlJZmMqAMU YSBeGgmA2kVsK16brRKx7pVphRW2fq9FVfQDr3w3YuY6y3palg9+XSuRyToTA6s9qWjAaRJjeO mhzPBAUupeosiBTN1M/bwNWFM1x/+HLCf1/QNDv8ex9/JNPfA/vkDKY44X1L33+pSxa8A+ceMV 7uIlwnMgAtlfF9ZtdGwEzO5MbkY9qmrIV6ekYLQmJYPwOngXAghFnbqCOR/8X2fUsZz00h8zH1 QQbkANzlrvlYuPQkpAbuF2W+RST0wcDi0q/9Jtt5RmZJeQ==; 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:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References: MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=UT2eOk4r27g7MJfm1ijw3K69P6Sg6h+Ov99CRT8xJtE=; b=axkXeD4iXIeBb0yloWj4x28KJY pH9J5T90wAs2QmmLFJ39U6Nzc0AOQaNrRd/WZxfU9CUHvCpV7ykPRirLnSo57W5pQ/f/sR6K8w7RP FdniRu+Ewl8Rg+621EQTa76siFdzmH6vpoe5J0TXCmhAw/MuNdKlbiY6ynFnBcN8ktX5XNKOFZy7b qExITxRPqTwAow8ygkYMNLP4XV9oUVv3hYnP62PkkizsrnkuG1Uo91lMlUvlwjhAaU7sLlmuKM8lt Tvz4KxWKL/7gmJab/wpNh4ZWHnRXZiPoYbvaaf6KMtHAlqEKQPWNmd9uF3Mfpm5mSZWjrbTV+lA7h oFqR7LIw==; Received: by zero.zsh.org with local id 1pYun9-00041I-W4; Sun, 05 Mar 2023 20:17:12 +0000 Authentication-Results: zsh.org; iprev=pass (mail-ed1-f50.google.com) smtp.remote-ip=209.85.208.50; 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-ed1-f50.google.com ([209.85.208.50]:34637) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1pYumn-0003hN-U6; Sun, 05 Mar 2023 20:16:50 +0000 Received: by mail-ed1-f50.google.com with SMTP id g3so30649696eda.1 for ; Sun, 05 Mar 2023 12:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UT2eOk4r27g7MJfm1ijw3K69P6Sg6h+Ov99CRT8xJtE=; b=cf4oXHeWTcVBV72M8hjWtEz4eQBSeP/9GA0ug9gJQuvnUhie3YVb25f1zbIvbtHZ5j gP1vKPZMdfK/mJCmbWFXZd5bwdGDyvG6ptycDs0rbUf1SQHRi8V2skcmH9Nhe0PKMSEh xleGc4oUXmlwuD/uNu3dhzVg/2yXkewFW84imSUK/v7CeG2rCX7iHTkeHwPlp84GCNTv dmob73vKpfkLFXwD78+yaVqwm3m8Q79AkLK8fH6UlixvFDCzFJu46aT7e7pk8wz8Kg8t 9tuxMSpFbe/rU85/lR967WFeNgoVhXcKiKAtQeAbceXWqUOAZ1+Evbv9Oq5h1YQGypgK v1Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=UT2eOk4r27g7MJfm1ijw3K69P6Sg6h+Ov99CRT8xJtE=; b=Pj06jB2L6MlwCvBgVfB9tJNQ6llppPeMVOpZubl3wUj2qH/uioKE22ostEhz2IhnYf zRg4HnxgeQ7+KRHMpOvW1oXLJ45WKPU2iXA+aFarfq/6iykOrxLOPcs60uA2ihghHfhw vKlXUhxWYBwzAcc/qxOX8wh73ugPlPaFWdDzZpkV1P2omulMyXYAr+bvzNcmsY44uBzP 7iMNH7eAiq+D7Ztei/6d2YF3hlOQa7lRbORXSGrU0xObI/E+2MDjs57Uqp4OhTBXyHn/ 4zvLztdywILOEKRzQIaLZKwGCaPITPPVZbIQqDug2cANG/qJBySGnwRiFNlyqgplodrA 9YqQ== X-Gm-Message-State: AO0yUKVqEEjgRqQidYbVvMJx22JabRC5t9TkZS49Bq5HFo+Bp7/a3jaU oHLB6EH2TmvhzvTL5w8Hlc7MS/UolAJESlb9uJhzeOKkJSOVLWvgVXc= X-Google-Smtp-Source: AK7set/H/olXNE7/j8QX8p6qEdX/aJ6Y8P7DJY/Bk3CfAIMnPEkkMW+FNLZ61r+/cgWsUVxLdW1Oi4GMIZACLtjV+gs= X-Received: by 2002:a17:906:3087:b0:878:4a24:1a5c with SMTP id 7-20020a170906308700b008784a241a5cmr3576170ejv.6.1678047407883; Sun, 05 Mar 2023 12:16:47 -0800 (PST) MIME-Version: 1.0 References: <26170-1678007435.186071@mDq6.Euc0.bAwZ> In-Reply-To: <26170-1678007435.186071@mDq6.Euc0.bAwZ> From: Bart Schaefer Date: Sun, 5 Mar 2023 12:16:36 -0800 Message-ID: Subject: Re: [PATCH 1/3] Extended ksh compatibility: namespace parameter syntax To: Oliver Kiddle Cc: Zsh hackers list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Seq: 51504 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 Sun, Mar 5, 2023 at 1:10=E2=80=AFAM Oliver Kiddle wrote: > > On 26 Feb, Bart Schaefer wrote: > > The attached patch enables assignment of and reference to parameters > > prefixed with ksh-style namespace syntax, e.g., ${.namespace.param}. > > I've been running this patch since you posted it and haven't found it to > cause any problems as such. It also holds up to testing but with no way > to assign to variables with a dot in their name, there's a limit to > what's possible to test. Assignment should be possible. % .foo.bar=3Dsomething % print ${.foo.bar} something % print ${.foo.bar::=3Dotherthing} otherthing % typeset -m .foo.\* .foo.bar=3Dotherthing > My main concern is that in the absence of special significance to the > syntax up-front it could be harder to add later. At least the > documentation should warn so users should not be surprised if e.g, in the > future, `local foo` will hide a ${foo.bar}. Yes, I've been working on doc and tests. One difference that I want to add is that parameters starting with "." are omitted from the default output of "set" and "typeset" (with no arguments). > But every new module like ksh93 > could need reworking if the implementation changes so that this is a bar > entry in a foo hash table instead of a foo.bar entry in a global hash > table. Exactly how far we (or I) want to go with this is still an open question. Namespaces do not nest, so anything with a leading "." (and exactly one further ".") is in the global hash table. > Ksh uses dots both for namespaces and compound variables. Of the two, > compound variables are definitely the most useful. In ksh (based on doc and some testing, I'm not a ksh expert) ${foo.bar} might be a reference to ${foo[bar]} or it might be a call to the function named foo.bar to invoke the "bar" property of "foo" (or it might even be that ksh implements the former as the latter). In the foregoing patch I have allowed the syntax without the leading "." to be parsed, but so far not ${foo.bar.baz} etc., so the doc I've written so far does warn that that leaving off the first "." might do something different later. Patch following soon. > I like the aspect of hiding shell specific > variables away below .sh - could also be good for .zle. Given zsh dynamic scoping, it works reasonably well to have ZLE variables behave like locals -- you can't access them outside a shell function (widget) anyway. If there were controls we wanted to expose higher up -- such as, perhaps, fiddling with keymaps without having to invoke "zle -K" or "bindkey -[eva]") then yes, a ".zle" namespace could be handy. > I think it is a mistake to not make compound variables, namespaces and > associative arrays merely different facets of the exact same underlying > thing. Agreed with respect to associative arrays and compound variables (whatever that ends up meaning to us, I find the ksh implementation rather grotty especially from a syntax standpoint, and there are some significant conflicts with existing zsh idioms). Namespaces actually are a slightly different thing because the variety of "objects" in a namespace isn't limited to parameters. If we were already using a global hash table to contain as its elements the parameters, commands, aliases, functions, etc. hash tables, that might be a different matter, but we're pretty far from that now. > I'd like to be able to dump variables out as json/xml/yaml and > reimport them back without the loss of detail of which type they started > out as. For that, there are other obstacles (not related to namespaces or compound variables) remaining to be overcome, but it's worth keeping in mind.