Removing the space in `a+ +b`?

# Isiah Meadows (19 days ago)

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

# akxe at seznam.cz (19 days ago)

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

# Claude Pache (19 days ago)
# guest271314 (19 days ago)

Reversing the order does not require a space character

+b+a
# Claude Pache (19 days ago)

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?

# guest271314 (19 days ago)

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.

# Bob Myers (19 days ago)

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.

# Waldemar Horwat (19 days ago)

On 6/28/19 8:41 AM, Isiah Meadows wrote:

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

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.

 Waldemar
# Isiah Meadows (18 days ago)

Just 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

# ViliusCreator (8 days ago)

Lexer already sees ++ as operator, not + operators. It can be hard to implement something like that.

# Isiah Meadows (6 days ago)

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