Recent

Author Topic: Inline If statement, i.e. IIF()?  (Read 3128 times)

Zoran

  • Hero Member
  • *****
  • Posts: 1840
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: Inline If statement, i.e. IIF()?
« Reply #15 on: May 21, 2024, 08:57:04 pm »
It's been more than eight years since PascalDragon implemented (in what was then trunk) and announced the IfThen intrinsic.
It was implemented so that only one of the two expressions gets evaluated, which cannot be done with a normal function.

Then other core developers didn't agree with it though. So it was removed from the fpc sources then.

See: https://lists.freepascal.org/pipermail/fpc-pascal/2016-January/046376.html


MarkMLl

  • Hero Member
  • *****
  • Posts: 6887
Re: Inline If statement, i.e. IIF()?
« Reply #16 on: May 22, 2024, 08:36:04 am »
I /thought/ I remembered that, and my sympathies are fully with Sven on this one: it's most unfortunate to have Pascal omit something which is standard in other ALGOL-derivatives.

I'm a bit troubled though: if the syntax "looks like a function", how is it possible to know that it's the "evaluate one but not both" wgich is being used rather than the "ordinary function" from strutils or maths?

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 14820
  • Censorship about opinions does not belong here.
Re: Inline If statement, i.e. IIF()?
« Reply #17 on: May 22, 2024, 07:34:34 pm »
It was implemented so that only one of the two expressions gets evaluated, which cannot be done with a normal function.
But my version is accepted a few years ago. With the provision that it is a generic and therefor does not adhere to boolean shortcut evaluation, although I wish it did. Anyway It is there.
bitrate is always calculated like this:sample rate * bitdepth * number of channels.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5541
  • Compiler Developer
Re: Inline If statement, i.e. IIF()?
« Reply #18 on: May 22, 2024, 09:28:29 pm »
It was implemented so that only one of the two expressions gets evaluated, which cannot be done with a normal function.
But my version is accepted a few years ago. With the provision that it is a generic and therefor does not adhere to boolean shortcut evaluation, although I wish it did. Anyway It is there.

It seems you don't have your terms right. Boolean shortcut evaluation is the case for the ordinary IfThen as well, because it only applies to the condition, just like in the if-statement. What is the important difference is whether the branches are both evaluated or only the one selected by the condition.

Code: Pascal  [Select][+][-]
  1. program tifthen;
  2.  
  3. {$mode objfpc}
  4.  
  5. uses
  6.   SysUtils;
  7.  
  8. type
  9.   TTest = class
  10.     f: LongInt;
  11.   end;
  12.  
  13. var
  14.   t: TTest;
  15.  
  16. procedure DoTest;
  17. begin
  18.   { with $B+ this would crash if t is Nil }
  19.   Writeln(specialize IfThen<LongInt>(Assigned(t) and (t.f = 42), 1, 2));
  20. end;
  21.  
  22. begin
  23.   t := Nil;
  24.   DoTest;
  25.   t := TTest.Create;
  26.   DoTest;
  27.   t.f := 42;
  28.   DoTest;
  29. end.

I'm a bit troubled though: if the syntax "looks like a function", how is it possible to know that it's the "evaluate one but not both" wgich is being used rather than the "ordinary function" from strutils or maths?

If I'd do it again I'd just go with a ifthenelse-expression. 🤷‍♀️

MarkMLl

  • Hero Member
  • *****
  • Posts: 6887
Re: Inline If statement, i.e. IIF()?
« Reply #19 on: May 23, 2024, 08:42:27 am »
I'm a bit troubled though: if the syntax "looks like a function", how is it possible to know that it's the "evaluate one but not both" wgich is being used rather than the "ordinary function" from strutils or maths?

If I'd do it again I'd just go with a ifthenelse-expression. 🤷‍♀️

Which was of course the ALGOL way. In the general case (i.e. including later ALGOL derivatives), I've been troubled by that lacking an explicit end. However since it can't- by definition- omit the else I think that in terms of language consistency this is a a very minor sin.

Quote
But my version is accepted a few years ago. With the provision that it is a generic and therefor does not adhere to boolean shortcut evaluation, although I wish it did. Anyway It is there.

It seems you don't have your terms right. Boolean shortcut evaluation is the case for the ordinary IfThen as well, because it only applies to the condition, just like in the if-statement. What is the important difference is whether the branches are both evaluated or only the one selected by the condition.

That's something I tried to emphasise earlier in the thread. Many details are lost in the mists of time, but I've seen stuff which implied that- in effect- ALGOL expanded a complex boolean expression into a cascade of if-then-else statements, i.e. it was distinct from the sort of optimisation which would shortcircuit e.g. a := 0 * something();. But the concept of types in ALGOL-60 was very immature, I can't even remember without looking for documentation whether there was a boolean variable type per se or if types were merely there to distinguish between integers and floats.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 5541
  • Compiler Developer
Re: Inline If statement, i.e. IIF()?
« Reply #20 on: May 26, 2024, 10:07:04 pm »
I'm a bit troubled though: if the syntax "looks like a function", how is it possible to know that it's the "evaluate one but not both" wgich is being used rather than the "ordinary function" from strutils or maths?

If I'd do it again I'd just go with a ifthenelse-expression. 🤷‍♀️

Which was of course the ALGOL way. In the general case (i.e. including later ALGOL derivatives), I've been troubled by that lacking an explicit end. However since it can't- by definition- omit the else I think that in terms of language consistency this is a a very minor sin.

That is my opinion as well that the “dangling else” problem isn't as problematic with the if-expression compared to the if-statement.

 

TinyPortal © 2005-2018