Re: PATCH: internal parameter flags (resend)

[Peter Stephenson <pws@xxxxxxx>]

Bart Schaefer wrote:
> 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.

I vaguely remember the discussion you refer to, but it's a different
issue.  It is still the case that the flags can be changed without
affecting the value, only when it's retrieved.  You're trying to apply
an additional rationale to what constitutes the value being retrieved
that I don't think holds water (and I don't think was ever discussed).

> 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?)

I agree that the old value is wrong, but I don't see why the new value
is.  You're now trying to add yet another rule that the padding flags
are sometimes ignored.  I chanced on the problem because I was
specifically expecting the new behaviour (in a simpler version, but with
the new order of padding and subscripting).

It is possible to compromise here, I think, by simply swapping the order
of padding and subscripting in the substitution code (and actually I
think the new description of the substitution code in the manual would
still apply), but I haven't understood why that should be.

> 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.

I really can't see how.  I think it just creates a confusing distinction
on how parameters are accessed.  Why would you set the -u flag for a
parameter and then expect it not to be applied?  What's the point in having
both flags on substitution and on parameters themselves if the latter
only apply at the same time?

> "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.

To me that's just plain confusing.

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

I haven't seen any useful functionality in there, but certainly if there
are practical examples of things that should work the old way I'd be
glad to hear them.  It's possible there actually are cases where you
need a back door to what you originally set without altering the flags,
but I can't actually think of one; all the examples I can think of would
suggest you want consistency.  In other words, I'm not saying there's
definitely no rationale for the old way, only that I haven't seen it yet
and it surprised me when I discovered how it worked.

-- 
Peter Stephenson <pws@xxxxxxx>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070