www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - is this right??

reply BCS <none anon.com> writes:
void main()
{
  int s;
  mixin("s") = 5;
}
-----
Line 4: found '=' when expecting ';'


http://www.digitalmars.com/d/1.0/expression.html#MixinExpression
Jun 16 2009
next sibling parent reply BCS <none anon.com> writes:
Hello BCS,


 void main()
 {
 int s;
 mixin("s") = 5;
 }
 -----
 Line 4: found '=' when expecting ';'
 http://www.digitalmars.com/d/1.0/expression.html#MixinExpression
 



(mixin("s")) = 5;

Given that the above works, it looks like the parser prematurely commits 
to a mixin declaration when it finds "mixin (" at function scope.

Unless someone spots a flaw in this, I'll post a bug.
Jun 16 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
BCS escribió:

 Hello BCS,
 

 void main()
 {
 int s;
 mixin("s") = 5;
 }
 -----
 Line 4: found '=' when expecting ';'
 http://www.digitalmars.com/d/1.0/expression.html#MixinExpression



 (mixin("s")) = 5;
 
 Given that the above works, it looks like the parser prematurely commits 
 to a mixin declaration when it finds "mixin (" at function scope.
 
 Unless someone spots a flaw in this, I'll post a bug.



Yes, at that point the parser is parsing statements, so if it finds a 
"mixin(...)" it turns it into a statement.

I'm thinking about how to fix this. I think the parser should peek the 
next token after the closing parenthesis. If it's a semicolon, then 
treat it as a statement-mixin. Else, just invoke parseAssignExp and 
create a new ExpStatement.

I modified this in Descent and it seems to work. :-)

Here's the code (in Java, but the idea is simple to translate to C++):

// inside Parser::parseStatement
case TOKmixin: {
     Dsymbol d;
     t = peek(token);
     if (t.value == TOKlparen)
     {
         if (peekPastParen(t).value != TOKsemicolon) {
             Expression e = parseAssignExp();
             s = new ExpStatement(loc(), e);
         } else {
             // mixin(string)
             nextToken();
             check(TOKlparen);
             Expression e = parseAssignExp();
             check(TOKrparen);
             check(TOKsemicolon);
             s = newCompileStatement(loc(), e);
         }
         break;
     } else {
         d = parseMixin();
         s = newDeclarationStatement(loc(), d);
         break;
     }
}
Jun 16 2009
parent reply BCS <none anon.com> writes:
Hello Ary,


 BCS escribió:
 

 Hello BCS,
 

 void main()
 {
 int s;
 mixin("s") = 5;
 }
 -----
 Line 4: found '=' when expecting ';'
 http://www.digitalmars.com/d/1.0/expression.html#MixinExpression



 
 Given that the above works, it looks like the parser prematurely
 commits to a mixin declaration when it finds "mixin (" at function
 scope.
 
 Unless someone spots a flaw in this, I'll post a bug.
 



 "mixin(...)" it turns it into a statement.
 



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

Hope you don't mind me quoting you.
Jun 16 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
BCS escribió:

 Hello Ary,
 

 BCS escribió:


 Hello BCS,


 void main()
 {
 int s;
 mixin("s") = 5;
 }
 -----
 Line 4: found '=' when expecting ';'
 http://www.digitalmars.com/d/1.0/expression.html#MixinExpression




 Given that the above works, it looks like the parser prematurely
 commits to a mixin declaration when it finds "mixin (" at function
 scope.

 Unless someone spots a flaw in this, I'll post a bug.



 "mixin(...)" it turns it into a statement.



 http://d.puremagic.com/issues/show_bug.cgi?id=3073
 
 Hope you don't mind me quoting you.



Not at all!

But later when I went to sleep I thought about that a little more, and 
look at this:

1. mixin("int x = 2;");
2. mixin("x = 2");

The first should be treated as a MixinStatement, because it ends with a 
semicolon. The second should be treated as a MixinExpression, because it 
doesn't end with a semicolon (and it's a perfectly valid expression, 
it's an assign expression). But according to my patch it'll be treated 
as a statement and it'll fail.

Now this:

3. mixin("int x = 2");

is neither of them.

You can only deduce that information if you can extract the contents of 
the mixin, paste it in the source file and treat the whole line as a 
statement, and you'd get things right. But now all of those lines can be:

mixin(secret());

and now you don't know, you'll have to wait for semantic anlaysis to 
know that, but then it's too late.

But I think my patch is reasonable because it allows you to do more 
things than before, it's backwards compatible and also you'd almost 
never do number 2 but instead use number 1.
Jun 17 2009
prev sibling parent reply hasen <hasan.aljudy gmail.com> writes:
BCS wrote:

 void main()
 {
  int s;
  mixin("s") = 5;
 }
 -----
 Line 4: found '=' when expecting ';'
 
 
 http://www.digitalmars.com/d/1.0/expression.html#MixinExpression
 
 



mixin *expression*

(4+3) = 5;
Jun 16 2009
parent reply hasen <hasan.aljudy gmail.com> writes:
hasen wrote:

 BCS wrote:

 void main()
 {
  int s;
  mixin("s") = 5;
 }
 -----
 Line 4: found '=' when expecting ';'


 http://www.digitalmars.com/d/1.0/expression.html#MixinExpression



 mixin *expression*
 
 (4+3) = 5;
 



Oh, never mind,

AssignExpression can be of the form:

ConditionalExpression = AssignExpression

my bad.
Jun 16 2009
parent BCS <none anon.com> writes:
Hello hasen,


 hasen wrote:
 

 BCS wrote:
 

 void main()
 {
 int s;
 mixin("s") = 5;
 }
 -----
 Line 4: found '=' when expecting ';'
 http://www.digitalmars.com/d/1.0/expression.html#MixinExpression
 



 
 (4+3) = 5;
 



 
 AssignExpression can be of the form:
 
 ConditionalExpression = AssignExpression
 
 my bad.



Irony: I wrote a lib that abuses the grammer to allow exactly that kind of 
syntax <g>

http://www.dsource.org/projects/scrapple/browser/trunk/backmath
Jun 16 2009