www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Context sensitivity

reply bearophile <bearophileHUGS lycos.com> writes:
I was away.

This is D code adapted from a blog post about C language:
http://eli.thegreenplace.net/2011/05/02/the-context-sensitivity-of-c%E2%80%99s-grammar-revisited/

http://www.reddit.com/r/programming/comments/h23h3/the_context_sensitivity_of_cs_grammar_revisited/


Three little D2 programs that compile with no errors. Similar code is allowed
in C too:

//----------------

alias int Foo;
void foo() {
    Foo bar;
    float Foo;
}
void main() {}

//----------------

alias int Foo;
void foo() {
    Foo Foo;
    int bar = Foo + 2;
    assert (bar == 2);
}
void main() {}

//----------------

alias char Foo;
void foo() {
    int bar = Foo.sizeof, Foo, spam = Foo.sizeof;
    assert(bar == 1);
    assert(spam == 4);
}
void main() {}

//----------------

Note: currently I have put nothing about this in Bugzilla.

My question is: is it OK to keep allowing such kind of code in D2 too? Or is it
better to statically forbid it?

A disadvantage of statically disallowing it is the breakage of some valid C
code. On the other hand I don't think I want to find code like that in D
programs.

Bye,
bearophile
May 03 2011
next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 03/05/2011 11:18, bearophile wrote:

 I was away.

 This is D code adapted from a blog post about C language:
 http://eli.thegreenplace.net/2011/05/02/the-context-sensitivity-of-c%E2%80%99s-grammar-revisited/

 http://www.reddit.com/r/programming/comments/h23h3/the_context_sensitivity_of_cs_grammar_revisited/


 Three little D2 programs that compile with no errors. Similar code is allowed
in C too:

 //----------------

 alias int Foo;
 void foo() {
      Foo bar;
      float Foo;
 }
 void main() {}

 //----------------

 alias int Foo;
 void foo() {
      Foo Foo;
      int bar = Foo + 2;
      assert (bar == 2);
 }
 void main() {}

 //----------------

 alias char Foo;
 void foo() {
      int bar = Foo.sizeof, Foo, spam = Foo.sizeof;
      assert(bar == 1);
      assert(spam == 4);
 }
 void main() {}

 //----------------

 Note: currently I have put nothing about this in Bugzilla.

 My question is: is it OK to keep allowing such kind of code in D2 too? Or is
it better to statically forbid it?

 A disadvantage of statically disallowing it is the breakage of some valid C
code. On the other hand I don't think I want to find code like that in D
programs.

 Bye,
 bearophile


This is why there are code conventions that have different rules for 
naming variables/fields and types, so you don't confuse them...

-- 
Bruno Medeiros - Software Engineer
May 06 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Bruno Medeiros, Software Engineer:


 This is why there are code conventions that have different rules for
 naming variables/fields and types, so you don't confuse them...


Walter has just shown slides in D.announce that explain why sometimes code
conventions aren't enough :-)

Bye,
bearophile
May 06 2011
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 06/05/2011 17:52, bearophile wrote:

 Bruno Medeiros, Software Engineer:


 This is why there are code conventions that have different rules for
 naming variables/fields and types, so you don't confuse them...


 Walter has just shown slides in D.announce that explain why sometimes code
conventions aren't enough :-)

 Bye,
 bearophile


I wasn't saying code conventions are good enough for all kinds of human 
errors, I was just talking about this particular one, of confusing and 
overlapping variable and type names.

-- 
Bruno Medeiros - Software Engineer
May 19 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Bruno Medeiros:


 I wasn't saying code conventions are good enough for all kinds of human 
 errors, I was just talking about this particular one, of confusing and 
 overlapping variable and type names.


I think in this case some compiler strictness is better than code conventions.
Few days ago I have opened an issue, to avoid this topic to be lost and
forgotten:
http://d.puremagic.com/issues/show_bug.cgi?id=6005

Bye,
bearophile
May 19 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
 Bruno Medeiros:


 I wasn't saying code conventions are good enough for all kinds of human
 errors, I was just talking about this particular one, of confusing and
 overlapping variable and type names.


 I think in this case some compiler strictness is better than code conventions.


Few days ago I have opened an issue, to avoid this topic to be lost and
forgotten:

 http://d.puremagic.com/issues/show_bug.cgi?id=6005

 Bye,
 bearophile


I think it would be ok to disallow that statically. But it is important how to
do
it. Disallowing shadowing a name after it has already been referenced would be
the
best possibility I think. It might slightly compromise compiler efficiency
though,
because that is additional information that needs to be stored in the symbol
table.

Timon
May 19 2011
prev sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
bearophile wrote:


 I was away.
 
 This is D code adapted from a blog post about C language:
 http://eli.thegreenplace.net/2011/05/02/the-context-sensitivity-of-


c%E2%80%99s-grammar-revisited/

 
 


http://www.reddit.com/r/programming/comments/h23h3/the_context_sensitivity_of_cs_grammar_revisited/

 
 
 Three little D2 programs that compile with no errors. Similar code is
 allowed in C too:
 
 //----------------
 
 alias int Foo;
 void foo() {
     Foo bar;
     float Foo;
 }
 void main() {}
 
 //----------------
 
 alias int Foo;
 void foo() {
     Foo Foo;
     int bar = Foo + 2;
     assert (bar == 2);
 }
 void main() {}
 
 //----------------
 
 alias char Foo;
 void foo() {
     int bar = Foo.sizeof, Foo, spam = Foo.sizeof;
     assert(bar == 1);
     assert(spam == 4);
 }
 void main() {}
 
 //----------------
 
 Note: currently I have put nothing about this in Bugzilla.
 
 My question is: is it OK to keep allowing such kind of code in D2 too? Or
 is it better to statically forbid it?
 
 A disadvantage of statically disallowing it is the breakage of some valid
 C code. On the other hand I don't think I want to find code like that in D
 programs.
 
 Bye,
 bearophile


That's surprising, I didn't know it. I agree it should be statically 
forbidden, which does not violate the principles wrt C compatibility because 
it doesn't silently change semantics. 

Tt also interacts with templates because they can pick up the redefined 
name. Not sure if it's really a problem, it would be interesting to think of 
a situation where this can occur in practice. Maybe with lots of templates, 
ctfe and mixins it can became non-obvious? It sure as hell would be 
confusing to run into such a bug.
May 06 2011