Re: PATCH: += parameter assignments

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 15,  4:16pm, Oliver Kiddle wrote:
} Subject: Re: PATCH: += parameter assignments
}
} > 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"?

You pointed one of them out yourself:

	((s+=5))
	s=foo

produces s=0, which could be surprising if `s' was previously a scalar.
I'd actually forgotten about that effect of assignment to integers.

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

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

I'm more concerned about people who intended to do exactly that but who
mistakenly left out the parens, ending up with a script that works for a
while and then mysteriously breaks.

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

That whole mailing list has been silent for a long time -- or at least 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.)

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

Really?  I'd say truncation was the reverse of appending.  Pop is the
opposite of push; unshift is the opposite of shift, not of push.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net