Re: PATCH: internal parameter flags (resend)

[Bart Schaefer <schaefer@brasslantern.com>]

On Dec 13,  8:43pm, Peter Stephenson wrote:
}
} Handling of internal parameter flags, by which I means ones defined with
} typeset rather than applied during the subsitution, is flaky.

Hmm.

I seem to recall some discussion of this in the past.  If I recall
correctly, the upshot was that parameter flags affect the "display"
of a value when it finally comes to a point that's the functional
equivalent of inserting the value into a command line argument, and
that it specifically was not the intention that flags affect the
*actual* value stored in the parameter.

The context of the discussion as I remember it was whether the flags
should be applied immediately when assigning to the parameter (or
when changing the flags of an existing parameter with typeset), vs.
being applied when the value is retrieved, and the resolution was in
favor of the latter.  This means, for example, that you can change
the -R -L and -Z flags without affecting the underlying value.

(However, not all flags are created equal in this respect.  The -U
flag of arrays, for instance, applies at assignment time.)

Put another way, the parameter flags are substitution flags, not
value flags, and apply only when a parameter is substituted, not
every time its value is accessed.

Note particulars of this effect:

schaefer<506> typeset -Z 5 -T ARY ary
schaefer<507> ARY=5
schaefer<508> echo $ARY
00005
schaefer<509> echo $ary
5
schaefer<510> ary=(1 2)
schaefer<511> echo $ARY
001:2

So far this still works with the patch, but here's the tricky bit:

schaefer<512> echo $ARY[3]
00002

With PWS's patch applied, $ARY[3] becomes "1" in this example, which
I believe is wrong.  (I don't really think 00002 is correct either;
in fact I'd have said it should just be "2".  Why should the padding
flags of the entire string apply to a slice of it?)

This is distinct from ${${ARY}[3]}, which always was "1".

} % typeset -u param=upper
} % UPPER=VALUE
} % print ${(P)param}
} 
} prints nothing, even though $param outputs UPPER, because of the way
} flags are handled in the wrong place.

Again I think this was correct as it was.  The *value* of param is
"upper", not "UPPER", regardless of the flags; in this case
${(P)param} and ${(P)${param}} should be distinct, because the first
uses the value of $param as a name whereas the second treats the
substitution of $param as a name.  And the pre-patch zsh does just
that:

torch% typeset -u param=upper
torch% UPPER=VALUE
torch% print ${(P)param}

torch% print ${(P)${param}}
VALUE

In summary I think this change actually removes useful and intended
functionality and should be revised or backed out.

--