Re: PATCH: += parameter assignments

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Bart wrote:

> } > 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"?
>
> You pointed one of them out yourself:
>
>       ((s+=5))
>       s=foo
>
> produces s=0, which could be surprising if `s' was previously a
scalar.

Yes, unless assignments outside (( )) were always scalar as I think
they should be.

> I'd actually forgotten about that effect of assignment to integers.

Having remembered it, would you now agree that the current += behaviour
of doing arithmetic for numerics is at least consistent with normal
assignments?

> } > 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).
>
> It'd also be impossible; following
>
>       integer s=5
>       s+=four
>
> how would one convert `5four' back to an integer?  If the type
> were going to change to scalar, that change would have to stick.

Convert it back to an integer with math evaluation resulting (for
this example) in a bad math expression error. It wouldn't be much use
and would allow some really nasty tricks to be done. My point being
that assignments inside (( )) converting results back to a scalar is
not a good idea in my opinion.

> } 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.
>
> I agree that would be better.  A function that wants to create `s' as
a
> global scalar probably *doesn't* have a `typeset -g s=' in it.  If
`s'
> already exists as an integer, strange things are going to happen.

That's bad!

Basically, I can't see a solution that only involves changes to +=
without either leaving inconsistencies with normal assignments or worse
problems.

In summary, I think the ideal would be to make all assignments depend
on context only. So:
  ((a=5)) would always result in a being of integer type and
  a=5     would always result in a being of scalar type
Any scalars used in integer context would still have to be converted to
be numeric first and vice versa. Using typeset to declare a variable as
an integer would only be useful if initialising the variable.

The trouble with this is it would be a big incompatibility and of
minimal use interactively. An option maybe?

> That whole mailing list has been silent for a long time -- or at
least

True but the list probably still works. Unless I missed it, POSIX
doesn't have assignments in arithmetic context or numeric variables.

> I
> haven't received any messages from it.  (In a related note, Austin
> Group
> just got their spec through another hurdle and are accepting errata.)

Have you looked at it recently? The last time I looked, there was very
little change to the shell spec, all the changes being in other areas.

> Really?  I'd say truncation was the reverse of appending.

Well, at least sort of. Enough that with =+ not being an option, it
seemed like a reasonable idea. I couldn't see us ever wanting -= for
truncation as you can already use subscripts to do truncation (and %=
would be more likely). I quite often do things like `fpath=(~+ $fpath)'
so I thought it'd be useful (though I can use a subscript of [1,0]).

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