Code interpreted wrongly?

[Felix Pöge]

Dear Statalist,

I am having a problem with the following code. Please understand that it is schematic and I am using it this way, but with more content, in my program.
The problem is in the second part, it throws the error "} is not a valid command name" after printing "After capture 2", which it absolutely should not. It works when I replace $DEBUG_QUIET with noisily or quietly, but I would like to not do that.
I am working with Stata 14.0.

Thanks a lot,
Felix

// Just show that this concept generally works
global DEBUG_QUIET quietly
$DEBUG_QUIET di "test quiet"

global DEBUG_QUIET noisily
$DEBUG_QUIET di "test noise"

// Show that it works with 1
if 1 {
    capture $DEBUG_QUIET {
            di as error "Inside 1"
    }
    di "After capture 1"
}

di "Now we are here 1"

// Show that it does not work with 0
if 0 {
    capture $DEBUG_QUIET {
            di as error "Inside 2"
    }
    di "After capture 2"
}

di "Now we are here 2"

[Jorge Eduardo Perez Perez]

Very tricky, all I can do is confirm this behavior in Stata 13.

[daniel klein]

The example can be simplified to

local noisily noisily

if (0) {
    `noisily' {
        display "this should not be displayed"
    }
    display "neither should this be displayed"
}

and I would send this to tech-support.

Note that the same does not happen if we instead type

local noisily noisily

if (0) {
    `noisily' display "this should not be displayed"
    display "neither should this be displayed"
}

omitting the intermediate pair of braces, or

if (0) {
    noisily {
        display "this should not be displayed"
    }
    display "neither should this be displayed"
}

omitting local evaluation.

By the way, I ran this in Stata 12.1 on a Win7 machine.

Best
Daniel

[Attaullah Shah]

Daniel I recieved this error for your first codel

unrecognized command:  } invalid command name

[Felix Pöge]

Yeah, this is the behavior we are seeing but it should not happen, from a conceptual point of view.

I have sent an eMail to the tech-support and will get back to you in case there is an interesting result. Thank you all so far!

[daniel klein]

Yes, you are supposed to. That is one part (or consequence) of the problem outlined here. The other is, that the line "neither should this be displayed" is actually displayed.

It seems Stata interprets the first closing brace as the one matching the opening brace after the if statement, when it is actually supposed to match the second opening brace, i.e. the one following `noisily'. Omitting the last closing brace prevents the error message, but does, of course, not solve the underlying problem. This is easily demonstrated by the fact that the line that should not be displayed is still displayed. Also, there should now actually be an error message, because the braces are not balanced in the code below

local noisily noisily

if (0) {
    `noisily' {
        display "this should not be displayed"
    }
    display "neither should this be displayed"

Again, I would send this to tech-support.

Best
Daniel

[Felix Pöge]

Just to let you all know what came out:

In order for Stata to run as quickly as it can, the Stata parsing logic does not expand macros in blocks of code that are not supposed to be run. In your example, the zero in the IF expression means the block is not supposed to be run, so in this case Stata is looping over the lines of the IF block to find its end. But it does so without interpreting the lines of code within the block or doing any macro expansion. Therefore, Stata cannot recognize the noisily block's opening brace because the noisily macro was never expanded, but it does find the noisily blocks closing brace, and this leads to it erroring out when it finds the IF block's closing brace.

If Stata's parsing logic were to parse and macro expand every line of code within blocks that shouldn't be run, then this would slow down execution of the code and increase run times.

(Thanks to Peter Fuschich from StataCorp's Technical Department)

Cheers,
Felix