zsh-users
 help / color / mirror / code / Atom feed
From: "Lawrence Velázquez" <larryv@zsh.org>
To: "Ray Andrews" <rayandrews@eastlink.ca>
Cc: zsh-users@zsh.org
Subject: Re: uninvited members of associative array
Date: Sat, 17 Dec 2022 22:44:18 -0500	[thread overview]
Message-ID: <3b9f0d96-8ba4-4196-b9ba-f6731f60ce49@app.fastmail.com> (raw)
In-Reply-To: <93583301-dbe4-673e-f8b0-b515d1e97c1d@eastlink.ca>

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


  parent reply	other threads:[~2022-12-18  3:46 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-15 23:48 Ray Andrews
2022-12-16  0:05 ` Lawrence Velázquez
2022-12-16  0:48   ` Ray Andrews
2022-12-16  1:29     ` Lawrence Velázquez
2022-12-16  2:09     ` Dominik Vogt
2022-12-16  2:56       ` Ray Andrews
2022-12-16  3:21         ` Lawrence Velázquez
2022-12-16  4:16           ` Ray Andrews
2022-12-16 10:05             ` Dominik Vogt
2022-12-16 14:13               ` Ray Andrews
2022-12-16 15:19                 ` Dominik Vogt
2022-12-16 19:14                   ` Ray Andrews
2022-12-16 16:30                 ` Daniel Shahaf
2022-12-16 18:21                   ` Ray Andrews
2022-12-16 19:04                     ` Dominik Vogt
2022-12-16 20:10                       ` Ray Andrews
2022-12-16 21:15                         ` Dominik Vogt
2022-12-16 21:33                           ` Bart Schaefer
2022-12-16 21:59                             ` Dominik Vogt
2022-12-16 22:15                               ` Bart Schaefer
2022-12-16 23:33                                 ` Ray Andrews
2022-12-17 12:47                                   ` Pier Paolo Grassi
2022-12-17 17:32                                     ` Ray Andrews
2022-12-17 18:10                                 ` Ray Andrews
2022-12-17 18:19                                   ` Roman Perepelitsa
2022-12-17 20:31                                     ` Ray Andrews
2022-12-17 20:49                                       ` Bart Schaefer
2022-12-17 21:07                                       ` Lawrence Velázquez
2022-12-17 21:52                                         ` Ray Andrews
2022-12-17 22:10                                           ` Bart Schaefer
2022-12-17 23:41                                             ` Daniel Shahaf
2022-12-18  0:15                                             ` Ray Andrews
2022-12-18  0:25                                               ` Daniel Shahaf
2022-12-18  2:13                                                 ` Ray Andrews
2022-12-18 20:12                                                   ` Daniel Shahaf
2022-12-18 20:26                                                     ` Bart Schaefer
2022-12-18 20:41                                                       ` Ray Andrews
2022-12-18  3:44                                               ` Lawrence Velázquez [this message]
2022-12-17 23:25                                         ` Daniel Shahaf
2022-12-16 21:33                           ` Ray Andrews
2022-12-16 20:25                       ` Daniel Shahaf
2022-12-16 21:43                         ` Dominik Vogt
2022-12-16  3:20 ` Bart Schaefer
2022-12-16  4:15   ` Ray Andrews
2022-12-16  8:12 ` Roman Perepelitsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3b9f0d96-8ba4-4196-b9ba-f6731f60ce49@app.fastmail.com \
    --to=larryv@zsh.org \
    --cc=rayandrews@eastlink.ca \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).