Q about new IfThen() intrinsic

[guest58172]

Hello, i've just read this:

http://lists.freepascal.org/pipermail/fpc-pascal/2016-January/046375.html

which basically announces that something like C ternary expressions is implemented in FPC trunk.

Will it work with += and -=, when C-like operators are activated ?

[Thaddy]

What is that a F*...
Just try... You are a grown up boy.

[FTurtle]

See options:
Project Options | Compiler Options | Parsing

[guest58172]

What is that a F*...
Just try... You are a grown up boy.

Calm down man, or take your little pills, It's just a question

[Zoran]

What is that a F*...
Just try... You are a grown up boy.

He can just ask questions, this is a very interesting new language feature.
I believe that for talking about new beautiful feature, we are not required to install FPC from trunk.

[FTurtle]

Sorry, first I wrong read and understood your question.

Since it's declared in the System unit it won't interfere with the
IfThen()s that are declared in the Math unit or other units, so they'll
continue to work as before to avoid any surprises.

So, now already available IfThen in few modules.

Write:

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

1. uses math, strutils;

and use them.

As far I understand Sven said about other feature.
It also will function (in System) and work similar.
I think C-like operators can not affect the ability to work of IfThen, because they are just another way of representation of the same things.
At least IfThen from strutils works with +=

Just for fun:

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

1. procedure TForm1.Button2Click(Sender: TObject);
2. var
3.   a: Integer;
4.   s: String;
5. begin
6.   a := StrToInt(Edit2.Text);  // initial value is 2
7.   s := Edit3.Text;
8.  
9.   a *= 2;
10.   s += Format('(%d%s25) ', [a, IfThen(a>25, '>', '<=')] );
11.  
12.   Edit2.Text := IntToStr(a);
13.   Edit3.Text := s;
14. end;
15.  

Output to Edit3:

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

1. (4<=25) (8<=25) (16<=25) (32>25) (64>25)
2.  

[BeniBela]

Good thing I just installed fpc trunk.

Seems to work nicely

BUT

Code: [Select]

uses math;
ifthen(true, a,b )

evaluates both branches

What is planned for that?

It is quite unfortunately named, if it gets overriden by the math functions

[Blaazen]

You didn't read the discussion on ML properly (no wonder, it's a few hundred posts  ). Sven Barth already promised renaming to avoid confusion with Math.IfThen.

[FTurtle]

Good thing I just installed fpc trunk.

Functions from math and strutils work in 3.0.0 (may be earlier), so, you could use existing installation of Lazarus 1.6 RC2 if it is.

BUT

Code: [Select]

uses math;
ifthen(true, a,b )

evaluates both branches

This is a fee for convenience. IfThen does not replace usual if, but it can be very useful in some cases, like in my example.

It is quite unfortunately named, if it gets overriden by the math functions

Why? First, the compiler will attempt to use functions from modules connected via Uses and if not found suitable, will use the new feature. As far as I understand, the main difference between them is:

function IfThen(Condition: Boolean; ThenExpr, ElseExpr: type): type;
...
An important point to note is that in general the result type is
determined by the ThenExpr (there are a few usability exceptions
regarding strings and chars).

[bee]

Oh God… not again! We already have had hundreds of email about this on the list.

[skalogryz]

Oh God… not again! We already have had hundreds of email about this on the list.

Indeed. This is how a technical non-problem turns into a political dispute.

The proposed IfThen() aka iif() aka iff() aka IfThenElse() intrinsic is supposed to act differently, than existing Math.IfThen. The key difference, is that only one of the expressions is evaluated, based on the value of condition. If condition is true, only "then" expression is evaluated (and returned), if condition is false, only "else" expression is evaluated.

But here comes the problem:
The intrinsic looks like a function, but acts differently. In case of a function all arguments are evaluated prior to the function call. That might cause confusion, even though there're already intrinsic that're acting in a similar manner, i.e. assert().

Logically, it's better to have as less exceptions as possible, that's why it is desirable not to add another exception into RTL.

So, in the thread another proposal came up - let's have if..then as an expression. That would make if..then an operator. With implementing this, a code like

Code: [Select]

  x:=if a then b else c;
would be possible. It might look nice, but ...

whenever a new operator is introduced, it must have a defined precedence. For example, what the value of x would be:

Code: [Select]

  x:=if true then 5 else 3 + 4;
should it be resolved as:

Code: [Select]

  x:=(if true then 5 else 3) + 4;
or

Code: [Select]

  x:=(if true then 5 else (3 + 4));
If using intrinsic, is really not a problem, since function call (which it looks like) takes the higher precedence:

Code: [Select]

  x:=IfThen(true, 5, 3)+4;
So defining the right precedence is critical to usability of an operator, since it might be a source for potential bugs.
But adding a new operator with its precedence opens a big can worm.
First of all, it breaks Pascal fundamental simplicity.
Pascal has only 4 (or 5 levels) of precedence.
Compare it to C with 18 or even Algol with 12 levels.
More levels, the harder expressions are to be understood and read.
Secondly, it also creates precedent of extending the language with a new operator, so more operators could be added (case-expression... and so on). More operators -> greater complexity.
Thirdly, potentially one might start asking about overloading these new operators, bringing even more complexity.

Another point was made, that neither Ifthen() intrinsic nor if-expression solves any technical problems.
What they do could be achieved by using if-statement. So they're nothing more but a syntax sugar (not very welcomed, in general, that is intended to make the development a little bit easier (less typing, easier to port C-like language  code)

There's a saying: the road to hell is paved with good intentions. Is this case the sample of the saying?

What makes it all hard (over 200 emails of the mailing list), is that the patch has already been provided, it's very easy to accept it technically.
The optimal solution might be - not to do anything. Put the patch on hold, until the language is ready for it or until Delphi implements it also. (I wonder if Delphi developers had the same problem and decided not to add it to the language)

thanks for reading, btw!

[Martin_fr]

But here comes the problem:
The intrinsic looks like a function, but acts differently. In case of a function all arguments are evaluated prior to the function call. That might cause confusion, even though there're already intrinsic that're acting in a similar manner, i.e. assert().

Logically, it's better to have as less exceptions as possible, that's why it is desirable not to add another exception into RTL.

So, in the thread another proposal came up - let's have if..then as an expression. That would make if..then an operator. With implementing this, a code like

Code: [Select]

  x:=if a then b else c;
would be possible. It might look nice, but ...

whenever a new operator is introduced, it must have a defined precedence. For example, what the value of x would be:

There is also a point missing:

* IfThen() looks like a function, but is not. True.

But
* x:=if a then b else c;  the right hand site expression, looks like a statement, but isn't.

So in that, they both have the same problem, they are not what they look like.

Furthermore, if I understand the patch for the ":= if then else" correct (and I might not), then it is not actually implemented as operator.

The parser still parses the same "if" as before. All other operators are known as operator in the parser, and translated as such. There also is no entry in the operator precedence table. There simple is code that detects the "if" token, if in place of an operand.

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

1. program Project1;
2. {$mode objfpc}
3.  
4. const a = 1 + 2;    // + is an operator, this works
5. //const a = ifthen(true, 1,2);  // this does not work
6. //const a = if true then 1 else 2;  // and this (despite it should be an operator) does not work either
7.  
8. begin
9.   writeln(a);
10.   readln;
11. end.
12.  

[guest58172]

Hello, i've just read this:

http://lists.freepascal.org/pipermail/fpc-pascal/2016-January/046375.html

which basically announces that something like C ternary expressions is implemented in FPC trunk.

Will it work with += and -=, when C-like operators are activated ?

I just wanted to know if it was really comparable to the ternary operator:

Code: D  [Select][+][-]

1. void main()
2. {
3.     int a,b,c,d;
4.     a = (b == 0) ? c : d;       // a := IfThen(b=0,c,d);
5.     a += (b == 0) ? c : d;      // a += IfThen(b=0,c,d);
6. }

[mse]

What makes it all hard (over 200 emails of the mailing list), is that the patch has already been provided, it's very easy to accept it technically.
The optimal solution might be - not to do anything. Put the patch on hold, until the language is ready for it or until Delphi implements it also. (I wonder if Delphi developers had the same problem and decided not to add it to the language)

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

[Zoran]

Thank you, Bart, for this feature!

The optimal solution might be - not to do anything.

Oh, no... we came so close to have this nice language feature just to see that it might not get inculded...

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? As time passes, I do not see what can happen to ease these problems with function implemented in strutils and math -- they will still be there and behave like functions behave, always evaluate both branches and make side effects.

I hope that we will see it in FPC as soon as possible, that is in the next release.
Of course, it is a matter of taste. I feel free to talk about it here now. I don't use IfThen functions implemented in strutils and math, but the intrinsic in system unit is something I would use a lot. The name can be changed, but even that is not really necessary (Yes I read the discussion on mailing list, and this is still my opinion).

or until Delphi implements it also. (I wonder if Delphi developers had the same problem and decided not to add it to the language)

Please do not wait for Delphi. Let's not care about Delphi for once. And if Delphi doesn't implement it, we do not lose compatibility with Delphi code. Only the other way is lost -- FPC code with this cannot be ported to Delphi, but let them care about this.