From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-38210-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 26109 invoked by alias); 23 Mar 2016 09:23:47 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 38210
Received: (qmail 26332 invoked from network); 23 Mar 2016 09:23:46 -0000
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.1
X-AuditID: cbfec7f5-f792a6d000001302-dd-56f2609cf12f
Date: Wed, 23 Mar 2016 09:23:38 +0000
From: Peter Stephenson <p.stephenson@samsung.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: zsh -n does not detect incorrect associative array declaration
Message-id: <20160323092338.492731f9@pwslap01u.europe.root.pri>
In-reply-to:
 <CAH+w=7bkphoEdbFzXbU4_UXNWjr8M1UMUuO0QAiOfh=QR--1Ww@mail.gmail.com>
References: <56F1C3D7.6020800@redhat.com>
 <CAH+w=7YDbbw_J2G6BJKqi9=MtymqAQo1Zhv-19FGK0RqFnyScA@mail.gmail.com>
 <56F1FF5F.6060907@redhat.com>
 <CAH+w=7bkphoEdbFzXbU4_UXNWjr8M1UMUuO0QAiOfh=QR--1Ww@mail.gmail.com>
Organization: Samsung Cambridge Solution Centre
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu)
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Brightmail-Tracker:
 H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsVy+t/xK7pzEj6FGfxZyGxxsPkhkwOjx6qD
	H5gCGKO4bFJSczLLUov07RK4Mna938FU8Jet4sGZV4wNjAdYuxg5OSQETCSmrNzJAmGLSVy4
	t56ti5GLQ0hgKaPEhu9fmSCcGUwSPzbsZ4RwzjFKTLn7HSpzllHi76InzCD9LAKqEm3te9lB
	bDYBQ4mpm2YzgtgiAloSO06eZAKxhQW8Jab8vQ1WwytgL/Hs6nGgOzg4OAWCJTZOL4eYeZ1R
	YucqiJn8AvoSV/9+YoK4z15i5pUzjBC9ghI/Jt8Du5sZaP7mbU2sELa8xOY1b8F6hQTUJW7c
	3c0+gVF4FpKWWUhaZiFpWcDIvIpRNLU0uaA4KT3XSK84Mbe4NC9dLzk/dxMjJKC/7mBceszq
	EKMAB6MSD2/BuY9hQqyJZcWVuYcYJTiYlUR4deI/hQnxpiRWVqUW5ccXleakFh9ilOZgURLn
	nbnrfYiQQHpiSWp2ampBahFMlomDU6qBUawjb+aJ2y2d/EbXF3KuWPPkmtEt14zLsyuWnb20
	2r1x47Y7C1yuVvi8Mare+kpOedG5F88qCq4ndgjeOvWDjZf/kujp8zueXOxcsTb9dfA5O8O4
	BRaie8pjpJTMBANmvjHRbtjgfEqGO/SFGKeNdJSw1uQawVU9XyXXOK76M/9UXpBzLLNGgBJL
	cUaioRZzUXEiADp6bU9kAgAA

On Tue, 22 Mar 2016 23:40:54 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Contrast this with ksh where associative array assignments look like
> 
> fn=( [foo_key]=foo_val [bar_key]= )
> 
> There the parser doesn't need to know the type of fn because the
> association is explicit in the format of the parenthesized list.  If
> we ever get around to implementing that bit of ksh syntax your
> assertion would become valid.  (But in that case the assignment
> forcibly changes the type of "fn" to become an associative array so
> the typeset is irrelevant.)

Off the original topic, but actually it doesn't, at least not in bash.

$ a=(1 2 3)
$ echo ${a[2]}
3
$ a=([one]=1 [two]=2)
$ echo ${a[*]}
2

This has been interpreted as a[one]=1 then a[two]=2 with "a" still an
array, so "one" and "two" are treated as 0.  This version was quite old
(4.1.7).

pws