Removing the space in `a+ +b`?
Why would you need it, there should not be need to type the second + as if the first is number it will be added anyway.
---------- Původní zpráva ----------
Od: Isiah Meadows
Datum: 28. 6. 2019 v 17:44:35
Předmět: Removing the space in a+ +b?
Currently, the production a+ +b requires a space to disambiguate it from
the increment operator. However, a++b is not itself valid, as the postfix
increment cannot be immediately followed by a bare identifier on the same
line, nor can a prefix operator be preceded by one on the same line. Could
the grammar be amended to include this production and make it evaluate
equivalently to a+ +b
AdditionExpression :: AdditionExpression ++ [no LineTerminator here]
UnaryExpression
Reversing the order does not require a space character
+b+a
Le 28 juin 2019 à 19:03, guest271314 <guest271314 at gmail.com> a écrit :
Reversing the order does not require a space character
+b+a
If you have +a + +b, reversing order is not interesting.
But more importantly, there is no point into searching for a solution unless there is a problem. What is the problem with that space?
But more importantly, there is no point into searching for a solution unless there is a problem. What is the problem with that space?
Agree. The only applicable context which can fathom where the existence or non-existence of a space character in source code would be a factor is golf.
Personally I would reserve the a ++ b pattern for some future semantics
for an infix version of the ++ operator, if anyone ever comes up with one.
On 6/28/19 8:41 AM, Isiah Meadows wrote:
Currently, the production
a+ +brequires a space to disambiguate it from the increment operator. However,a++bis not itself valid, as the postfix increment cannot be immediately followed by a bare identifier on the same line, nor can a prefix operator be preceded by one on the same line. Could the grammar be amended to include this production and make it evaluate equivalently toa+ +bAdditionExpression :: AdditionExpression
++[no LineTerminator here] UnaryExpression
Maybe it could, but the extra complexity really doesn't seem worth it, particularly since you'd need the unusual line terminator restriction to avoid breaking existing code. Other uses of + don't have line terminator restrictions.
WaldemarJust an update to you all: I'm only very weakly for this, and I'm okay to rescind this suggestion.
Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com
Lexer already sees ++ as operator, not + operators. It can be hard to implement something like that.
The idea is to introduce a grammar hack that notices a++b and
evaluates it with identical semantics to a+ +b. C++ used a similar
trick to allow Foo<Bar<T>> in addition to Foo< Bar<T> > for nested
template application, because it previously conflicted with >>. For
instance, consider Foo<Bar<T>> name(arg);: it used to be parsed as
(Foo < Bar) < (T >> name(arg));, but they made a breaking change to
make it parse as a variable declaration of type Foo<Bar<T>> instead,
invoking the type's constructor with arg. I was suggesting a similar
hack, just in this case taking advantage of something that is
currently invalid.
BTW, I'm no longer behind my suggestion, and was never strongly in favor of it to begin with.
Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com
Currently, the production
a+ +brequires a space to disambiguate it from the increment operator. However,a++bis not itself valid, as the postfix increment cannot be immediately followed by a bare identifier on the same line, nor can a prefix operator be preceded by one on the same line. Could the grammar be amended to include this production and make it evaluate equivalently toa+ +bAdditionExpression :: AdditionExpression
++[no LineTerminator here] UnaryExpression