Q about new IfThen() intrinsic

[FTurtle]

skalogryz, Martin_fr, thanks.

[Zoran]

An argument for IIF:

In this mail: http://lists.freepascal.org/pipermail/fpc-pascal/2016-February/046444.html Maciej argues that IIF should not be used because in other languages it is implemented as a function which evaluates both branches.

Actually, not in all languages. It is defined so in VisualBasic. However, in Firebird it does what we need, it is implemented as (see here):

IIF(Cond, Result1, Result2) is a shortcut for “CASE WHEN Cond THEN Result1 ELSE Result2 END”. You can also compare IIF to the ternary “? :” operator in C-like languages.

So, it behaves just as our new intrinsic.

[FTurtle]

By the way, good name for new intrinsic: IfThenGet

Code: Pascal  [Select][+][-]

1. x := IfThenGet(c, a, b);

[skalogryz]

Put the patch on hold, until the language is ready for it

until the language is ready - I do not understand when and how do you think the language can become more ready for this feature?

Recently generic were implemented for functions. That pretty much opened the door to implementing the IfThen() via regular language feature rather than a compiler intrinsic. Though there were an issue Silvio ran into. (Note: reporting the issue actually inspired compiler - intrinsic solution).
Another potentially possible approach is to have an inline function modifier to be evaluated on the first use, rather than prior to the call (as it is done right now). It would make inline functions to act similar to achieve the same functionality. However, implementing such argument modifier could be really tricky.
...who knows what other language features could be introduced, that would help to implement IfThen()

I hope that we will see it in FPC as soon as possible, that is in the next release.

Does it actually prevents you from completing your project?

[Zoran]

Recently generic were implemented for functions. That pretty much opened the door to implementing the IfThen() via regular language feature rather than a compiler intrinsic. Though there were an issue Silvio ran into. (Note: reporting the issue actually inspired compiler - intrinsic solution).
Another potentially possible approach is to have an inline function modifier to be evaluated on the first use, rather than prior to the call (as it is done right now). It would make inline functions to act similar to achieve the same functionality. However, implementing such argument modifier could be really tricky.
...who knows what other language features could be introduced, that would help to implement IfThen()

We have a nice solution which can be included now. Why would we wait for other ways of implementing this? Why do you think that intrinsic solution should be avoided?

I hope that we will see it in FPC as soon as possible, that is in the next release.

Does it actually prevents you from completing your project?

Of course I can use good old if-then-else construct, but I would like to be able to use this nice new syntax.

[frakno]

I do not understand the excitement. I use the following easy function, and I think that is meant by this discussion

Code: Pascal  [Select][+][-]

1. function IfFork( Decision  :Boolean; YesInt  :Integer; NoInt  :Integer = 0 )  :Integer;
2.   begin
3.       if Decision then Result := YesInt else Result := NoInt;
4.   end;
5.  
6. function IfFork( Decision  :Boolean; YesStr  :String; NoString  :String = '' )  :String;
7.   begin
8.       if Decision then Result := YesStr else Result := NoString;
9.   end;
10.  
11. ...
12.  

And the usage:

Code: Pascal  [Select][+][-]

1. AString := IfFork(  SortType.ItemIndex = 0, 'ASC', 'DESC' );  

so why the big discussion about a built-in version
                         

[skalogryz]

I do not understand the excitement. I use the following easy function, and I think that is meant by this discussion

Code: Pascal  [Select][+][-]

1. function IfFork( Decision  :Boolean; YesInt  :Integer; NoInt  :Integer = 0 )  :Integer;
2.   begin
3.       if Decision then Result := YesInt else Result := NoInt;
4.   end;
5.  

         

You do understand that the following code

Code: [Select]

  b := true;
  a := IFFork (b, 5 + 5, 3-2);
does a useless job of calculating 3-2, since only 5+5 should be evaluated?

For example, this code

Code: [Select]

  b := true;
  if b then
    a := 5+5
  else
    a:= 3-2;
doesn't have such deficiency.

The all excitement is about having IfFork() that would be as effective as a plain if-statement.

[frakno]

Sorry, I cant see a big difference

the solution from unit math !!! is

Code: Pascal  [Select][+][-]

1. function ifthen(val:boolean;const iftrue:integer; const iffalse:integer= 0) :integer;
2. begin
3.   if val then result:=iftrue else result:=iffalse;
4. end;

and my old solution is

Code: Pascal  [Select][+][-]

1. function IfFork( Decision  :Boolean; YesInt  :Integer; NoInt  :Integer = 0 )  :Integer;
2.   begin
3.       if Decision then Result := YesInt else Result := NoInt;
4.   end;

sure would be better:   IfFork( Decision  :Boolean; const YesInt  :Integer; const NoInt  :Integer = 0 )  :Integer;

and because of overloading this with a string and ...-versions  in my unit my solution is much more universal
because the ifthen solution in the math unit is limited to integer, int64 and double results

but as a german idiom says: preferences and savours are thankfully different

[BeniBela]

Yup. There are too much such constructs in Free Pascal already. That is why I started the MSElang initiative.

No there are not enough!

Sorry, I cant see a big difference

The point is, with an intrinsic you can write

Code: [Select]

x := ifthen(obj <> nil, obj.foobar, '');


You cannot do that with the old version



Although it would be much clearer as

Code: [Select]

x := if obj <> nil then obj.foobar else '';


[skalogryz]

Sorry, I cant see a big difference

let's have some practice, then!

1) try this code.

Code: [Select]

{$mode objfpc}
{$assertions on}
uses SysUtils;
var
  a,b : integer;
begin
  a:=4;
  b:=0;
  assert(b =0, 'the result if of division is '+IntToStr(a div b));
  writeln('b is zero!');
end.
Does it fail?

2) Now, lets change it a little bit and try again.

Code: [Select]

{$mode objfpc}
{$assertions on}
uses SysUtils;

procedure myassert(cond : boolean; const msg: string); inline;
begin
   if not cond then begin
     writeln(msg);
     halt;
   end;
end;

var
  a,b : integer;
begin
  a:=4;
  b:=0;
  myassert(b =0, 'the result if of division is '+IntToStr(a div b));
  writeln('b is zero!');
end.
Does it  fail? if yes, what's the error message?

[frakno]

BeniBela

Code: [Select]
x := ifthen(obj <> nil, obj.foobar, '');


You cannot do that with the old version

Yeah, that's a difference i can see

[BeniBela]

OMG, they lost their minds: 

http://lists.freepascal.org/fpc-pascal/2016-February/046616.html

 

[skalogryz]

http://lists.freepascal.org/fpc-pascal/2016-February/046616.html

For the best, imho!
(Syntax) Sugar diet is not healthy.

[Zoran]

Bad news... 

[guest58172]

In the NewsGroup topic there are interesting solutions proposed to implement a Pascal-ish ternary operator (instead of the intrasic). But the problem is clear: precedence:

Code: Pascal  [Select][+][-]

1. a :=  c > d then e else f;

Which is, I believe a problem in the grammar, since the rules have to be changed, because c > d already returns a boolean that might be assignable. In C like languages it's a bit different because expressions that evaluates to bool are surrounded with parens.

with the Q mark

Code: Pascal  [Select][+][-]

1. a ?:=  c > d then e else f;

Code: Pascal  [Select][+][-]

1. a ?+=  c > d then e else f;

Code: Pascal  [Select][+][-]

1. a ?-=  c > d then e else f;

top down parsing works.

Introducing the Q mark is not a bad idea, soon or later you'll implement coalesce...