I have a possible fix/solution now, by setting the 'ithen' flag in
getoptxt() after parsing a new expression (i.e. calling express()),
depending on the type of the output of the expression ('b' or not),
if the 'ithen' flag is negative in the current IFLABEL. The negative
'ithen' is set on finding a 'then' in splitline(), and the first
expression that is parsed after that is the conditional test of the
if/then statement. This is somewhat hackish and needs testing, but
it does allow for replacing the kgoto with a goto if an i-rate
conditional is used for if/then.

On Monday 06 February 2006 13:25, Istvan Varga wrote:

> Here is a more detailed explanation why the 'else' branch is always
> run at i-time. The following orchestra code:
> 
>     if (cond) then
>     ...
>     else
>     ...
>     endif
> 
> is internally translated to something like:
> 
>     cngoto (cond), _else
>     ...
>     kgoto _endif
> _else:
>     ...
> _endif:
> 
> 'cngoto' is an opcode that jumps to the specified label if 'cond' is
> not true; if the conditional is valid at i-time, it is evaluated both
> at init and perf time, while if it is considered a "k-rate" conditional,
> 'cngoto' is a no-op at init time.
> So, with an i-rate conditional, the 'else' branch is always run at i-time
> because the 'kgoto' falls through to it. With a k-rate conditional, both
> branches are always run at i-time because 'cngoto' falls through as well.
> 
> Now the question is why is a 'kgoto' used to skip the else branch ?
> It is obvious that if the conditional is "k-rate" then initializing the
> else stuff is always needed, but why is it not replaced with a 'goto'
> if the conditional is "i-rate" ? Well, at the point in time when the
> 'else' is replaced with the kgoto/label pair, the parser does not know
> the type of the conditional expression, as the if/then/else expansion is
> done in splitline(), while the (cond) expression is parsed by express()
> which does not know about the context where a particular expression is
> used. This is also the reason why 'cngoto' determines the type of the
> conditional at run-time and not at compile time. However, to have run-time
> checks in else as well, it should somehow know the type of an argument of
> an opcode elsewhere in the orchestra. Either way, the solution might be
> non-trivial.
> 
> 'ithen' is basically a hack to allow for i-time only conditionals.
> It replaces the cngoto with a cogoto, and kgoto with a goto. However,
> for some reason cogoto always jumps at performance time, so it will
> then always take the 'else' branch and never the 'if'.
> 
> On Monday 06 February 2006 11:32, Istvan Varga wrote:
> 
> > On Monday 06 February 2006 09:39, Matt J. Ingalls wrote:
> > 
> > > it looks like there might be  a bug in csound 5.  the csound4 output looks 
> > > right.
> > 
> > No, it does not. If you look more carefully, you will notice that in the
> > Csound 4 output, the 'if' and 'elseif' branches are always executed, while
> > the 'else' ones are never, regardless of the value of p4. Also, the report
> > was done with an old version of Csound 4. With the latest 4.23 sources from
> > CVS, its output is exactly identical to that of version 5.
> > In fact, the current if/then/else code in Csound 5 is synchronized with
> > your most recent changes to 4.23, and it is since then that the 'else'
> > branch is always executed at i-time. 'ithen' was also added by you,
> > apparently to work around this limitation.
> > 
> > > if i remember right, p-variables are treated as k-rate variables in  
> > > conditionals.
> > 
> > No, they are i-rate conditionals. If you compile with -v, you should notice
> > that the temporary boolean variables are of type 'b' and not 'B' (but maybe
> > not in older versions).