On Sep 15, 7:07 pm, Florian Goujeon <florian.gouj...@42ndart.org>
wrote:

      [...]
> Is there any good reason for the C++ grammar to be context-sensitive?

History.  The C grammar was already context sensitive, and the
declaration syntax of C didn't scale very well when features
started to be added.

> If not, is there any chance that C++ standard will be modified
> to allow context-free parsers to parse it?

No.  I don't think it could be done without breaking a very
large number of programs.

> After all, these cases are pretty rare (well, "a * b;" is very
> frequent, but it's almost never a multiplication).
> Besides, C++0x, by allowing double right angle brackets in
> nested template-ids, deprecated this kind of expression:
>    template<int I> struct test{};
>    test<1 >> 2> t; //correct in C++98, but not in C++0x

> Unless I'm missing something, it seems like the C++ grammar could be
> made context-free with minimum effort - the same kind of effort that
> has been made to allow double right angle brackets in nested
> template-ids.

Do it.  If you can come up with a reasonable proposal, which
doesn't break too much existing code, I'm sure that the
committee (and a lot of compiler vendors as well) would be more
than interested.

--
James Kanze

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Florian Goujeon wrote:

> However, in these cases, the syntax ambiguities could be easily
> resolved by adding parentheses:
>    (a * b); //multiplication
> and:
>    bool bool_ = a < (b || c) > (d && e); //function call

or ((a < (b || c)) > (d && e)).

>
> Is there any good reason for the C++ grammar to be context-sensitive?

The coders    reluctance to type ()?

(Note: PERL was created more restrictive wrt {}, and nobody died, AFAIK :-))

>
> Unless I'm missing something, it seems like the C++ grammar could be
> made context-free with minimum effort - the same kind of effort that
> has been made to allow double right angle brackets in nested
> template-ids.

Well, you did not get it right at the first approach, so chances are other
people will not either ;-)

>
> Making the C++ grammar context-free would make C++ parsers (and
> intrinsically compilers) faster, easier to code and independent of
> semantic analysis and would indirectly improve the user experience.
> This would be great.

There is nothing that prevents you from typing your code in an unambiguous
way, and it will greatly help you with get along with compilers that get an
indigestion at e.g. { int *a (NULL); }.  If I were you, I would even write
{ DEFINE_VARIABLE (POINTER (int), NULL); }, and let the macros figure out
how to push it down.  That would get you much praise from a casual reader,
and perhaps even from Don Knuth, and a vigorous opposition from your fellow
coders who just want to get it running and go home, and that are quite happy
with
{ char *x = malloc (100); }
and would consider
(malloc (100 * sizeof *x)) an abomination
(and even that is not quite correct).

Best regards,
Chris




--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Sep 20, 2:14 am, Krzysztof =AFelechowski <giecr...@stegny.2a.pl>
wrote:
> or ((a < (b || c)) > (d && e)).

Don't be ironic, it's far from what I said.
There's no need to put so many parentheses to resolve this kind of
ambiguities.

Besides, Lisp programmers have already taken almost every parentheses.
It is our duty to save them.


> > Is there any good reason for the C++ grammar to be context-sensitive?
>
> The coders=B4 reluctance to type ()?

As I said, cases where parentheses are needed are pretty rare.
This would affect the coders' experience as much as the obligation to
add parentheses around right-shift expressions in template-ids will.
(Once again: unless I'm missing something. If so, please tell me.)


> Well, you did not get it right at the first approach, so chances are othe=
r
> people will not either ;-)

I beg your pardon, I don't understand your answer...?


> There is nothing that prevents you from typing your code in an unambiguou=
s
> way [snip]

Actually, there's no need to perform disambiguations in the cases you
enumerated, since, as I said, { a * b; } will be considered as a
pointer declaration.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Florian Goujeon wrote:
> Unless I'm missing something, it seems like the C++ grammar could be
> made context-free with minimum effort - the same kind of effort that
> has been made to allow double right angle brackets in nested
> template-ids.
>
> Making the C++ grammar context-free would make C++ parsers (and
> intrinsically compilers) faster, easier to code and independent of
> semantic analysis and would indirectly improve the user experience.
> This would be great.

I read a (research) paper not long ago which discussed an alternative
syntax for accessing the features of C++. It simply mapped the new
syntax to the current C++. But for the life of me I can't find it, or
even remember its name. Anyone?

While the language itself is not probable to change, it is always
possible to create such syntactic alternatives with an additional
converter in the middle.

--
http://kaba.hilvi.org

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hello,

C++ is known to be a very hard to parse programming language, notably
because its grammar is context-sensitive.

For example, to following statement=85:
   a * b;
=85 may be either a multiplication or a pointer declaration.

Trickier example. In the following declaration=85:
   bool bool_ = a < b || c > (d && e);
=85 the right-hand side expression may be either a boolean expression
(where 'a', 'b', 'c', 'd' and 'e' are variables of type bool) or a
function template call (whose name is 'a', which takes one bool
template parameter and where 'b', 'c', 'd' and 'e' are all variables
of type const bool).

However, in these cases, the syntax ambiguities could be easily
resolved by adding parentheses:
   (a * b); //multiplication
and:
   bool bool_ = a < (b || c) > (d && e); //function call

Is there any good reason for the C++ grammar to be context-sensitive?
If not, is there any chance that C++ standard will be modified to
allow context-free parsers to parse it?

After all, these cases are pretty rare (well, "a * b;" is very
frequent, but it's almost never a multiplication).
Besides, C++0x, by allowing double right angle brackets in
nested template-ids, deprecated this kind of expression:
   template<int I> struct test{};
   test<1 >> 2> t; //correct in C++98, but not in C++0x

Unless I'm missing something, it seems like the C++ grammar could be
made context-free with minimum effort - the same kind of effort that
has been made to allow double right angle brackets in nested
template-ids.

Making the C++ grammar context-free would make C++ parsers (and
intrinsically compilers) faster, easier to code and independent of
semantic analysis and would indirectly improve the user experience.
This would be great.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]