Dear Simon,
In message CAPnjgZ0RiiCuOgxce1mRv=GLzadWfvq6cgn0oHeSfhXrCOZR9Q@mail.gmail.com you wrote:
var++=fred
is unambiguous but very confusing. I think it would be better to disallow +
It's neither unambiguous nor confusing. It is assigning to "var++".
What? Can you read that again?
Did so, but didn't get what you might mean?
In the "<name><operator><value>" syntax there is no way to define an operator that starts with a character that is legal at the end o a name. Especially since usual escape characters like backslash are also valid characters in a name.
So if you want to maintain the status quo for variable names, you must use an operator that has no such needs.
It is much easier to change what is new and can be defined at will.
i. e. define an operator that is stil trivial to parse (as in an awk script) and does not clash with name rules.
If we define for example that "<name>=+<value>" appends, then we can also define our own escape rules, for example:
var=fred assigns var=+fred appends "fred" var=\+fred assignes the value "+fred" var=++fred appends "+fred"I don't like that at all.
Why not?
Yes, "=+" may be less intuitive than "+=", but then, it's a new feature, it is esy to use, and it does not clash with any potentially existing environments.
It requires an escape for a common case and
Well, I think if appending a value that starts with a '+' charecter is a "common case", then variable names ending ith a '+' are common case, too.
And at least my proposal can handle all situations I can think of in a somewhat reasonable way, and it does not need to place new restrictions on variable names.
is very confusing.
Is it?
Since people will be converting their out-of-tree scripts anyway, they can check for this sort of madness at the time. There should be no problem.
Agreed. There should be no problem with my proposal - the last 2 of the 4 example aboves are pathological situations which will not happen often.
Best regards,
Wolfgang Denk