From: "Oliver Kiddle" <okiddle@yahoo.co.uk>
To: zsh-workers@sunsite.dk
Cc: schaefer@brasslantern.com
Subject: Re: PATCH: += parameter assignments
Date: Mon, 14 Jan 2002 12:45:25 +0000 (GMT) [thread overview]
Message-ID: <20020114124525.3912.qmail@web9301.mail.yahoo.com> (raw)
Sorry if you get this twice - I'm resending it after it didn't turn up
first time and sorry if Yahoo re-wraps the text horribly.
Bart Schaefer wrote:
> I'm not entirely happy with the addition of the a+=val syntax because
> it
> conflicts (conceptually, not mechanically) with the += operator that
is
> already present in the math syntax. Consider that the following:
>
> integer i=4
> typeset s=4
> i+=5
> s+=5
> ((i+=5))
> ((s+=5))
> print $i $s
>
> yields
>
> 14 50
What would you have sooner expected - `14 14'?
>
> However, what I consider to be worse is that:
>
> s=four
> ((s+=5))
> s+=5
> print $s
>
> yields
>
> 55
>
> Interpreting strings as integers in math context makes some sort of
> sense, but doing both that, and also overloading += depending on the
> parameter type, is going too far. I think the suggested change for
> -= would be even more confusing.
I'm not sure that I've entirely understood your argument here as your
example doesn't seem particularly confusing to me. The ((s+=5)) results
in 5 with s remaining a scalar - that was the case before. It remained
a scalar so the s+=5 results in 55.
I don't think it is ideal that the new += can be used for numeric
addition. I find += to be useful with arrays, scalars and associations
and it is these (with the addition of compound variables) for which I
imagine this feature was intended in ksh93. My intention was to
continue to use (( ... )) when dealing with numerics - we could add a
note to recommend this in the documentation.
Have you got any ideas on how to solve this? Short of ditching +=, the
only thing I can think of would be to make scalar+=val identical to
(( scalar+=val )) but I think it would be a pity to lose the appending
to scalars functionality. Does anyone else have any view or ideas?
> type, is going too far. I think the suggested change for -= would be
> even more confusing.
The results might not be imediately obvious after a mix of both the
math and non-math += for scalars but considered on their own I don't
find them "confusing".
> And the following can't be anything but a bug:
A bug maybe, but it has bugger all to do with the += code.
> (Previously
meaning 4.0.4 but 4.1.0-dev-1 behaves as now so the problem will have
been introduced sometime before that. 15292 at a guess as that is the
one in that time frame dealing with math.c.
Oliver
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
next reply other threads:[~2002-01-14 12:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-14 12:45 Oliver Kiddle [this message]
2002-01-14 13:04 ` Peter Stephenson
2002-01-14 18:47 ` Bart Schaefer
2002-01-15 16:16 ` Oliver Kiddle
2002-01-15 17:54 ` Bart Schaefer
2002-01-16 14:43 ` Oliver Kiddle
-- strict thread matches above, loose matches on Subject: below --
2001-12-17 12:02 Oliver Kiddle
2001-12-17 12:11 ` Borsenkow Andrej
2001-12-17 12:28 ` Peter Stephenson
2001-12-17 12:28 ` Oliver Kiddle
2002-01-07 17:38 ` Bart Schaefer
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=20020114124525.3912.qmail@web9301.mail.yahoo.com \
--to=okiddle@yahoo.co.uk \
--cc=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).