Next version of C++ as ambigous as today?

[JohnQ]

Is there any effort being made to move C++ toward having a less ambigous
grammer/closer to LALR(1)?

John

 

[Victor Bazarov]

Is there any effort being made to move C++ toward having a less
ambigous grammer/closer to LALR(1)?

I think you should ask that in 'comp.std.c++'. The standardization
procedures are discussed there.

V

 

[Ira Baxter]

Is there any effort being made to move C++ toward having a less ambigous
grammer/closer to LALR(1)?

If anything, it is likely to be much worse.
They can't dump backwards compatibility, so the existing
parse ambiguities are likely to stay, and they
are shoehorning more features into the dark
syntax corners of the language, so there are
likely to be more complications.

Of course, a miracle might occur.
I wouldn't count on it.

The real cure is to use a stronger parsing technology than
LALR, such as GLR. Our C++ front end
uses this quite successfully. The ambiguities
are still there, but they can be managed.

 

[JohnQ]

If anything, it is likely to be much worse.
They can't dump backwards compatibility, so the existing
parse ambiguities are likely to stay, and they
are shoehorning more features into the dark
syntax corners of the language, so there are
likely to be more complications.

Complexity grows on complexity. I hear ya.

Of course, a miracle might occur.
I wouldn't count on it.

That backward compatibility thing is a real bitch huh.

The real cure is to use a stronger parsing technology than
LALR, such as GLR. Our C++ front end
uses this quite successfully. The ambiguities
are still there, but they can be managed.

Or to avoid those ambiguities in a subset of C++ with a slightly modified
syntax (use <[]> for templates, for example), call it something else and
offer it to those who don't have a care about backward compatibility.

I read the first half or so of Stroustrup's "D&E" yesterday again and I for
one would not want to go through all the drudgery that the inventors of C++
did as it seems a herculean effort. The nice thing is though, to invent a
"new" language in the likeness of C++, one doesn't have to (!) for it's
already been done and the knowledge is reusable. After all these years, and
in reading certain passages in D&E, it's nice to know that, even though I
may be in the minority (or obscurity!), that there are others who voiced
opinions for things that went the other way with C++. A lot of good choice
were made. A few really bad ones were though too. The few "bad" ones are
enough to leave one wanting an "incrementally" better C++ (hehe, ++C++...
C++ should have been ++C, preincrement/then, leaving C++ for post
increment/now). What is one of those things you ask? Classes and structs
being the same. But that's easier to say now, surely, than it was back then.
But that's the point: a lot has been learned since then, but can't be
realized because of this "backward compatibility" thing. Solution: a "new"
language ("in the likeness of C++).

Let's see.. how would that go... Ooo I know, use C++ as a frontend of the
compiler for the new language. "C++Front". Well isn't that a novel idea.

John

 

[Guillermo Schwarz]

On Jun 24, 12:08 am, "JohnQ" <[email protected]>
wrote:
.... The nice thing is though, to invent a

"new" language in the likeness of C++, one doesn't have to (!) for it's
already been done and the knowledge is reusable. After all these years, and
in reading certain passages in D&E, it's nice to know that, even though I
may be in the minority (or obscurity!), that there are others who voiced
opinions for things that went the other way with C++.

The most successful C++ projects I've seen declare from the start the
subset of the language allowed to be used in the project. This
document is called the "code conventions", is written by the most
experienced programmers in the project and is used a guide during
every code review done before any check-in.

Another alternative is to use language D. http://www.digitalmars.com/d/