Scoping rules differ from legacy gen_erate.exe

[john-tornblom]

Scoping rules for defining new variables in included files differ from legacy gen_erate.exe

For example:

.include "assign_x.arc" .// assign the variable x a literal value
.print "${x}"

will print the value of x to stdout when using pyrsl, but the original implementation prints an error message claiming x is undefined.

However, the following code works as expected in both implementations, i.e. the variable x is reassigned a new value by the included arcetype file.

.assign x = "init value"
.include "assign_x.arc" .// assign the variable x a literal value
.print "${x}"

This might be a bug in the original version of gen_erate.exe

[cortlandstarrett]

I agree and consider this a bug in gen_erate. gen_erate is the only language I have seen that scopes macro inclusion. Ick. Can anyone think of merit for such scoping?

[rmulvey]

I am not sure it should be called a bug, however I agree that the pyrsl version is an improvement and I see no reason why we would not move forward with this improvement.
The reason I am hesitant to write that it is a bug in gen_erate is that it may very well be that gen_erate was implemented this way for a reason (perhaps not a good reason :), but a reason ). The reason may be the fact the gen_erate is a c++ application written before there was a c++ standard. At the time, ansi c would require declarations be at the start of a block, and c++ implementations often followed this rule. I can see no reason why this would need to be done this way.

[john-tornblom]

One problem with sharing variables with included files is that you might accidentally overwrite them. Another problem is that an include file could define a variable with of one type, which is later reassigned with a new value of a different type. However, pyrsl does not perform type checking on assignments, only invocations. The value is reassigned, just like in python.

In my opinion. the whole point with includes is to actually share a scope. Perhaps pyrsl could expose variables in the current scope as read-only for includes, and allow functions to be declared in the current scope. But that would be yet another compatibility issue. A similar behavior could be achieved by invoking a function that includes the file, then the call site should read the resulting body emitted by the function.