On Tue, Oct 19, 2021 at 10:24:25AM -0600, Simon Glass wrote: > Hi Wolfgang, > > On Tue, 19 Oct 2021 at 10:20, Wolfgang Denk <w...@denx.de> wrote: > > > > Dear Simon, > > > > In message > > <capnjgz1p6uerhdsgbzgmxfhgv7uhrfa1ufvohggd0-136ot...@mail.gmail.com> you > > wrote: > > > > > > But how do we handle this? > > > > > > var+=fred > > > > > > Is this appending to var or assigning to var+ ? > > > > It is assigning to "var+". > > er... > > > > > > > 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?
With the assumption that the append operator is "=+" and NOT "+=" then yes, your examples are unambiguous because = is not allowed in variable names, before and after. > > I think we should not change what is old and might be in use. > > > > It is much easier to change what is new and can be defined at will. > > > > 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. It requires an escape for a common case and > is very confusing. Wait saying we'll add "+SOMETHING" is a common case? > 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. I'm not sure I like saying the operator is "=+" rather than "+=" because "=+" is a less commonly seen operator and tends to be an alternative appends for special cases / side-effects / position in parsing. -- Tom
signature.asc
Description: PGP signature
