<p>Am 02.02.2016 11:42 schrieb "Mark Morgan Lloyd" <<a href="mailto:markMLl.fpc-pascal@telemetry.co.uk">markMLl.fpc-pascal@telemetry.co.uk</a>>:<br>
><br>
> Michael Van Canneyt wrote:<br>
><br>
>> Call me old fashioned, but then I think<br>
>>   foo:=iif(Condition1,<br>
>>            iif(Condition2, ThenExpr1, ElseExpr1),<br>
>>            iif(Condition3, ThenExpr2, ElseExpr2));<br>
>> is more clear.<br>
>><br>
>> The "if then" construct is really confusing.<br>
>> "if then" is a statement, not an expression.<br>
><br>
><br>
> Yes, and that's why to get the desired semantics it's more appropriate to use  if then else  rather than  iif()  etc.<br>
><br>
> Please correct me if I'm wrong, but my understanding is that in all cases where parameters are passed to a procedure or function they are evaluated and placed on the stack before the code is called. However the  if then else  statement never, under any circumstances, executes code in the untaken statement/block, and it is that which is the required behaviour for an "inline if" expression.<br>
><br>
> If we want to organise it so that FPC can only evaluate function parameters when required, then it is necessary to implement ALGOL-60's "call by name" semantics, which were universally agreed to be deeply messy and perhaps not even what the standard authors intended.</p>
<p>Compiler intrinsics are not necessarily subject to these rules. Take for example Assert: the string parameter whig can contain function calls is only evaluated if assertions are active at all and the condition is false.<br>
Same with the IfThen-intrinsic I had added, it only evalutes the branch that is taken.<br>
Please note that intrinsics are the exception, not the rule.</p>
<p>Regards,<br>
Sven</p>