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,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12215 invoked from network); 5 Mar 2023 09:57:59 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 5 Mar 2023 09:57:59 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1678010279; b=GrUArFIlGt4jsAqK8PyqhiiPdKHmfLhHqFnH+/cLqWGjtJDB1DgsVJE/GOLshtgg+gnkllXoAo +01wghLhxj2uJFZbNBBgM+dzI6N6VIjsHv4x0odNPoDkT7wkOunHwfKRbaqiabHehdOwFgA9hP Q5DtlkmM8vVYscinSXOB/pz6d6+m88S7Th7brlivpQChDVFqx8NxO5KJWHS+VhOZKlH+w5On/e MAOA4sUnTnm8oPExjVC6Q4D8GgXyzWCkrnqEFu7CKHgNlSbKxONw95QVUrf8aB3IPXkrs9TCb+ /fks9G8g8pCXEeQEJP90+eKlSMsgj3D1IiUdA0smwK98zQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-lf1-f54.google.com) smtp.remote-ip=209.85.167.54; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1678010279; bh=tGTz1YTHvAnBWqcLvvnYiyTw+ZqOUFVMhlVp1mtCFak=; 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=HAX7DgKgwSbQ9zWYExuVa5K221aPqCiwCFoY1aqTMQOGf/wFdQ1Vsy0Y1w7n5iundm8SH2Smkp uCcsN+pZ19XzZozaPncDqKWT84GvT1DiD9nZjAUoXZBpSz3JYQHtmW2vBLBbb8lOymSqVropRd 7I454PvfcIX2XkNuoWBkIOuDVSX85lnkW8wdfVKqplbIlMi6OCgtT5SEg05aKq58gSuRFzchIx isrN0Ig3+7C/AXbhSfoCYgAZP9iBpisLn3W0Z1AB2VYACWaG8wlvmcKppiEJAkROPcLO/5YN9m lhg0Z1L0gUiiAYRA/Ie2PBTj4G8y/kazbmbNtd0zY2Qy+g==; 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=ZWN0eFV8/iJcgE/oTETjFngsgMUC4UnRSHeAdSNwJ34=; b=U+PgZLiVrX36rFtxklgf1Ea2o0 97sbhf1qvE+da4Kq1J8peEWf2bcP6avOYUT3C5IRC+Bv4vIM+H7KptAxvD8kS6OFQ3kxv3cwr/tRZ s6YkCD88cBTlskswQMy6a+ApD/CdfNy2yoxy/VLie+SBpuBvvtPXzpwjbb9/8gIpOLplsoV0uCn89 EZ5dQw0PfKfb4PhkMU0BLhg+5fWMaMYXIq3uliZLKPbK9LI2vKXEB2Ys2DmTBgkeQlp8sqmM+nB16 PLgP0hTFy4JyqE8n9DNCBNPQDaRH9hlpQxQxFGjeTRav7jKyDIsip3Rewv+5lp2Q3NC8fGSAy7kMW 7K2GLGDw==; Received: by zero.zsh.org with local id 1pYl7u-000FMh-Tk; Sun, 05 Mar 2023 09:57:59 +0000 Authentication-Results: zsh.org; iprev=pass (mail-lf1-f54.google.com) smtp.remote-ip=209.85.167.54; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-lf1-f54.google.com ([209.85.167.54]:44618) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1pYl7Z-000F4B-Hm; Sun, 05 Mar 2023 09:57:38 +0000 Received: by mail-lf1-f54.google.com with SMTP id s20so8952832lfb.11; Sun, 05 Mar 2023 01:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678010256; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZWN0eFV8/iJcgE/oTETjFngsgMUC4UnRSHeAdSNwJ34=; b=eCC3aUTtUfyTIlHcFoWguUyW1HJSL0LmJlecpndjUijxdMMFW/6Sqj8K0Dx8COHYh+ pXc1Ceee06jpR/DbmrJ+cYND0rNTqmdqDqLKjelEC+tJHD8SExJmRigSlv4XCvesXb2J zpLiClYDEnDTtuwGzEAhuS51z7ixv/7lr8PTk7OzfSEzWkoTE9gG0yKjv7dbHAU2y7II o/v8at+gl7kl4d9F/+A1WEvhETQEPYoGXvJn3LacWzDbFquhd1XBc8S8A8e1Lo6I3nGT HwVuiYVU3y0b9kmr3f7QFM81VxujuMJXC3iY8fGxkVSEcWXbKTd62wCfqrM49wdYgFRX +cQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678010256; 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=ZWN0eFV8/iJcgE/oTETjFngsgMUC4UnRSHeAdSNwJ34=; b=0dtH84e8BEMmjHYdY9LwEVChmrCW00rP2jHsTPr3zRvzg1M5sIRdBVry7PmfgNrzQB GuC68MUDlqhFxYnqAQq58yqU8AFPH6txg2phwR0acaL8tNg1PuVpU7pPgLBLpA+x+8/8 +tEcut3GVUe5Rrp3ZY94Al/Ni592jkuRTwBUZop4y0PWUqugsWmyoPAIGbEvswjGahdl gGxE6whX3v7peFfFxcbqSpHWKo8nsv0njDo5itMRf05+JqhwtC8idfGKfS3Xv4TqruCP peDqLOdYifn6vPGo0MjZM7UxvdzAXhxlESMOARUlIl/DjsRpF4cydmARXfOQvKPdo53+ XOlA== X-Gm-Message-State: AO0yUKW2XEU/u6/VfBbTCX9J73lfN4WAnrhED7BewAzL8XtrAwPKW+gh LhcjP+4ct2C+GKVlXaOPtDCW3vgRMQ/oG2OuRsD15ocF X-Google-Smtp-Source: AK7set8tUVqinJIWaFueqrhSUswwBijEytnoeGmNnLSXms77ccusL90rypgp4vxtG8QdK/nFS5sJSANP9kSD4eZCH70= X-Received: by 2002:ac2:54ae:0:b0:4e7:fa9a:4d45 with SMTP id w14-20020ac254ae000000b004e7fa9a4d45mr1256710lfk.2.1678010256459; Sun, 05 Mar 2023 01:57:36 -0800 (PST) MIME-Version: 1.0 References: <26170-1678007435.186071@mDq6.Euc0.bAwZ> In-Reply-To: <26170-1678007435.186071@mDq6.Euc0.bAwZ> From: Sebastian Gniazdowski Date: Sun, 5 Mar 2023 09:57:10 +0000 Message-ID: Subject: Re: [PATCH 1/3] Extended ksh compatibility: namespace parameter syntax To: Oliver Kiddle Cc: Bart Schaefer , Zsh hackers list Content-Type: multipart/alternative; boundary="00000000000044095d05f6243570" X-Seq: 51503 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: --00000000000044095d05f6243570 Content-Type: text/plain; charset="UTF-8" I wonder, how far is this from supporting a nested arrays? Like arr[2][3] or assoc[a][c]? On Sun, 5 Mar 2023 at 09:11, 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}. > > As yet, there's no special significance to use of this syntax, that > > is, parameters having such a prefix are ordinary parameters like any > > others, with the usual dynamic scoping rules, etc. Each of namespace > > and param must be an identifier in the original zsh semantics of > > identifiers. > > 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. > > 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}. 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. I'm not sure how ksh implements the initial dot. It effectively > blocks consecutive dots because you have to declare the parent first. > > Ksh uses dots both for namespaces and compound variables. Of the two, > compound variables are definitely the most useful. The namespace { ... } > syntax of ksh was not designed with the interactive nature of the shell > being considered foremost. I like the aspect of hiding shell specific > variables away below .sh - could also be good for .zle. > > I think it is a mistake to not make compound variables, namespaces and > associative arrays merely different facets of the exact same underlying > thing. 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. > > Oliver > > -- Best regards, Sebastian Gniazdowski --00000000000044095d05f6243570 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I wonder, how far is this from supporting a nested arrays? L= ike arr[2][3] or assoc[a][c]?

On Sun, 5 Mar 2023 at 09:11, Oliver Kidd= le <opk@zsh.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On 26 Feb, Bart Schaefer w= rote:
> The attached patch enables assignment of and reference to parameters > prefixed with ksh-style namespace syntax, e.g., ${.namespace.param}. > As yet, there's no special significance to use of this syntax, tha= t
> is, parameters having such a prefix are ordinary parameters like any > others, with the usual dynamic scoping rules, etc.=C2=A0 Each of names= pace
> and param must be an identifier in the original zsh semantics of
> identifiers.

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.

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}. 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. I'm not sure how ksh implements the initial dot. It effectively<= br> blocks consecutive dots because you have to declare the parent first.

Ksh uses dots both for namespaces and compound variables. Of the two,
compound variables are definitely the most useful. The namespace { ... } syntax of ksh was not designed with the interactive nature of the shell
being considered foremost. I like the aspect of hiding shell specific
variables away below .sh - could also be good for .zle.

I think it is a mistake to not make compound variables, namespaces and
associative arrays merely different facets of the exact same underlying
thing. 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.

Oliver



--
Best regards,
Sebastian Gniazdowski

--00000000000044095d05f6243570--