Re: uninvited members of associative array

[Lawrence Velázquez <larryv@xxxxxxx>]

On Sat, Dec 17, 2022, at 7:15 PM, Ray Andrews wrote:
> On 2022-12-17 14:10, Bart Schaefer wrote:
>> The input doesn't have a type. It's the result of a substitution, so
>> it's just a series of separate words.  Where the words came from is
>> not remembered.  Consider:
> I suppose it could be looked at that way

It could be looked at that way because that is the way it is.


> OTOH it could be that the type
> is referenced.  After all the type *is* recorded.  typeset -p doesn't
> just cough up the contents, it knows that an AA should display
> differently than a normal array.  Since the type information is there,
> there's no reason why it might not be referred to.

Parameter substitutions do not communicate variable attributes, nor
should they.  A core design tenet of Bourne-adjacent shells is that,
once the dust settles, using a substitution is equivalent to using
the substituted values directly.  Thus the following sets of commands
work identically in the end:

	% typeset -A arr1
	% arr1[a]=1
	% arr1[b]=
	% arr1[c]=3
	% set -A arr2 "${(@kv)arr1}"
	% typeset -p arr2
	typeset -a arr2=( a 1 b '' c 3 )

	% unset arr2
	% set -A arr2 a 1 b '' c 3
	% typeset -p arr2
	typeset -a arr2=( a 1 b '' c 3 )

Your proposal would make a hash of this, introducing special cases
that are incoherent and work differently for no good reason.  It
would also likely require "set" to be reimplemented as a keyword,
which would be ridiculous.


>> set -A thing new1 new2 "${(@kv)whatever}" new3 new4
>>
>> What "type" is that?	set -A IN "${(@Pkv)${1}}" # Copy the array to IN, the working copy.
>>
> Not fair.  In that case 'thing' is not assigned any type, so it's
> defaulting to a normal array is unavoidable.   But if I do:
>
> set -A IN "${(@Pkv)${1}}"
>
> .. and $1 names an array that typedef knows is an AA, then it wouldn't
> be very much work for IN to be matched with that type.

So the variable should only be created as an associative array if
all the "set" arguments are produced by a single parameter expansion
of another associative array?  That's a very limited use case.


> As I mentioned, my
> case would rely on the precedent that that's the way it is with integer
> promotion.

I assume you're thinking about what happens here:

	% var=(a b c)
	% typeset -p var
	typeset -a var=( a b c )
	% ((var = 1))
	% typeset -p var
	typeset -i var=1

Arithmetic contexts are their own little universe.  You can't really
use them as a comparison point here.


> Well it's simple and hopefully failsafe, but I still  can't help but
> thinking that if typedef knows the type of the input then the type of
> the output could be assigned as well as the values.

Should the following "set" command automatically create "out" as
an associative array?  After all, all its arguments come from a
single parameter expansion of an existing associative array, just
like your other examples.

	% typeset -A in=(a 121 b 121 c 23)
	% set -A out "$in"
	zsh: bad set of key/value pairs for associative array

Hm.  Okay, only if the expansion produces separate words.

	% set -A out "${(@)in}"
	zsh: bad set of key/value pairs for associative array

Okay, only if it asks for both keys and values.

	% set -A out "${(@kvu)in}"
	zsh: bad set of key/value pairs for associative array

Okay, only if it actually makes use of all the keys and values.

	% set -A out "${(@kvs:2:)in}"
	zsh: bad set of key/value pairs for associative array

Okay, only if it doesn't modify the keys and values.

	% set -A out "${(@kvo)in}"
	% typeset -p out
	typeset -A out=( [121]=121 [23]=a [b]=c )

Yay!  It ... works?

I'll stop here.  Your desired behavior would have be applied so
narrowly as to be essentially useless -- and certainly not worth
the added complexity.


> Daniel:
>
>> Could someone please clarify this in the manual? 
>
> Thanks.  It makes me feel less stupid when someone agrees with me that 
> the manual isn't as clear as it could be.

No one actually thinks that the manual is perfectly clear.  The
disagreement is with your notion that the manual should be more
verbose and have more of a tutorial vibe, when it is a reference
and should be treated as such.


> The manual was written by 
> someone too intelligent for the job -- no empathy for the less gifted.

Your learned helplessness is becoming tiresome.


-- 
vq