Re: ${(P)${foo}} (Re: Associative array ordering)

Re: ${(P)${foo}} (Re: Associative array ordering)

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Feb 2,  5:58pm, Sven Wischnowsky wrote:
> } Subject: Re:  Associative array ordering and selective unset (Re: Example 
> }
> } I wrote:
> } 
> } > Maybe yet another flag? E.g.: `P' makes the thing after the
> } > flags be used as the name of a parameter. So `${(P)foo}' is the same
> } > as `$foo', but `${(P)${foo}}' will take the value of `foo' as the name 
> } > of a parameter and work on it.
> } 
> } The patch below does this (it was quite easy).
> 
> Well, you got to that before I got around to responding to that particular
> tidbit.
> 
> The other day someone asked about ksh namerefs in zsh, and I said that with
> ${(e)...} you didn't really need them.  Here's a case where they would have
> been exactly what the doctor ordered; in an appropriate muddle of ksh and
> zsh syntax,
> 
> 	nameref ref=$arg[1]
> 	echo ${(t)!ref}
> 
> which is a whole lot easier on the eyes, it must be admitted.

Yes, but in cases where you need it only once, this is a bit verbose,
don't you think?

> } With it you can do
> } things like the above or `${(P)+${foo}}' to see if the parameter whose 
> } name is stored in `foo' is set.
> 
> There are actually several ways we can go from here.
> 
> We can keep Sven's syntax as is.
> 
> We can modify Sven's syntax so that ${(P)foo} is the same as ${(P)${foo}},
> and make ${!foo} a synonym for it in ksh compatibility mode.  This is
> almost like ksh namerefs except that they don't get their own namespace.

I first thought about implementing ${(P)foo}, but implementing only the one 
I did, seemed easier. Now that I had a deeper look into the substitution 
code again, making ${(P)foo} work doesn't look that complicated, too.
Although that would be less powerful, so keeping the thing I
implemented may still be useful.
Making ${!foo} a synonym may be useful, and as far as I can this we
wouldn't have to restrict this to ksh compatibility mode (am I missing 
something?).

> We can make ${!foo} a synonym for ${(P)${foo}} (either in ksh mode or all
> the time), leaving ${(P)foo} alone.  I'm not too thrilled about this one.

Neither am I.

> We can add another hash table to be the nameref namespace, implement the
> nameref and `typeset -n' builtins, and make ${(P)foo} [or another letter]
> and ${!foo} synonyms where `foo' must be a nameref.  That would deprecate
> ${(P)${foo}}.

Namerefs may be useful anyway. But, as I said above I wouldn't like to
have to invent a nameref just to use this double-lookup once.

So, I'd vote for the ${!foo}=${(P)foo}=${(P)${foo}}-but-${(P)${foo#*=}}-
still-works suggestion, or for the last one (without the deprecation
bit). Those two can be combined anyway.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: ${(P)${foo}} (Re: Associative array ordering)

[Bart Schaefer]

On Feb 3,  9:02am, Sven Wischnowsky wrote:
} Subject: Re:  ${(P)${foo}} (Re: Associative array ordering)
}
} Bart Schaefer wrote:
} 
} > There are actually several ways we can go from here.
} > 
} > We can keep Sven's syntax as is.
} > 
} > We can modify Sven's syntax so that ${(P)foo} is the same as ${(P)${foo}},
} > and make ${!foo} a synonym for it in ksh compatibility mode.  This is
} > almost like ksh namerefs except that they don't get their own namespace.
} 
} I first thought about implementing ${(P)foo}, but implementing only the one 
} I did, seemed easier.

I suspect that's at least in part how we ended up with ${${param}} instead
of simply ${{param}} in the first place, but ....

} Now that I had a deeper look into the substitution 
} code again, making ${(P)foo} work doesn't look that complicated, too.
} Although that would be less powerful, so keeping the thing I
} implemented may still be useful.

Yes, particularly ${(P)$(...)} is probably useful, even if ${(P)${...}}
was not.

} Making ${!foo} a synonym may be useful, and as far as I can this we
} wouldn't have to restrict this to ksh compatibility mode (am I missing 
} something?).

You're missing `setopt banghist`, which is unsetopt in ksh mode.  ${!foo}
will have substituted the history item beginning with "foo" long before
it makes it to the parameter code.  That's why the ${!assoc[@]} syntax
is accepted only in ksh mode, too.

Let's go this way:  Implement ${(P)foo}, the same as ${(P)${foo}} where
the inner ${...} has no flags or modifiers, and leave ${!foo} undefined
until we do real namerefs (if we ever do).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: ${(P)${foo}} (Re: Associative array ordering)

[Peter Stephenson]

Sven Wischnowsky wrote:
> I forgot to append the patch for the docs, sorry.

Needs a slight addition.

--- Doc/Zsh/expn.yo.par	Wed Feb  3 11:33:50 1999
+++ Doc/Zsh/expn.yo	Wed Feb  3 11:39:43 1999
@@ -531,7 +531,7 @@
 substitution in place of the parameter name this flag makes the result
 of the expansion be taken as a parameter name which is then
 used. E.g. if you have `tt(foo=bar)' and `tt(bar=baz)', the strings
-`tt(${(P)foo}' and `tt(${(P)${foo}})' will be expanded to `tt(baz)'.
+`tt(${(P)foo})' and `tt(${(P)${foo}})' will be expanded to `tt(baz)'.
 )
 item(tt(o))(
 Sort the resulting words in ascending order.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: ${(P)${foo}} (Re: Associative array ordering)

[Sven Wischnowsky]

I wrote:

> Bart Schaefer wrote:
> 
> > Let's go this way:  Implement ${(P)foo}, the same as ${(P)${foo}} where
> > the inner ${...} has no flags or modifiers, and leave ${!foo} undefined
> > until we do real namerefs (if we ever do).
> 
> Yep.

I forgot to append the patch for the docs, sorry.

Bye
 Sven

--- od/Zsh/expn.yo	Wed Feb  3 08:46:59 1999
+++ Doc/Zsh/expn.yo	Wed Feb  3 11:06:10 1999
@@ -525,13 +525,13 @@
 nested but too deep recursion may have unpredictable effects.
 )
 item(tt(P))(
-If used with a parameter name, this flag has no effect. But if it is
-used with a tt(${)...tt(}) type parameter expression or a
-tt($LPAR())...tt(RPAR()) type command substitution in place of
-the parameter name this flag makes the result of the expansion be
-taken as a parameter name which is then used. E.g. if you have
-`tt(foo=bar)' and `tt(bar=baz)', the string `tt(${(P)${foo}})' will be 
-expanded to `tt(baz)'.
+This makes the value of the parameter var(name) be taken as a
+parameter name on which to work. If it is used with a tt(${)...tt(})
+type parameter expression or a tt($LPAR())...tt(RPAR()) type command
+substitution in place of the parameter name this flag makes the result
+of the expansion be taken as a parameter name which is then
+used. E.g. if you have `tt(foo=bar)' and `tt(bar=baz)', the strings
+`tt(${(P)foo}' and `tt(${(P)${foo}})' will be expanded to `tt(baz)'.
 )
 item(tt(o))(
 Sort the resulting words in ascending order.

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: ${(P)${foo}} (Re: Associative array ordering)

[Sven Wischnowsky]

Bart Schaefer wrote:

> Let's go this way:  Implement ${(P)foo}, the same as ${(P)${foo}} where
> the inner ${...} has no flags or modifiers, and leave ${!foo} undefined
> until we do real namerefs (if we ever do).

Yep.

Bye
 Sven

--- os/subst.c	Wed Feb  3 10:55:01 1999
+++ Src/subst.c	Wed Feb  3 10:48:21 1999
@@ -991,6 +991,12 @@
 	copied = 1;
 	*s = sav;
 	v = (Value) NULL;
+    } else if (aspar) {
+	if ((v = getvalue(&s, 1))) {
+	    val = idbeg = getstrvalue(v);
+	    subexp = 1;
+	} else
+	    vunset = 1;
     }
     if (!subexp || aspar) {
 	char *ov = val;

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

${(P)${foo}} (Re: Associative array ordering)

[Bart Schaefer]

On Feb 2,  5:58pm, Sven Wischnowsky wrote:
} Subject: Re:  Associative array ordering and selective unset (Re: Example 
}
} I wrote:
} 
} > Maybe yet another flag? E.g.: `P' makes the thing after the
} > flags be used as the name of a parameter. So `${(P)foo}' is the same
} > as `$foo', but `${(P)${foo}}' will take the value of `foo' as the name 
} > of a parameter and work on it.
} 
} The patch below does this (it was quite easy).

Well, you got to that before I got around to responding to that particular
tidbit.

The other day someone asked about ksh namerefs in zsh, and I said that with
${(e)...} you didn't really need them.  Here's a case where they would have
been exactly what the doctor ordered; in an appropriate muddle of ksh and
zsh syntax,

	nameref ref=$arg[1]
	echo ${(t)!ref}

which is a whole lot easier on the eyes, it must be admitted.

} With it you can do
} things like the above or `${(P)+${foo}}' to see if the parameter whose 
} name is stored in `foo' is set.

There are actually several ways we can go from here.

We can keep Sven's syntax as is.

We can modify Sven's syntax so that ${(P)foo} is the same as ${(P)${foo}},
and make ${!foo} a synonym for it in ksh compatibility mode.  This is
almost like ksh namerefs except that they don't get their own namespace.

We can make ${!foo} a synonym for ${(P)${foo}} (either in ksh mode or all
the time), leaving ${(P)foo} alone.  I'm not too thrilled about this one.

We can add another hash table to be the nameref namespace, implement the
nameref and `typeset -n' builtins, and make ${(P)foo} [or another letter]
and ${!foo} synonyms where `foo' must be a nameref.  That would deprecate
${(P)${foo}}.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com