I cannot generate C files from test programs. Here is the list of statements involved by each testX.mc

test5.mc -> IF statement

test7.mc -> WHILE statement

test8.mc -> FOR LOOP

test9.mc -> DO-WHILE

Submitted on 25 April 2013 at 15:57

Note: the c syntax does not support declarations inside for loops at the moment.

for(int32_t i=1;i++;i<3)
	x *=a;

Without the declaration it works fine:

int32_t i;
for(i=1;i++;i<3)
	x *=a;

if, while, do-while and forloop without declaration are done.

The forloops with declarations are pending.

forloops with declarations are now desugared into two c statements, a declaration and a for loop with the assignment of the initial value to the variable.

this

for (int32 j = 0; j < 12; j++)

become

int32_t j;
for ( j = 0 ; (j < 12) ; j++ )

I don’t know how to avoid name conflicts, i.e. variables that are declared into the for loop ( here j ) should be visible only into the loop body… so maybe we need a slightly different desugaring

You could put a new unique number after the variable name. Stratego has a strategy for that, allthough I’m not sure what the strategy was. In that way if you declare the same var after the loop it does not give a conflict.

I think that’s not the proper way to do things. What you are trying to do here should probably be done by namebinding. I remember seeing an example that addresses your problem when reading about NaBL for the Compiler Construction course.

I thought that the issue at stake here is that the desugared c code is not valid in the following situation.

for (int32 j = 0; j < 12; j++){
     // some stuff
}
int32 j = 3;

That cannot really be solved by namebinding, only be changing the generated variable name.

Desugaring with changing the name of the variable is evil, since it does indeed a name binding related thing. But you can desugar to a block:

{int32 j; for (j = 0; j <12; j++) {...}}

However, why do you want to do this at all? Where is the syntactic sugar in it? The declaration?

BTW, the example by Daco might not be valid in the first place. At least it is invalid in Java.

Yes, that’s the situation I was referring to.
If I remember correctly, you should be able to define namebinding rules that explicitly state the scope of a variable.

Something along the lines of:

for(var, cond, exp, body):
defines Variable var in body

I never used this though, so I don’t know if it works.

I was able to generate a new unique name for the variable but how can I change every reference to that variable in the desugaring? I mean, if the the var J is desugared into J2 every occurence of J in the loop body should be changed into J2, right?

Yes, and that’s why it is nasty to do things this way.

You should desugar the for loop into a block as Guido suggested. Then the block can generate an anonymous scope in NBL:

Block(_):
    scopes Variable

Also, if you are generating C99 code, a declaration inside a for loop is allowed. I guess the C syntax from the metaborg-c project is ANSI C?

The first thing to discuss is still, why this should be desugared at all? We have two desugarings:

1. A real desugaring to BaseC, which makes analyses easier.
2. A transformation to standard C, which is the final compilation step.

Which one are we talking here?

I think it’s both. You can have multiple variable definitions in a for loop, which would be hard to do name binding for. If you desugar it into separate variable definitions in a block it is easier for name binding and makes compilation to ANSI C possible.

Ok, this helps me understand it. Thus, it is a pre-name-binding desugaring, which is also useful for the final compilation, which is however not the root cause for doing it.