From: Bart Schaefer <schaefer@brasslantern.com>
To: "Zsh Hackers' List" <zsh-workers@sunsite.dk>
Subject: Re: PATCH: internal parameter flags (resend)
Date: Fri, 14 Dec 2007 21:56:19 -0800 [thread overview]
Message-ID: <071214215619.ZM2188@torch.brasslantern.com> (raw)
In-Reply-To: <200712141014.lBEAEmZt001008@news01.csr.com>
On Dec 14, 10:14am, Peter Stephenson wrote:
} Subject: Re: PATCH: internal parameter flags (resend)
}
} Bart Schaefer wrote:
} > schaefer<506> typeset -Z 5 -T ARY ary
} > schaefer<510> ary=(1 2)
} > 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.
Sorry; no, I'm not; that was just a remark in passing, it has nothing
really to do with the point I was making. Please ignore it for this
thread.
} > 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?
I would set it to save me from having to remember to do ${(U)param}
every time I mention $param, regardless of what order the flags are
applied ... but mentioning $param and mentioning ${(P)param} aren't
the same thing.
} > ${(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.
Let's consider a parallel situation: Parameter references in math
expressions. If I write:
setopt octalzeroes
integer -Z5 x=9
Then $(( x )) has the value 9 but $(( $x )) is "bad math expression".
Why wasn't the parameter flag applied to x in the first case? Do you
think I should have expected it to be? What if x was not an integer?
So, although I still think that ${(P)param} should use the un-altered
value [*], I'm willing to let the other part of this go because of the
following bad inconsistency with the "old way":
torch% typeset -Z5 x=6
torch% print $#x
5
torch% print $x[4]
torch%
Either $#x should report the "real" length, or $x[4] should index into
the string whose length was counted. I suspect that changing $#x in
this case would break a lot more things than changing the subscript.
[*] In part because they're the closest thing we have to namerefs, and
namerefs would not allow these kinds of transformations on the value.
next prev parent reply other threads:[~2007-12-15 5:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-13 20:43 Peter Stephenson
2007-12-14 4:46 ` Bart Schaefer
2007-12-14 10:14 ` Peter Stephenson
2007-12-15 5:56 ` Bart Schaefer [this message]
2007-12-16 13:52 ` Peter Stephenson
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=071214215619.ZM2188@torch.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-workers@sunsite.dk \
/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).