zsh-workers
 help / color / mirror / code / Atom feed
From: "Oliver Kiddle" <okiddle@yahoo.co.uk>
To: Bart Schaefer <schaefer@brasslantern.com>, zsh-workers@sunsite.dk
Subject: Re: PATCH: += parameter assignments
Date: Tue, 15 Jan 2002 16:16:03 +0000 (GMT)	[thread overview]
Message-ID: <20020115161603.46731.qmail@web9302.mail.yahoo.com> (raw)
In-Reply-To: <1020114184715.ZM18893@candle.brasslantern.com>

> On Jan 14, 12:45pm, Oliver Kiddle wrote:

> The point is that I can't think of -anything- reasonable to expect,
> except perhaps that in a saner world ((s+=5)) would be an error
because
> you can't add an integer to a string.  Unfortunately we're beyond
hope
> of changing that (and I wouldn't really want to anyway).
>
> About the closest thing I can come up with is that all assignments in
> (( )) should force the parameter type to change to numeric (integer
or
> float), but that has its own set of potential gotchas.

This would seem sensible to me but is it too late to be changing that?
If you think it is an option then can you elaborate on the "gotchas"?

> Better might be if += outside of (( )) always converted numerics
> to strings and then did an append.

This is perhaps worth considering. I did actually consider it at the
time but didn't do it because of ksh compatibility. To be consistent
with assignments inside (( )), it would have the convert the result of
the appending back to a numeric type afterwards (which would limit the
usefulness of it).

> The argument is something like this:  It's OK for += to mean "convert
> to
> number, do arithmetic, then convert back to the original type" as
long
> as
> it *always* means that.  It's confusing when it means one thing in ((
> ))
> and two or more things (depending on the parameter type) outside ((
)).
>
> What I don't like is that I can't look at `s+=5' and know what it's
> going
> to do.  At least I know `((s+=5))' will always add 5 numerically,
even
> if
> it might convert s to 0 first.

But you can't look at s=foo and know what it is going to do because if
s is an integer, you end up with s being 0 (or whatever foo
arithmetically evaluates to). I think it would be better if this was a
scalar assignment but it isn't.

My intention was to never in a script use:
  numeric+=val using (( numeric+=val )) instead or,
  array+=val using array+=( val ) instead
so nobody reading the script might be confused.

Perhaps we could just make a recommendation in the manual that with
numeric variables assignments outside of (( )) not be used.

Note that David Korn included += in his "first cut" for the new
standard (item 48. in 3 Aug e-mail) so it might be worth sending him an
e-mail about this.

> To have -= be additive for strings and "subtractive" for numeric
types
> is just compounding the problem.

That probably just depends on how you think about the operations. `+'
being used as an appending operation seems fairly logical to me without
thinking about it as being "additive". `-' is the reverse of `+' and
prepending the reverse of appending so `-=' for prepending made sense
to me. I suppose I've used languages where `+' is a concatenation
operator quite a lot so am used to it. Anyway, I'm happy to accept that
it might seem less logical to other people and I won't be implementing
it now.

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


  reply	other threads:[~2002-01-15 16:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-14 12:45 Oliver Kiddle
2002-01-14 13:04 ` Peter Stephenson
2002-01-14 18:47 ` Bart Schaefer
2002-01-15 16:16   ` Oliver Kiddle [this message]
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=20020115161603.46731.qmail@web9302.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).