> Pavel Minayev wrote:
> 
> 
> I'm awfully close to a Bison parser that can parse D (it seems as though
> it
> can be done, with some tricks).  But the nonterminal "expression" now
> needs to be split into two almost identical nonterminals: "expression" and
> "expressions_legal_inside_a_conditional_test".  Ick.


Me too.

Instead of using to near identical expressions you could pass a flag in
yylval stating wether the expression is valid in a conditional and test
that flag if the expression is used in the conditional (this is the way I
use to generate warnings in the oomic parser for such expressions).
This would move the problem from the parser to the helper code,  and could
be implemented in a few lines.

C 2002/6/11

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D0627D9.8F67461A@deming-os.org...
> Two questions:
> 1) Can you point me to the spec where this is?  I can never find
> stuff...
> 2) How do you do this without creating special-case rules?  One of the
> great advantages of C is that it is mostly (if you discount variable &
> type declarations) context-free.  If (var = 0) is an expression that
> results in an integer, and integers are legal arguments to if(), then
> if(var = 0) should be legal.
>
> If you add this inconsistency, you're going to make D parsers and compilers MUCH harder to write...

This is not in the parser. It is in the semantic analysis phase, where
AssignExp's issue an error when asked to convert to boolean (via the
checkBoolean() virtual function).

"Matthew Wilson" <dm@synesis-group.com> wrote in message news:ae3gtl$11dq$1@digitaldaemon.com...
> What do you think about having a compiler option "-pendantic" for practioners of the true way ... sorry, I mean pedantic sods like me?

As a general rule, and from my painful experience with C/C++ and the multitude of command line switches to change the language it will compile, I think it's best to avoid all compiler switches which change the language!

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ae2re0$8qk$1@digitaldaemon.com...
> But you can't global search/replace 0 with null.

True, but the compiler will quickly find them for you anyway <g>.

Fair enough.

Then let's have maximal pedantic built-in!

"Walter" <walter@digitalmars.com> wrote in message news:ae5man$7vv$1@digitaldaemon.com...
>
> "Matthew Wilson" <dm@synesis-group.com> wrote in message news:ae3gtl$11dq$1@digitaldaemon.com...
> > What do you think about having a compiler option "-pendantic" for practioners of the true way ... sorry, I mean pedantic sods like me?
>
> As a general rule, and from my painful experience with C/C++ and the multitude of command line switches to change the language it will compile,
I
> think it's best to avoid all compiler switches which change the language!
>
>

Very true.  I use this to my advantage alot;  comment out or change the name of a variable or function at point of declaration and poof the compiler red-flags all occurrences of it.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ae5man$7vv$2@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ae2re0$8qk$1@digitaldaemon.com...
> > But you can't global search/replace 0 with null.
>
> True, but the compiler will quickly find them for you anyway <g>.

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D064081.4F84E1F9@deming-os.org...

> I'm awfully close to a Bison parser that can parse D (it seems as though
it
> can be done, with some tricks).  But the nonterminal "expression" now
needs to
> be split into two almost identical nonterminals: "expression" and "expressions_legal_inside_a_conditional_test".  Ick.

Can't you define the generic "expression" as a list of
"legal_conditional_expressions"
separated by assignment ops?

"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:ae5rej$djr$1@digitaldaemon.com...

> Fair enough.
>
> Then let's have maximal pedantic built-in!

Nooooo!!! =)

Let's better have some way to move switches inside the programs, like VB's OPTION statement.

    int a;
    option strictbool = true;
    if (a) { ... }   // error!
    option strictbool = false;
    if (a) { ... }   // okay

Pavel Minayev wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D064081.4F84E1F9@deming-os.org...
>
> > I'm awfully close to a Bison parser that can parse D (it seems as though
> it
> > can be done, with some tricks).  But the nonterminal "expression" now
> needs to
> > be split into two almost identical nonterminals: "expression" and "expressions_legal_inside_a_conditional_test".  Ick.
>
> Can't you define the generic "expression" as a list of
> "legal_conditional_expressions"
> separated by assignment ops?

Yeah, but it gets really ugly.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Don't like it. I think a command-line option is better than this.

Never been a fan of having stuff in the code that pertains to environment /
user choices (such as #pragma comment(lib: etc. etc)

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ae6voa$1ifk$1@digitaldaemon.com...
> "Matthew Wilson" <dmd@synesis.com.au> wrote in message news:ae5rej$djr$1@digitaldaemon.com...
>
> > Fair enough.
> >
> > Then let's have maximal pedantic built-in!
>
> Nooooo!!! =)
>
> Let's better have some way to move switches inside the programs, like VB's OPTION statement.
>
>     int a;
>     option strictbool = true;
>     if (a) { ... }   // error!
>     option strictbool = false;
>     if (a) { ... }   // okay
>
>
>