Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2016-01

New feature: IfThen() intrinsic

120 messages · 30 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Sven Barth

Hello together!

I've finally come around to add a feature that many people have asked for throughout the years: an inline if that works like the if-statement in that it only evaluates that expression that is indeed returned.

After the discussion last year about the inline-if I've decided to add it as an intrinsic function instead of an extension of the language. Like all intrinsics it's part of the System unit and "declared" like this:

=== code begin ===

function IfThen(Condition: Boolean; ThenExpr, ElseExpr: type): type;

=== code end ===

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.

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).

Examples:

=== code begin ===

function A: LongInt;
begin
  A := 42;
end;
function B: LongInt;
  B := 21;
end;
var
  i, j: LongInt;
  s: String;
begin
  i := 42;
  j ;= IfThen(i < 32, 48, 21);
  j := IfThen(True, 23, 49); // compiler will warn of unreachable code
  j := IfThen(False, 23, 49); // compiler will warn of unreachable code
  j := IfThen(i < 32, A, B); // in this case only B will be executed
  //j := IfThen(i < 32, 32, '123'); // this will fail if there's no
suitable conversion operator available
  //s := IfThen(j < 32, #42, 'Foo'); // this will fail as a char is expected
  s := IfThen(j < 32, #42, #3294); // this will work however and will
result in a WideChar
  s := IfThen(j < 32, 'Hello World', 'Hello'#3294'World'); // this will
also work and will result in a WideString (and a warning as s is a
Short-/AnsiString)
end;

=== code end ===

If there are any combinations of types that should work, but do not, please don't hesistate to report them at http://bugs.freepascal.org/

Regards,
Sven

Reply by email

Mark Morgan Lloyd
to Sven Barth
Sven Barth wrote 8 lines
Hello together! I've finally come around to add a feature that many people have asked for throughout the years: an inline if that works like the if-statement in that it only evaluates that expression that is indeed returned. After the discussion last year about the inline-if I've decided to add it as an intrinsic function instead of an extension of the language.

Thanks for that, it will make maintaining some Pascal transcribed from Javascript much easier.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

silvioprog
to Sven Barth: Hello together! I've finally come around to add a feature that many people have asked for…
Sven Barth wrote 66 lines
Hello together! I've finally come around to add a feature that many people have asked for throughout the years: an inline if that works like the if-statement in that it only evaluates that expression that is indeed returned. After the discussion last year about the inline-if I've decided to add it as an intrinsic function instead of an extension of the language. Like all intrinsics it's part of the System unit and "declared" like this: === code begin === function IfThen(Condition: Boolean; ThenExpr, ElseExpr: type): type; === code end === 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. 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). Examples: === code begin === function A: LongInt; begin A := 42; end; function B: LongInt; B := 21; end; var i, j: LongInt; s: String; begin i := 42; j ;= IfThen(i < 32, 48, 21); j := IfThen(True, 23, 49); // compiler will warn of unreachable code j := IfThen(False, 23, 49); // compiler will warn of unreachable code j := IfThen(i < 32, A, B); // in this case only B will be executed //j := IfThen(i < 32, 32, '123'); // this will fail if there's no suitable conversion operator available //s := IfThen(j < 32, #42, 'Foo'); // this will fail as a char is expected s := IfThen(j < 32, #42, #3294); // this will work however and will result in a WideChar s := IfThen(j < 32, 'Hello World', 'Hello'#3294'World'); // this will also work and will result in a WideString (and a warning as s is a Short-/AnsiString) end; === code end === If there are any combinations of types that should work, but do not, please don't hesistate to report them at http://bugs.freepascal.org/

Wooow! I did a request about it many years ago, however it was rejected because the limitation in the generic feature at that time.

So, I posted a bug related to it yesterday:

http://bugs.freepascal.org/view.php?id=29546

Can I use it after this new feature? (I'm upgrading my FPC sources now :-) )

Buddy, thanks a lot for that feature, it is very useful! o/

Silvio Clécio

Reply by email

Vojtěch Čihák
to Sven Barth: Hello together! I've finally come around to add a feature that many people have asked for…

Hi,
 
what is difference in produced assembler between ifthen(); and classic if - then - else?

Thanks, V.
______________________________________________________________

Show quoted text 5 lines
Od: Sven Barth Komu: "FPC-Pascal users discussions" Datum: 31.01.2016 15:43 Předmět: [fpc-pascal] New feature: IfThen() intrinsic

Hello together!

I've finally come around to add a feature that many people have asked for throughout the years: an inline if that works like the if-statement in that it only evaluates that expression that is indeed returned.

After the discussion last year about the inline-if I've decided to add it as an intrinsic function instead of an extension of the language. Like all intrinsics it's part of the System unit and "declared" like this:

Regards,
Sven

Reply by email

Sven Barth
to Vojtěch Čihák
Vojtěch Čihák wrote
what is difference in produced assembler between ifthen(); and classic if - then - else?

=== code begin ===

i := IfThen(x < 42, 32, 49);

=== code end ===

is equivalent to

=== code begin ===

if x < 42 then
  i := 32
else
  i := 49;

=== code end ===

That's in fact how the compiler handles this internally (with the added benefit of nesting IfThen()s).

Regards,
Sven

Reply by email

Sven Barth
to silvioprog: On Sun, Jan 31, 2016 at 11:43 AM, Sven Barth Wooow! I did a request about it many years…
silvioprog wrote
Wooow! I did a request about it many years ago, however it was rejected because the limitation in the generic feature at that time.

This implementation has nothing to do with generics. It's a compiler magic function, just like Writeln() and thus it can bend the usual rules ;)

So, I posted a bug related to it yesterday: http://bugs.freepascal.org/view.php?id=29546

I've seen your bug this night and that was the cause for finally implementing this.

Can I use it after this new feature? (I'm upgrading my FPC sources now :-) )

I've not yet looked at what the problem regarding your code is. However you can simply remove your TUtils.Iif() and use IfThen() instead.

Buddy, thanks a lot for that feature, it is very useful! o/

That's what I have hoped for. :)

Regards,
Sven

Reply by email

silvioprog
to Sven Barth
Sven Barth wrote 6 lines
On 31.01.2016 16:09, silvioprog wrote: > Wooow! I did a request about it many years ago, however it was rejected > because the limitation in the generic feature at that time. This implementation has nothing to do with generics. It's a compiler magic function, just like Writeln() and thus it can bend the usual rules ;)

Awesome.

So, I posted a bug related to it yesterday: > > http://bugs.freepascal.org/view.php?id=29546

I have a test-case in a draft project that worked fine some days ago, so I think that this bug was introduced recently. o_O

I've seen your bug this night and that was the cause for finally

implementing this.

2^64 thanks! :-)

Show quoted text 5 lines
Can I use it after this new feature? (I'm upgrading my FPC sources now :-) ) I've not yet looked at what the problem regarding your code is. However you can simply remove your TUtils.Iif() and use IfThen() instead.

YES! o/ .. \o .. \o/

I'm going to do it now ... :-D

Buddy, thanks a lot for that feature, it is very useful! o/ That's what I have hoped for. :)

^^

Silvio Clécio

Reply by email

silvioprog
to Sven Barth: Hello together! I've finally come around to add a feature that many people have asked for…
Sven Barth wrote 16 lines
Hello together! I've finally come around to add a feature that many people have asked for throughout the years: an inline if that works like the if-statement in that it only evaluates that expression that is indeed returned. After the discussion last year about the inline-if I've decided to add it as an intrinsic function instead of an extension of the language. Like all intrinsics it's part of the System unit and "declared" like this: === code begin === function IfThen(Condition: Boolean; ThenExpr, ElseExpr: type): type; === code end ===

[...]

If there are any combinations of types that should work, but do not, please don't hesistate to report them at http://bugs.freepascal.org/

First issue sent to: http://bugs.freepascal.org/view.php?id=29554. :-)

Silvio Clécio

Reply by email

Stephen Chrzanowski
to Ralf Quint

Mostly code readability, but, I've been writing my own functions to do that kind of thing for years. Same with the BETWEEN function.

Ralf Quint wrote 25 lines
On 1/31/2016 7:14 AM, Vojtěch Čihák wrote: > > Hi, > > what is difference in produced assembler between ifthen(); and classic if > - then - else? > > > +1 I don't really see how this is different from properly writing if ... then ... else... either... :-\ Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply by email

Marco van de Voort
to Sven Barth: Hello together! I've finally come around to add a feature that many people have asked for…

In our previous episode, Sven Barth said:

Show quoted text 17 lines
After the discussion last year about the inline-if I've decided to add it as an intrinsic function instead of an extension of the language. Like all intrinsics it's part of the System unit and "declared" like this: === code begin === function IfThen(Condition: Boolean; ThenExpr, ElseExpr: type): type; === code end === 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. 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).

I'm not really fond of the functionality, and I would not write new code with it, but it is very handy when converting C code.

The only really bad thing is the name, as Florian already said, with the versions in strutils and math. The clash with delphi compatible functions should be avoided.

Reply by email

Maciej Izak
to Marco van de Voort

2016-02-01 8:59 GMT+01:00 Marco van de Voort :

The only really bad thing is the name, as Florian already said, with the versions in strutils and math. The clash with delphi compatible functions should be avoided.

+1 . IfThen instricit is IMO very bad idea. I have a lot of "IfThen" from math and strutils modules.

IfThen from System totally breaks the compatibility :\ . C'mon Sven. In one field you're rigorously but in something like this you're liberal (braking/dangerous change / for existing code base).

If i understand correctly "ThenExpr" is executed only when "Condition" is true and "ElseExpr" is executed only when "Condition" is false. For standard "IfThen" from Math and StrUtils "ThenExpr" and "ElseExpr" is executed before IfThen is called.

for me different syntax for System.IfThen is required (fpIfThen ? or http://docs.elementscompiler.com/Oxygene/Expressions/If/ ).

Best regards, Maciej Izak

Reply by email

leledumbo
to Maciej Izak
If i understand correctly "ThenExpr" is executed only when "Condition" is

true and "ElseExpr" is executed only when "Condition" is false. For standard "IfThen" from Math and StrUtils "ThenExpr" and "ElseExpr" is executed before IfThen is called.

This is one thing that becomes my concern as expected side effect might not be triggered due to semantic differences, although I seldom use IfThen from either math/strutils (not lazy enough to write complete `if ... then begin ... end else begin ... end` for the sake of easy future modification).

View this message in context: http://free-pascal-general.1045716.n5.nabble.com/New-feature-IfThen-intrinsic-tp5723735p5723748.html Sent from the Free Pascal - General mailing list .

Reply by email

David Butler

This is usually called "inline if".

Maybe call it "inlineif" or "iif", e..g

x := iif (a < 3, 1, 2)

or even

x := iif a < 3 then 1 else 2;
Maciej Izak wrote 22 lines
2016-02-01 8:59 GMT+01:00 Marco van de Voort : > The only really bad thing is the name, as Florian already said, with the > versions in strutils and math. The clash with delphi compatible functions > should be avoided. +1 . IfThen instricit is IMO very bad idea. I have a lot of "IfThen" from math and strutils modules. IfThen from System totally breaks the compatibility :\ . C'mon Sven. In one field you're rigorously but in something like this you're liberal (braking/dangerous change / for existing code base). If i understand correctly "ThenExpr" is executed only when "Condition" is true and "ElseExpr" is executed only when "Condition" is false. For standard "IfThen" from Math and StrUtils "ThenExpr" and "ElseExpr" is executed before IfThen is called. for me different syntax for System.IfThen is required (fpIfThen ? or http://docs.elementscompiler.com/Oxygene/Expressions/If/ ).

Reply by email

Maciej Izak
to David Butler

2016-02-01 9:35 GMT+01:00 David Butler :

Show quoted text 11 lines
This is usually called "inline if". Maybe call it "inlineif" or "iif", e..g x := iif (a < 3, 1, 2) or even x := iif a < 3 then 1 else 2;

anything is better than System.IfThen blatant incompatibility. I opt for oxygene syntax. Anyway reverting this "ferature" in current form is very important.

Reply by email

Michalis Kamburelis
to Maciej Izak: 2016-02-01 8:59 GMT+01:00 Marco van de Voort : +1 . IfThen instricit is IMO very bad…
Maciej Izak wrote 14 lines
+1 . IfThen instricit is IMO very bad idea. I have a lot of "IfThen" from math and strutils modules. IfThen from System totally breaks the compatibility :\ . C'mon Sven. In one field you're rigorously but in something like this you're liberal (braking/dangerous change / for existing code base). If i understand correctly "ThenExpr" is executed only when "Condition" is true and "ElseExpr" is executed only when "Condition" is false. For standard "IfThen" from Math and StrUtils "ThenExpr" and "ElseExpr" is executed before IfThen is called. for me different syntax for System.IfThen is required (fpIfThen ? or http://docs.elementscompiler.com/Oxygene/Expressions/If/ ).

As far as I understand, compatibility is not broken: new IfThen was deliberately introduced as part of the System unit, that is implicitly always used as the 1st unit. If you use Math (or StrUtils or any other modules that provide IfThen implementations), they will "cover" the System.IfThen definition. So your code will continue to work as it was.

And the name like FpIfThen look rather ugly, actually. As far as I'm concerned, IfThen sounds simple and Ok.

Michalis

Reply by email

Maciej Izak
to Michalis Kamburelis

2016-02-01 10:17 GMT+01:00 Michalis Kamburelis :

Show quoted text 9 lines
As far as I understand, compatibility is not broken: new IfThen was deliberately introduced as part of the System unit, that is implicitly always used as the 1st unit. If you use Math (or StrUtils or any other modules that provide IfThen implementations), they will "cover" the System.IfThen definition. So your code will continue to work as it was. And the name like FpIfThen look rather ugly, actually. As far as I'm concerned, IfThen sounds simple and Ok.

IfThen is not ok. It can potentially break compatibility. The probability is huge. IfThen is in many cases the only function that is used from Math or StrUtils. I have big codebase to maintain which is refactored very often. The risk to omit Math and StrUtils is very big.

It can be very hard to debug.

There are so many ways to implement this and was chosen the worst scenario. :\

Best regards, Maciej Izak

Reply by email

Michael Van Canneyt
to Maciej Izak
Maciej Izak wrote 16 lines
2016-02-01 10:17 GMT+01:00 Michalis Kamburelis : > > As far as I understand, compatibility is not broken: new IfThen was > deliberately introduced as part of the System unit, that is implicitly > always used as the 1st unit. If you use Math (or StrUtils or any other > modules that provide IfThen implementations), they will "cover" the > System.IfThen definition. So your code will continue to work as it was. > > And the name like FpIfThen look rather ugly, actually. As far as I'm > concerned, IfThen sounds simple and Ok. IfThen is not ok. It can potentially break compatibility. The probability is huge. IfThen is in many cases the only function that is used from Math or StrUtils. I have big codebase to maintain which is refactored very often. The risk to omit Math and StrUtils is very big.

This is not an argument.

If you take this as an argument, then the system unit is set in concrete, for fear of breaking someones code whenever something new is introduced.

Show quoted text 7 lines
It can be very hard to debug. There are so many ways to implement this and was chosen the worst scenario. :\ From my point of view, Sven took the best possible route by making it an

identifier of the system unit. The refactoring argument is nonsense, as it applies to ANY identifier, not just this one.

We can discuss IIF or IfThen, but the same applies for IIF.

Michael.

Reply by email

Maciej Izak
to Michael Van Canneyt

2016-02-01 10:42 GMT+01:00 Michael Van Canneyt :

Show quoted text 5 lines
This is not an argument. If you take this as an argument, then the system unit is set in concrete, for fear of breaking someones code whenever something new is introduced.

No. This is argument. That was reason in Delphi to introduce TObject.DisposeOf instead of any other name to help not breaking someones code.

From my point of view, Sven took the worst possible route, *especially

there is a hundred other ways to achieve this* (!).

Best regards, Maciej Izak

Reply by email

Maciej Izak
to Michael Van Canneyt: This is not an argument. If you take this as an argument, then the system unit is set in…

2016-02-01 10:42 GMT+01:00 Michael Van Canneyt :

Show quoted text 5 lines
Sven took the best possible route by making it an identifier of the system unit. The refactoring argument is nonsense, as it applies to ANY identifier, not just this one. We can discuss IIF or IfThen, but the same applies for IIF.

You are kidding me?

You can never be sure what you use. When is used Math or StrUtils I need to use System.IfThen. O___o

*The decision Sven is wrong.*

Best regards, Maciej Izak

Reply by email

Michael Van Canneyt
to Maciej Izak
Maciej Izak wrote 10 lines
2016-02-01 10:42 GMT+01:00 Michael Van Canneyt : > Sven took the best possible route by making it an > identifier of the system unit. The refactoring argument is nonsense, as it > applies to ANY identifier, not just this one. > > We can discuss IIF or IfThen, but the same applies for IIF. You are kidding me?

No ?

Show quoted text 5 lines
You can never be sure what you use. When is used Math or StrUtils I need to use System.IfThen. O___o *The decision Sven is wrong.*

Two can play at this game :)

*your argument means the system unit cannot be changed _ever again_*

The scope rules apply for this just as it does for any other. The modes are based on this rule by inserting - behind your back - the objpas unit in the uses clause which does in essence the same.

As I said, I don't care about the actual name.

I personally would have used IIF():
I have a unit fpiif which contains a bunch of iif overloads, so my life would certainly be easier if Sven had used that ;)

Michael.

Reply by email

Alexandrov Alexandru
to Maciej Izak: 2016-02-01 10:42 GMT+01:00 Michael Van Canneyt : You are kidding me? You can never be…

IIf or IfThen (I opt for IIf) are trivial functions. The result of the Math function must be the same as the System ones. Why do you care which one apply?

2016-02-01 12:00 GMT+02:00 Maciej Izak :

Show quoted text 24 lines
2016-02-01 10:42 GMT+01:00 Michael Van Canneyt : > Sven took the best possible route by making it an > identifier of the system unit. The refactoring argument is nonsense, as it > applies to ANY identifier, not just this one. > > We can discuss IIF or IfThen, but the same applies for IIF. You are kidding me? You can never be sure what you use. When is used Math or StrUtils I need to use System.IfThen. O___o *The decision Sven is wrong.* -- Best regards, Maciej Izak _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Alexandrov Alexandru, tel. 0732-378-682 tel. 0743-586-614

Reply by email

Sven Barth
to Alexandrov Alexandru

Am 01.02.2016 11:21 schrieb "Alexandrov Alexandru" <

: IIf or IfThen (I opt for IIf) are trivial functions. The result of the

Math function must be the same as the System ones. Why do you care which one apply?

Because there is a semantic difference. The new intrinsic works like an if-statement in that only the branch that is taken is evaluated while for all other IfThen() that exist up to now both branches will be evaluated. Thus using one over the other can lead to changes in behavior, especially if side effects (calling functions) are involved.

Regards,
Sven

Reply by email

Maciej Izak
to Michael Van Canneyt: No ? Two can play at this game :) *your argument means the system unit cannot be changed…

2016-02-01 11:12 GMT+01:00 Michael Van Canneyt :

*your argument means the system unit cannot be changed _ever again_*

FPC team learned me more conservative approach :P

Show quoted text 5 lines
As I said, I don't care about the actual name. I personally would have used IIF(): I have a unit fpiif which contains a bunch of iif overloads, so my life would certainly be easier if Sven had used that ;)

Paradoxically, "IfThen" hinders future usage of the code in case when is used Math or StrUtils, it will cause unpleasant consequences. Any other name than "IfThen" is better.

To be clear : I like new feature but the name *must* be different. It is impossible to prove that "IfThen" name is right ;););) :P.

Best regards, Maciej Izak

Reply by email

Sven Barth
to Maciej Izak: 2016-02-01 8:59 GMT+01:00 Marco van de Voort : +1 . IfThen instricit is IMO very bad…
"Maciej Izak" wrote 5 lines
2016-02-01 8:59 GMT+01:00 Marco van de Voort : > > The only really bad thing is the name, as Florian already said, with the > versions in strutils and math. The clash with delphi compatible

functions

> should be avoided. +1 . IfThen instricit is IMO very bad idea. I have a lot of "IfThen" from

math and strutils modules.

IfThen from System totally breaks the compatibility :\ . C'mon Sven. In

one field you're rigorously but in something like this you're liberal (braking/dangerous change / for existing code base).

It does *not* break existing have to admit though that I forgot about the potential problems due to refactoring. I'll change the name to avoid this pitfall, though I've yet to decide which one.

Regards,
Sven

Reply by email

Maciej Izak
to Sven Barth

2016-02-01 11:28 GMT+01:00 Sven Barth :

It does *not* break existing code at all.

Right. As mentioned in my other message: "Paradoxically, "IfThen" hinders future usage of the code" :)

Best regards, Maciej Izak

Reply by email

Sven Barth
to David Butler: This is usually called "inline if". Maybe call it "inlineif" or "iif", e..g x := iif (a <…
"David Butler" wrote 10 lines
This is usually called "inline if". Maybe call it "inlineif" or "iif", e..g x := iif (a < 3, 1, 2) or even x := iif a < 3 then 1 else 2;

I personally would have preferred "if a < 3 then 1 else 2", but a discussion on fpc-devel a dew months ago has shown that there are quite some against it... I myself am against a c-like operator like ?: and thus the intrinsic came as a compromise.

Regards,
Sven

Reply by email

Marco van de Voort
to Sven Barth: functions math and strutils modules. one field you're rigorously but in something like…

In our previous episode, Sven Barth said:

Show quoted text 10 lines
> > > +1 . IfThen instricit is IMO very bad idea. I have a lot of "IfThen" from math and strutils modules. > > IfThen from System totally breaks the compatibility :\ . C'mon Sven. In one field you're rigorously but in something like this you're liberal (braking/dangerous change / for existing code base). It does *not* break existing if you run unmodified, but a bit of copy and paste due to other

FPC<->delphi conversion issues and a forgotten uses and you run into something strange problem. Of course after three days debugging later you find out that FPC also has an intrinsic, and you can see when it is the intrinsic and when the library function.

But then you have already pulled out most of your hair.

I have to admit though that I forgot about the potential problems due to refactoring. I'll change the name to avoid this pitfall, though I've yet to decide which one.

Good.

Reply by email

Maciej Izak
to Marco van de Voort

2016-02-01 11:38 GMT+01:00 Marco van de Voort :

Show quoted text 8 lines
Not if you run unmodified, but a bit of copy and paste due to other FPC<->delphi conversion issues and a forgotten uses and you run into something strange problem. Of course after three days debugging later you find out that FPC also has an intrinsic, and you can see when it is the intrinsic and when the library function. But then you have already pulled out most of your hair.

It even can be worser when you're bald man. :/

Best regards, Maciej Izak

Reply by email

Marc Weustink
to Sven Barth: functions math and strutils modules. one field you're rigorously but in something like…
Sven Barth wrote 20 lines
Am 01.02.2016 09:26 schrieb "Maciej Izak" < >: > > 2016-02-01 8:59 GMT+01:00 Marco van de Voort < >: >> >> The only really bad thing is the name, as Florian already said, with the >> versions in strutils and math. The clash with delphi compatible functions >> should be avoided. > > > +1 . IfThen instricit is IMO very bad idea. I have a lot of "IfThen" from math and strutils modules. > > IfThen from System totally breaks the compatibility :\ . C'mon Sven. In one field you're rigorously but in something like this you're liberal (braking/dangerous change / for existing code base). It does *not* break existing will break future code. What if I need math someday and add this to

the uses clause ? Which one will be called ?

I have to admit though that I forgot about the potential problems due to refactoring. I'll change the name to avoid this pitfall, though I've yet to decide which one.

OK,

Marc

Reply by email

Maciej Izak
to Sven Barth: functions math and strutils modules. one field you're rigorously but in something like…

2016-02-01 11:28 GMT+01:00 Sven Barth :

I have to admit though that I forgot about the potential problems due to refactoring. I'll change the name to avoid this pitfall, though I've yet to decide which one.

My proposition is:

function &if(Condition: Boolean; ThenExpr, ElseExpr: type): type;

& is used rarely (and it is legal ident part), collision with existing code base is minimal. Looks almost like regular Pascal syntax ;).

Best regards, Maciej Izak

Reply by email

Michael Van Canneyt
to Maciej Izak
Maciej Izak wrote 13 lines
2016-02-01 11:28 GMT+01:00 Sven Barth : > I have to admit though that I forgot about the potential problems due to > refactoring. I'll change the name to avoid this pitfall, though I've yet to > decide which one. > My proposition is: function &if(Condition: Boolean; ThenExpr, ElseExpr: type): type; & is used rarely (and it is legal ident part), collision with existing code base is minimal. Looks almost like regular Pascal syntax ;).

No. The compiler already uses &.

& means 'the following is an identifier even if it is a keyword'.

You can perfectly declare and compile:

Var
   &if : integer;
begin
   &if:=1;
end.

So &if is a bad idea.

Michael.

Reply by email

Maciej Izak
to Michael Van Canneyt

2016-02-01 13:09 GMT+01:00 Michael Van Canneyt :

Show quoted text 15 lines
No. The compiler already uses &. & means 'the following is an identifier even if it is a keyword'. You can perfectly declare and compile: Var &if : integer; begin &if:=1; end. So &if is a bad idea.

Yes it is possible. Anyway it is better idea than IfThen. You treat facts selectively. How often is used &if and how often is used IfThen?

&IfThen looks also good (I like shorter syntax &if). With "&" prefix it is obvious that this function is unique.

Best regards, Maciej Izak

Reply by email

Maciej Izak
to Maciej Izak

2016-02-01 13:15 GMT+01:00 Maciej Izak :

Show quoted text 24 lines
2016-02-01 13:09 GMT+01:00 Michael Van Canneyt : > > No. The compiler already uses &. > > & means 'the following is an identifier even if it is a keyword'. > > You can perfectly declare and compile: > > Var > &if : integer; > > begin > &if:=1; > end. > > So &if is a bad idea. Yes it is possible. Anyway it is better idea than IfThen. You treat facts selectively. How often is used &if and how often is used IfThen? &IfThen looks also good (I like shorter syntax &if). With "&" prefix it is obvious that this function is unique.

you can even perfectly declare and compile:

var
  inc, dec, chr: integer;
  ifthen: integer;
  &whatever: integer;

It means that inc/&if intrinsic name is bad? Srsly?

Best regards, Maciej Izak

Reply by email

Michael Van Canneyt
to Maciej Izak: 2016-02-01 13:09 GMT+01:00 Michael Van Canneyt : Yes it is possible. Anyway it is better…
Maciej Izak wrote 20 lines
2016-02-01 13:09 GMT+01:00 Michael Van Canneyt : > > No. The compiler already uses &. > > & means 'the following is an identifier even if it is a keyword'. > > You can perfectly declare and compile: > > Var > &if : integer; > > begin > &if:=1; > end. > > So &if is a bad idea. Yes it is possible. Anyway it is better idea than IfThen. You treat facts selectively. How often is used &if and how often is used IfThen?

You missed my point.

&IfThen looks also good (I like shorter syntax &if). With "&" prefix it is obvious that this function is unique.

You misunderstand.

The & character cannot be used as part of an identifier, it is a special token.

It is eaten by the scanner. The parser will never see it. You simply cannot define "&if' as an identifier. The parser will always see 'if'.

scanner.pas around line 4607.

And modifying the scanner for this exception is a REALLY bad idea.

Michael.

Reply by email

Maciej Izak
to Michael Van Canneyt

2016-02-01 13:29 GMT+01:00 Michael Van Canneyt :

Show quoted text 18 lines
You missed my point. > &IfThen looks also good (I like shorter syntax &if). With "&" prefix it is > obvious that this function is unique. > You misunderstand. The & character cannot be used as part of an identifier, it is a special token. It is eaten by the scanner. The parser will never see it. You simply cannot define "&if' as an identifier. The parser will always see 'if'. scanner.pas around line 4607. And modifying the scanner for this exception is a REALLY bad idea.

in that case you are right :)

Best regards, Maciej Izak

Reply by email

silvioprog
to Michalis Kamburelis: As far as I understand, compatibility is not broken: new IfThen was deliberately…

On Mon, Feb 1, 2016 at 6:17 AM, Michalis Kamburelis <

Show quoted text 24 lines
wrote: Maciej Izak wrote: > +1 . IfThen instricit is IMO very bad idea. I have a lot of "IfThen" > from math and strutils modules. > > IfThen from System totally breaks the compatibility :\ . C'mon Sven. In > one field you're rigorously but in something like this you're liberal > (braking/dangerous change / for existing code base). > > If i understand correctly "ThenExpr" is executed only when "Condition" > is true and "ElseExpr" is executed only when "Condition" is false. For > standard "IfThen" from Math and StrUtils "ThenExpr" and "ElseExpr" is > executed before IfThen is called. > > for me different syntax for System.IfThen is required (fpIfThen ? or > http://docs.elementscompiler.com/Oxygene/Expressions/If/ ). As far as I understand, compatibility is not broken: new IfThen was deliberately introduced as part of the System unit, that is implicitly always used as the 1st unit. If you use Math (or StrUtils or any other modules that provide IfThen implementations), they will "cover" the System.IfThen definition. So your code will continue to work as it was.

However Iif() sounds very good.

And the name like FpIfThen look rather ugly, actually. As far as I'm concerned, IfThen sounds simple and Ok.

+1. FpIfThen is very ugly. o.o'

Silvio Clécio

Reply by email

Sven Barth
to Michael Van Canneyt: You missed my point. You misunderstand. The & character cannot be used as part of an…
"Michael Van Canneyt" wrote 34 lines
On Mon, 1 Feb 2016, Maciej Izak wrote: > 2016-02-01 13:09 GMT+01:00 Michael Van Canneyt : >> >> >> No. The compiler already uses &. >> >> & means 'the following is an identifier even if it is a keyword'. >> >> You can perfectly declare and compile: >> >> Var >> &if : integer; >> >> begin >> &if:=1; >> end. >> >> So &if is a bad idea. > > > > Yes it is possible. Anyway it is better idea than IfThen. You treat facts > selectively. How often is used &if and how often is used IfThen? You missed my point. > > &IfThen looks also good (I like shorter syntax &if). With "&" prefix it

is

Show quoted text 6 lines
> obvious that this function is unique. You misunderstand. The & character cannot be used as part of an identifier, it is a special

token.

It is eaten by the scanner. The parser will never see it. You simply

cannot define "&if' as an identifier. The parser will always see 'if'.

scanner.pas around line 4607. And modifying the scanner for this exception is a REALLY bad idea.

Maciej is in so far right that the intrinsic could indeed be named "if" and the only way to call it would thus be by "&if", cause only then the scanner would not treat "if" as a keyword. So it would work with what the compiler currently can.

I'm more inclined to use iif() however, as &if() doesn't look that nice... (though it would be more noticeable :P )

Regards,
Sven

Reply by email

silvioprog
to Sven Barth

On Mon, Feb 1, 2016 at 11:42 AM, Sven Barth
wrote:
[...]

I'm more inclined to use iif() however, as &if() doesn't look that nice... (though it would be more noticeable :P )

+1+1+1+1+1 iif(). :-D

Silvio Clécio

Reply by email

leledumbo
to silvioprog
Iif sounds good, and would be very useful for converting C code. However Iif() sounds very good. Me too. Iif is used for many languages. +1+1+1+1+1 iif(). :-D

I'm with Silvio. The name "inline if" (iif) describes its semantics clearer than IfThen, which already has semantics of being regular function with all parameters evaluated first instead of a syntactic sugar for if-then-else statement.

View this message in context: http://free-pascal-general.1045716.n5.nabble.com/New-feature-IfThen-intrinsic-tp5723735p5723785.html Sent from the Free Pascal - General mailing list .

Reply by email

Maciej Izak
to Sven Barth: is token. cannot define "&if' as an identifier. The parser will always see 'if'. Maciej…

2016-02-01 15:42 GMT+01:00 Sven Barth :

Show quoted text 8 lines
Maciej is in so far right that the intrinsic could indeed be named "if" and the only way to call it would thus be by "&if", cause only then the scanner would not treat "if" as a keyword. So it would work with what the compiler currently can. I'm more inclined to use iif() however, as &if() doesn't look that nice... (though it would be more noticeable :P )

Phew. So it is possible. It is hard to discuss with compiler team members like Michael :P.

1. IMO &if (if is possible to use &if) is best choice. iif can conflict in the same way as IfThen.
2. IIF should works like IfThen in Math or StrUtils. If no - It will be precedence with comparision to others languages and iif definition (!)... https://en.wikipedia.org/wiki/IIf
3. intrinsic &if is very close to native usage of if then else
4. we can have both. IIF and &if. Don't create precedents!

Best regards, Maciej Izak

Reply by email

Martin
to Sven Barth: functions math and strutils modules. one field you're rigorously but in something like…
Sven Barth wrote
I have to admit though that I forgot about the potential problems due to refactoring. I'll change the name to avoid this pitfall, though I've yet to decide which one.

well (playing devils advocate), why not IF(a<b, 1, 2).

Only it will have to be written as &IF()

That already works today. The below compiles with fpc 3.0. (And I would guess, few (if any) are using this)

function &if(a: boolean; c,b: integer): integer;
begin
end;
var
   x: Integer;
begin
x := &if(1<2,2,3);
end.

Reply by email

Michael Van Canneyt
to Sven Barth: is token. cannot define "&if' as an identifier. The parser will always see 'if'. Maciej…
Sven Barth wrote 7 lines
> > And modifying the scanner for this exception is a REALLY bad idea. Maciej is in so far right that the intrinsic could indeed be named "if" and the only way to call it would thus be by "&if", cause only then the scanner would not treat "if" as a keyword. So it would work with what the compiler currently can.

Then you preclude

Var
  &if : Integer;

This is a really bad idea. The whole idea of & is to make the above possible, so you are going to make an exception on an exception ?

You really want to create monstrosities as

   &if:=system.&if(a>3,1,3) * b
Really guys, I know it is ugly, but we don't have to add to it even more;

Using & in a system intrinsic identifier: how crazy can you get ?

Sorry Maciej and Sven, but I will personally revert such a change, and shut down the SVN server afterwards to boot so you have time to calm down and get back to your senses. Get a holiday or so.

Michael.

Reply by email

Felipe Monteiro de Carvalho
to Michael Van Canneyt

So finally we have the ternary operator in Pascal? This will simplify converting from C to Pascal.

j ;= IfThen(i < 32, 48, 21);
I guess this is a typo and should be ":=" instead of ";="

thanks,

Felipe Monteiro de Carvalho

Reply by email

Maciej Izak
to Michael Van Canneyt: Then you preclude Var &if : Integer; This is a really bad idea. The whole idea of & is to…

2016-02-01 16:07 GMT+01:00 Michael Van Canneyt :

Show quoted text 17 lines
Then you preclude Var &if : Integer; This is a really bad idea. The whole idea of & is to make the above possible, so you are going to make an exception on an exception ? You really want to create monstrosities as &if:=system.&if(a>3,1,3) * b Really guys, I know it is ugly, but we don't have to add to it even more; Using & in a system intrinsic identifier: how crazy can you get ?

Looks good and clever. Logical choice. How often you have variables with & prefix?

Best regards, Maciej Izak

Reply by email

Graeme Geldenhuys
to Felipe Monteiro de Carvalho: So finally we have the ternary operator in Pascal? This will simplify converting from C…
Felipe Monteiro de Carvalho wrote
> > j ;= IfThen(i < 32, 48, 21); I guess this is a typo and should be ":=" instead of ";="

You replied to the wrong message, or I'm receiving mailing list messages out of sequence. The code you quoted above was in reply to Michael's message, but his message never contained such code??

Regards,
- Graeme -

My public PGP key: http://tinyurl.com/graeme-pgp

Reply by email

Michael Van Canneyt
to Maciej Izak: 2016-02-01 16:07 GMT+01:00 Michael Van Canneyt : Looks good and clever. Logical choice.…
Maciej Izak wrote 21 lines
2016-02-01 16:07 GMT+01:00 Michael Van Canneyt : > > Then you preclude > > Var > &if : Integer; > > This is a really bad idea. The whole idea of & is to make the above > possible, so you are going to make an exception on an exception ? > > You really want to create monstrosities as > > &if:=system.&if(a>3,1,3) * b > > Really guys, I know it is ugly, but we don't have to add to it even more; > > Using & in a system intrinsic identifier: how crazy can you get ? > Looks good and clever. Logical choice.

Only in warped minds, as far as I am concerned.
There is nothing logical about it.

The logical thing is to find a new pascal identifier.

How often you have variables with & prefix?

That is entirely irrelevant to the point I am trying to make.

But to answer your question:
Never, and if Delphi didn't have it, I would oppose its introduction as well. It is a result of a 'whatever goes' attitude.

Why not introduce C syntax, while we're at it ? Or Perl, or Javascript or whatever just happens to be the fashion of the day ? The compiler can probably handle it, I'm sure we'll find someone crazy enough to take the task on.

This 'whatever goes' attitude is really a disease that should be weeded out.

So you trying to introduce it in a system identifier/intrinsic is IMHO a double insult to plain common sense.

Michael.

Reply by email

leledumbo
to Maciej Izak: 2016-02-01 16:07 GMT+01:00 Michael Van Canneyt : Looks good and clever. Logical choice.…
Looks good and clever. Logical choice. How often you have variables with &

prefix?

Only when I use ORM with automapping of properties to fields (for fields whose name clash with reserved words such as the most common 'type'). I won't use it in other cases.

Agree with Michael, no & please.

View this message in context: http://free-pascal-general.1045716.n5.nabble.com/New-feature-IfThen-intrinsic-tp5723735p5723797.html Sent from the Free Pascal - General mailing list .

Reply by email

silvioprog
to leledumbo
leledumbo wrote 9 lines
> Looks good and clever. Logical choice. How often you have variables with & prefix? Only when I use ORM with automapping of properties to fields (for fields whose name clash with reserved words such as the most common 'type'). I won't use it in other cases. Agree with Michael, no & please.

I agree with Michael too. No & please, it can conflict with ported codes from C <http://tigcc.ticalc.org/doc/opers.html#ref>.

Silvio Clécio

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt: Only in warped minds, as far as I am concerned. There is nothing logical about it. The…
Michael Van Canneyt wrote 6 lines
> Looks good and clever. Logical choice. Only in warped minds, as far as I am concerned. There is nothing logical about it. The logical thing is to find a new pascal identifier.

+1

This 'whatever goes' attitude is really a disease that should be weeded out.

Indeed. Keep the Object Pascal language that Free Pascal supports as pure and Pascal-like as possible. That's what makes this language so nice to use. That doesn't mean new language features can't be added, but when they are, find a Pascal-like solution.

Regards,
- Graeme -

Reply by email

Maciej Izak
to Graeme Geldenhuys

2016-02-01 17:14 GMT+01:00 Graeme Geldenhuys
:

That doesn't mean new language features can't be added, but when they are, find a Pascal-like solution.

IfThen, IIF, &if is controversial.

My favorite still is &if.

More Pascal like propositions:

1) x := IfExpr(true, 0, 0);
2) x := if true then 0 else 0;
3) x := ite(true, 0, 0); // If Then Else = ITE, more correct than IIF
Best regards, Maciej Izak

Reply by email

Fabrício Srdic
to leledumbo: I'm with Silvio. The name "inline if" (iif) describes its semantics clearer than IfThen,…
"leledumbo" wrote 7 lines
> Iif sounds good, and would be very useful for converting C code. > However Iif() sounds very good. > Me too. Iif is used for many languages. > +1+1+1+1+1 iif(). :-D I'm with Silvio. The name "inline if" (iif) describes its semantics

clearer

than IfThen, which already has semantics of being regular function with

all

parameters evaluated first instead of a syntactic sugar for if-then-else statement.

+1

Reply by email

Jürgen Hestermann
to Michael Van Canneyt: Only in warped minds, as far as I am concerned. There is nothing logical about it. The…
Michael Van Canneyt wrote 5 lines
Never, and if Delphi didn't have it, I would oppose its introduction as well. It is a result of a 'whatever goes' attitude. Why not introduce C syntax, while we're at it ? Or Perl, or Javascript or whatever just happens to be the fashion of the day ? The compiler can probably handle it, I'm sure we'll find someone crazy enough to take the task on. This 'whatever goes' attitude is really a disease that should be weeded out. So you trying to introduce it in a system identifier/intrinsic is IMHO a double insult to plain common sense.

I fully agree!
Every *addition* to the language should be thought over carefully with respect to the spirit of the Pascal language. In case of doubt just don't implement it (yet).
Such things are cast in stone forever and one wrong quick shot can bite many people over many years.

If it cannot be avoided to add yet another (superfluous) function to the Pascal language (and in case someone cares) my thoughts about System."IfThen" are:

1.) It should not have the same name as IfThen from other (Pascal) units. At least the language itself should be as unambiguous as possible. 2.) It should consist of letters only (no operators like &). This would be totally confusing as it would break a long Pascal tradition and would make code less readable. 3.) It should have a speaking name that describes what it realy does.

From the above I would vote for "InlineIf" or eve better "IfThenElse".

Reply by email

Maciej Izak
to Fabrício Srdic: clearer all +1

2016-02-01 17:41 GMT+01:00 Fabrício Srdic :

Show quoted text 16 lines
Em 01/02/2016 12:52, "leledumbo" escreveu: > > > Iif sounds good, and would be very useful for converting C code. > > However Iif() sounds very good. > > Me too. Iif is used for many languages. > > +1+1+1+1+1 iif(). :-D > > I'm with Silvio. The name "inline if" (iif) describes its semantics clearer > than IfThen, which already has semantics of being regular function with all > parameters evaluated first instead of a syntactic sugar for if-then-else > statement. +1

iif is not semantic clear. IIF means "Immediate IF". Citation: "both truepart and the falsepart will be evaluated regardless of which one is actually returned." - https://en.wikipedia.org/wiki/IIf

IIF is equivalent of IfThen from Math / StrUtils, intrinsic "IfThen" works in different way. We can not make such a mess.

Best regards, Maciej Izak

Reply by email

Michael Van Canneyt
to Maciej Izak
Maciej Izak wrote 7 lines
2016-02-01 18:08 GMT+01:00 Jürgen Hestermann : > From the above I would vote for "InlineIf" or eve better "IfThenElse". > InlineIf sounds better than IIF. Very suggestive and correct. IfThenElse looks more like "Immediate IF" (or IfThen) functionality.

InlineIf is fine with me.

As long as it doesn't require & or some other special constructs.

Michael.

Reply by email

Sven Barth
to Michael Van Canneyt: Then you preclude Var &if : Integer; This is a really bad idea. The whole idea of & is to…
"Michael Van Canneyt" wrote 10 lines
On Mon, 1 Feb 2016, Sven Barth wrote: >> >> And modifying the scanner for this exception is a REALLY bad idea. > > > Maciej is in so far right that the intrinsic could indeed be named "if"

and

> the only way to call it would thus be by "&if", cause only then the

scanner

> would not treat "if" as a keyword. So it would work with what the

compiler

Show quoted text 10 lines
> currently can. Then you preclude Var &if : Integer; This is a really bad idea. The whole idea of & is to make the above possible, so you are going to make an exception on an exception ?

That would only be precluded if the &if variable would be in the System unit...

Show quoted text 10 lines
You really want to create monstrosities as &if:=system.&if(a>3,1,3) * b Really guys, I know it is ugly, but we don't have to add to it even more; Using & in a system intrinsic identifier: how crazy can you get ? Sorry Maciej and Sven, but I will personally revert such a change, and

shut down the SVN server afterwards to boot so you have time to

calm down and get back to your senses. Get a holiday or so.

In case you haven't read my mail carefully enough: I only stated that it's definitely possible to use "if" as an identifier for an intrinsic and to call it using "&if", because you said that it's not possible which is incorrect.
I also said that I don't prefer the "&if" and merely joked that it would be more noticeable because of the "&".

Regards,
Sven

Reply by email

Sven Barth
to Maciej Izak: 2016-02-01 15:42 GMT+01:00 Sven Barth : Phew. So it is possible. It is hard to discuss…
"Maciej Izak" wrote
2016-02-01 15:42 GMT+01:00 Sven Barth : > > Maciej is in so far right that the intrinsic could indeed be named "if"

and the only way to call it would thus be by "&if", cause only then the scanner would not treat "if" as a keyword. So it would work with what the compiler currently can.

> > I'm more inclined to use iif() however, as &if() doesn't look that

nice... (though it would be more noticeable :P )

Phew. So it is possible. It is hard to discuss with compiler team members

like Michael :P.

1. IMO &if (if is possible to use &if) is best choice. iif can conflict

in the same way as IfThen.

In that sense we have to consider the RTL as no longer expandable as all identifiers could be potentially used already, even &if!

2. IIF should works like IfThen in Math or StrUtils. If no - It will be

precedence with comparision to others languages and iif definition (!)...

And you didn't read the article fully. There is one language that has an iif() intrinsic that evaluates only the taken branch: Oxygene. ;)

Regards,
Sven

Reply by email

Sven Barth
to silvioprog: On Mon, Feb 1, 2016 at 12:48 PM, leledumbo I agree with Michael too. No & please, it can…
"silvioprog" wrote
On Mon, Feb 1, 2016 at 12:48 PM, leledumbo
> > > Looks good and clever. Logical choice. How often you have variables

with &

Show quoted text 10 lines
> prefix? > > Only when I use ORM with automapping of properties to fields (for fields > whose name clash with reserved words such as the most common 'type'). I > won't use it in other cases. > > Agree with Michael, no & please. I agree with Michael too. No & please, it can conflict with ported codes

from C.

While I agree with Michael I don't agree with you. We already have "&" which is used for two purposes:
- binary numbers
- escaping keywords
The &if would merely be an application of the latter which already works since AFAIK 2.4.0.
Also you can't have "&if" in C-code as C does not allow you to escape identifiers. And an address of an if statement is also not possible.

Regards,
Sven

Reply by email

silvioprog
to Michael Van Canneyt: InlineIf is fine with me. As long as it doesn't require & or some other special…
Michael Van Canneyt wrote 14 lines
On Mon, 1 Feb 2016, Maciej Izak wrote: > 2016-02-01 18:08 GMT+01:00 Jürgen Hestermann : > > From the above I would vote for "InlineIf" or eve better "IfThenElse". >> >> > InlineIf sounds better than IIF. Very suggestive and correct. IfThenElse > looks more like "Immediate IF" (or IfThen) functionality. > InlineIf is fine with me. As long as it doesn't require & or some other special constructs.

It would be nice if the programmer could choose it from some compiler switch, something like:

{$define ifthendecl := InlineIf}

or:

{$define ifthendecl := iif} // my favourite :3

or:

{$define ifthendecl := &if}

And the default could be IfThen.

Another nice feature sould be:

Ifso().

S := Ifso(True, 'SomeValue'); // S = 'SomeValue'
S := Ifso(False, 'SomeValue'); // S = ''

Just an idea. :-D

Silvio Clécio

Reply by email

Sven Barth
to silvioprog
"silvioprog" wrote 22 lines
On Mon, Feb 1, 2016 at 2:41 PM, Michael Van Canneyt < wrote: > > On Mon, 1 Feb 2016, Maciej Izak wrote: >> >> 2016-02-01 18:08 GMT+01:00 Jürgen Hestermann < : >> >>> From the above I would vote for "InlineIf" or eve better "IfThenElse". >>> >> >> InlineIf sounds better than IIF. Very suggestive and correct. IfThenElse >> looks more like "Immediate IF" (or IfThen) functionality. > > > InlineIf is fine with me. > > As long as it doesn't require & or some other special constructs. It would be nice if the programmer could choose it from some compiler

switch, something like:

Show quoted text 22 lines
{$define ifthendecl := InlineIf} or: {$define ifthendecl := iif} // my favourite :3 or: {$define ifthendecl := &if} And the default could be IfThen. Another nice feature sould be: Ifso(). S := Ifso(True, 'SomeValue'); // S = 'SomeValue' S := Ifso(False, 'SomeValue'); // S = '' Just an idea. :-D

Don't complicate a simple feature like this even more -.-

Regards,
Sven

Reply by email

silvioprog
to silvioprog: On Mon, Feb 1, 2016 at 2:41 PM, Michael Van Canneyt It would be nice if the programmer…

On Mon, Feb 1, 2016 at 3:23 PM, silvioprog wrote: [...]

Show quoted text 13 lines
It would be nice if the programmer could choose it from some compiler switch, something like: {$define ifthendecl := InlineIf} or: {$define ifthendecl := iif} // my favourite :3 or: {$define ifthendecl := &if}

[...]

Damn Gmail ctrl+enter... -.-'

I meant:

{$define TheFavouriteProgrammerWord := System.InlineIf}

so:

S := TheFavouriteProgrammerWord(Cond, TVal, FVal);
Silvio Clécio

Reply by email

Maciej Izak
to Sven Barth: and the only way to call it would thus be by "&if", cause only then the scanner would not…

2016-02-01 19:18 GMT+01:00 Sven Barth :

And you didn't read the article fully. There is one language that has an iif() intrinsic that evaluates only the taken branch: Oxygene. ;)

-,- OMG (!). Sorry :\ I have not noticed. This changes everything. Damn. What is better?

1. correct behavior ?
2. a little more oxygene compatibility ?

if 1 will be chosen, is possible to create alias to InlineIf/Ifthen/whateverIf intrinsic in the future? (for example iif alias in Oxygene mode)

Best regards, Maciej Izak

Reply by email

silvioprog
to Dmitry Boyarintsev: Dmitry

On Mon, Feb 1, 2016 at 3:34 PM, Dmitry Boyarintsev <

Show quoted text 12 lines
wrote: On Mon, Feb 1, 2016 at 1:23 PM, silvioprog wrote: > > It would be nice if the programmer could choose it from some compiler > switch, something like: > > {$define ifthendecl := InlineIf} > > macros?

Yes, or something that allow the programmer to choose an alias to the feature.

Silvio Clécio

Reply by email

Dmitry Boyarintsev
to silvioprog
silvioprog wrote 17 lines
On Mon, Feb 1, 2016 at 3:34 PM, Dmitry Boyarintsev < > wrote: > On Mon, Feb 1, 2016 at 1:23 PM, silvioprog wrote: > >> >> It would be nice if the programmer could choose it from some compiler >> switch, something like: >> >> {$define ifthendecl := InlineIf} >> >> macros? > Yes, or something that allow the programmer to choose an alias to the feature.

No matter what the language is, developers still want to write C... for the shortness of script

thanks,
Dmitry

Reply by email

David Butler

On Mon, Feb 1, 2016 at 8:45 PM, Dmitry Boyarintsev <

Show quoted text 28 lines
wrote: On Mon, Feb 1, 2016 at 1:40 PM, silvioprog wrote: > On Mon, Feb 1, 2016 at 3:34 PM, Dmitry Boyarintsev < > > wrote: > >> On Mon, Feb 1, 2016 at 1:23 PM, silvioprog wrote: >> >>> >>> It would be nice if the programmer could choose it from some compiler >>> switch, something like: >>> >>> {$define ifthendecl := InlineIf} >>> >>> macros? >> > > Yes, or something that allow the programmer to choose an alias to the > feature. > No matter what the language is, developers still want to write C... for the shortness of script

Speaking personally, the reason why I like Pascal syntax over C is exactly because it isn't short. I prefer the verbosity of Pascal rather than "cryptic" syntax of the C family. e.g. Pascal uses "function" not "func", "procedure" not "proc", "if then else" not "if ()", etc. Using short C-like syntax in Pascal goes against the long established style of Pascal.

Reply by email

Maciej Izak
to Sven Barth: and the only way to call it would thus be by "&if", cause only then the scanner would not…

2016-02-01 19:18 GMT+01:00 Sven Barth :

Show quoted text 8 lines
> 2. IIF should works like IfThen in Math or StrUtils. If no - It will be precedence with comparision to others languages and iif definition (!)... > https://en.wikipedia.org/wiki/IIf And you didn't read the article fully. There is one language that has an iif() intrinsic that evaluates only the taken branch: Oxygene. ;)

This is the strong argument for "iif". Mea culpa. You are the only one who is reading my links in this mailing list even better than me ;) Now I'm convinced for "iif" too. Damn.

Best regards, Maciej Izak

Reply by email

silvioprog
to Maciej Izak
Maciej Izak wrote 14 lines
2016-02-01 19:18 GMT+01:00 Sven Barth : > > 2. IIF should works like IfThen in Math or StrUtils. If no - It will be > precedence with comparision to others languages and iif definition (!)... > > > https://en.wikipedia.org/wiki/IIf > > And you didn't read the article fully. There is one language that has an > iif() intrinsic that evaluates only the taken branch: Oxygene. ;) > This is the strong argument for "iif". Mea culpa. You are the only one who is reading my links in this mailing list even better than me ;) Now I'm convinced for "iif" too. Damn.

IKTF <http://i.imgur.com/6SDcyEI.png>, bro. :-D

Silvio Clécio

Reply by email

Philippe Lévi
to Marco van de Voort

iif ... sounds good to me! +1 !
Philippe

________________________________________
De: em nome de Marco van de Voort
Enviado: segunda-feira, 1 de fevereiro de 2016 16:22 Para: FPC-Pascal users discussions
Assunto: Re: [fpc-pascal] New feature: IfThen() intrinsic

In our previous episode, Maciej Izak said:

> iif is not semantic clear. IIF means "Immediate IF". Citation: "both truepart and the falsepart will be evaluated regardless of which one is actually returned." - https://en.wikipedia.org/wiki/IIf

Well, correct that then :)

Reply by email

Marcos Douglas
to David Butler: On Mon, Feb 1, 2016 at 8:45 PM, Dmitry Boyarintsev < Speaking personally, the reason why…
David Butler wrote 5 lines
Speaking personally, the reason why I like Pascal syntax over C is exactly because it isn't short. I prefer the verbosity of Pascal rather than "cryptic" syntax of the C family. e.g. Pascal uses "function" not "func", "procedure" not "proc", "if then else" not "if ()", etc. Using short C-like syntax in Pascal goes against the long established style of Pascal.

+1

IMHO we can't use "IfThen" (or iif, IfThenElse, etc) as if it were a real function, because it is not.

So, according to the "spirit of Pascal, what do you think about this?

V := inline If Condition then ThenExpr else ElseExpr;

Only "inline" keyword will be introduced.
But I don't know if will be more hard to implement this.

Just my 2 cents...

Best,
Marcos Douglas

Reply by email

Sven Barth
to Marcos Douglas
Marcos Douglas wrote 20 lines
On Mon, Feb 1, 2016 at 5:06 PM, David Butler wrote: > Speaking personally, the reason why I like Pascal syntax over C is exactly > because it isn't short. I prefer the verbosity of Pascal rather than > "cryptic" syntax of the C family. e.g. Pascal uses "function" not "func", > "procedure" not "proc", "if then else" not "if ()", etc. Using short C-like > syntax in Pascal goes against the long established style of Pascal. +1 IMHO we can't use "IfThen" (or iif, IfThenElse, etc) as if it were a real function, because it is not. So, according to the "spirit of Pascal, what do you think about this? V := inline If Condition then ThenExpr else ElseExpr; Only "inline" keyword will be introduced. But I don't know if will be more hard to implement this.

If we would go the route of such an if-expression instead of an intrinsic then just leave away the "inline". That's absolutely not needed... (Note: implementation wouldn't be hard at all)

Regards,
Sven

Reply by email

Dmitry Boyarintsev
to Sven Barth
Sven Barth wrote
If we would go the route of such an if-expression instead of an intrinsic then just leave away the "inline". That's absolutely not needed... (Note: implementation wouldn't be hard at all)

something like this:

if if true then true else false and if false then false else true then
  writeln('syntax hurts my eyes?')

thanks,
Dmitry

Reply by email

silvioprog
to Sven Barth: If we would go the route of such an if-expression instead of an intrinsic then just leave…
Sven Barth wrote 28 lines
On 01.02.2016 20:33, Marcos Douglas wrote: > On Mon, Feb 1, 2016 at 5:06 PM, David Butler wrote: >> Speaking personally, the reason why I like Pascal syntax over C is exactly >> because it isn't short. I prefer the verbosity of Pascal rather than >> "cryptic" syntax of the C family. e.g. Pascal uses "function" not "func", >> "procedure" not "proc", "if then else" not "if ()", etc. Using short C-like >> syntax in Pascal goes against the long established style of Pascal. > > +1 > > IMHO we can't use "IfThen" (or iif, IfThenElse, etc) as if it were a > real function, because it is not. > > So, according to the "spirit of Pascal, what do you think about this? > > > V := inline If Condition then ThenExpr else ElseExpr; > > > Only "inline" keyword will be introduced. > But I don't know if will be more hard to implement this. If we would go the route of such an if-expression instead of an intrinsic then just leave away the "inline". That's absolutely not needed... (Note: implementation wouldn't be hard at all)

When you format this code (e.g using Ctrl+D) the result is a very ugly syntax:

var
  S: string;
  B: Boolen = True;
begin
  S :=
    if B then
      'A'
    else
      'B';
end;

And I think that it breaks compatibility with many Pascal syntax beautifier. IMHO Iif() (or something like this) sounds better.

Silvio Clécio

Reply by email

Marcos Douglas
to Sven Barth: If we would go the route of such an if-expression instead of an intrinsic then just leave…
Sven Barth wrote 7 lines
On 01.02.2016 20:33, Marcos Douglas wrote: > Only "inline" keyword will be introduced. > But I don't know if will be more hard to implement this. If we would go the route of such an if-expression instead of an intrinsic then just leave away the "inline". That's absolutely not needed... (Note: implementation wouldn't be hard at all)

Yes, but using 'inline' makes more readable. Like 'overload' does.

Regards,
Marcos Douglas

Reply by email

Mark Morgan Lloyd
to Sven Barth: If we would go the route of such an if-expression instead of an intrinsic then just leave…
Sven Barth wrote 24 lines
On 01.02.2016 20:33, Marcos Douglas wrote: > On Mon, Feb 1, 2016 at 5:06 PM, David Butler wrote: >> Speaking personally, the reason why I like Pascal syntax over C is exactly >> because it isn't short. I prefer the verbosity of Pascal rather than >> "cryptic" syntax of the C family. e.g. Pascal uses "function" not "func", >> "procedure" not "proc", "if then else" not "if ()", etc. Using short C-like >> syntax in Pascal goes against the long established style of Pascal. > +1 > > IMHO we can't use "IfThen" (or iif, IfThenElse, etc) as if it were a > real function, because it is not. > > So, according to the "spirit of Pascal, what do you think about this? > > > V := inline If Condition then ThenExpr else ElseExpr; > > > Only "inline" keyword will be introduced. > But I don't know if will be more hard to implement this. If we would go the route of such an if-expression instead of an intrinsic then just leave away the "inline". That's absolutely not needed... (Note: implementation wouldn't be hard at all)

And it does have to be said that ALGOL had that construct.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Sven Barth
to Dmitry Boyarintsev: On Mon, Feb 1, 2016 at 2:47 PM, Sven Barth something like this: if if true then true else…
Dmitry Boyarintsev wrote 12 lines
On Mon, Feb 1, 2016 at 2:47 PM, Sven Barth < > wrote: If we would go the route of such an if-expression instead of an intrinsic then just leave away the "inline". That's absolutely not needed... (Note: implementation wouldn't be hard at all) something like this: if if true then true else false and if false then false else true then writeln('syntax hurts my eyes?')

Everything can be abused...

Regards,
Sven

Reply by email

Sven Barth
to silvioprog: On Mon, Feb 1, 2016 at 4:47 PM, Sven Barth When you format this code (e.g using Ctrl+D)…
silvioprog wrote 50 lines
On Mon, Feb 1, 2016 at 4:47 PM, Sven Barth < > wrote: On 01.02.2016 20:33, Marcos Douglas wrote: > On Mon, Feb 1, 2016 at 5:06 PM, David Butler < > wrote: >> Speaking personally, the reason why I like Pascal syntax over C is exactly >> because it isn't short. I prefer the verbosity of Pascal rather than >> "cryptic" syntax of the C family. e.g. Pascal uses "function" not "func", >> "procedure" not "proc", "if then else" not "if ()", etc. Using short C-like >> syntax in Pascal goes against the long established style of Pascal. > > +1 > > IMHO we can't use "IfThen" (or iif, IfThenElse, etc) as if it were a > real function, because it is not. > > So, according to the "spirit of Pascal, what do you think about this? > > > V := inline If Condition then ThenExpr else ElseExpr; > > > Only "inline" keyword will be introduced. > But I don't know if will be more hard to implement this. If we would go the route of such an if-expression instead of an intrinsic then just leave away the "inline". That's absolutely not needed... (Note: implementation wouldn't be hard at all) When you format this code (e.g using Ctrl+D) the result is a very ugly syntax: var S: string; B: Boolen = True; begin S := if B then 'A' else 'B'; end; And I think that it breaks compatibility with many Pascal syntax beautifier. IMHO Iif() (or something like this) sounds better.

I honestly don't care about syntax beautifiers, are already broken for ObjFPC anyway.

Regards,
Sven

Reply by email

Martin
to Marcos Douglas: +1 IMHO we can't use "IfThen" (or iif, IfThenElse, etc) as if it were a real function,…
Marcos Douglas wrote
V := inline If Condition then ThenExpr else ElseExpr;

ignoring the "inline"

There are 3 styles (ignoring the names of identifiers used), can think of

1) function
   x :=  IfThen(a,b,c);
2) statement with return value
   x :=  If a Then b else c;

3) ternary operator
having 3 arguments, it needs at least 2 tokens to separate them

   x :=  a IfThen b else c;

Of course the operator can have a leading token, and the statement syntax could be an operator.

In cases 2 and 3 (operator) precedences become an issue (unless a
terminating "end" is required)
   x :=  If a Then b else c + 3;
should be which
   x :=  (If a Then b else c) + 3;
   x :=   If a Then b else (c + 3);

So function style has the build in clarity on this. But it can be confused with existing functions of the same name.

Reply by email

silvioprog
to Sven Barth: I honestly don't care about syntax beautifiers, are already broken for ObjFPC anyway.…

On Mon, Feb 1, 2016 at 5:10 PM, Sven Barth
wrote:
[...]

Show quoted text 20 lines
> When you format this code (e.g using Ctrl+D) the result is a very ugly > syntax: > > var > S: string; > B: Boolen = True; > begin > S := > if B then > 'A' > else > 'B'; > end; > > And I think that it breaks compatibility with many Pascal syntax > beautifier. IMHO Iif() (or something like this) sounds better. I honestly don't care about syntax beautifiers, are already broken for ObjFPC anyway.

But if it will be done using some syntax like this, it should use an additional identifier (inline, as it has been suggested). Anyway, this Pascal abbreviation sounds very strange, "if B is true, so A, else B". I can't see it in other place. :-D Usually we listen something like "if B is true, so something get 'A', otherwise something get 'B'".

You can extend the ObjFPC syntax adding this new abbreviations to make it more Pascal keyword style, but please keep some function like IfThen() (or something like this), it is very useful for who that already use it from other many languages.

Silvio Clécio

Reply by email

Roberto P.
to Philippe Lévi: iif ... sounds good to me! +1 ! Philippe ________________________________________ De: …

Maybe we shouldn't focus all that much on the " if " word..since all in all, it is meant to be differently from the language if-then-else What about using another word suggesting a choice?

   j := Switch(i < 32, 48, 21);
   j := Select(i < 32, 48, 21);
   j := Which(i < 32, 48, 21);

They look to me as a goog compromise between expressiveness (IfThen) and typing-laziness (iif).

Roberto

2016-02-01 20:24 GMT+01:00 Philippe Lévi :

Show quoted text 25 lines
iif ... sounds good to me! +1 ! Philippe ________________________________________ De: < > em nome de Marco van de Voort < > Enviado: segunda-feira, 1 de fevereiro de 2016 16:22 Para: FPC-Pascal users discussions Assunto: Re: [fpc-pascal] New feature: IfThen() intrinsic In our previous episode, Maciej Izak said: > > > iif is not semantic clear. IIF means "Immediate IF". Citation: "both > truepart and the falsepart will be evaluated regardless of which one is > actually returned." - https://en.wikipedia.org/wiki/IIf Well, correct that then :) _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply by email

Philippe Lévi
to Roberto P.

I thought about "condEval( cnd, true, false);"

we are looking for a name of a function ... and "if" is a statment ... variations of "if" still have the flavour of statment name ...

Philippe

________________________________
De: em nome de Roberto P.
Enviado: segunda-feira, 1 de fevereiro de 2016 19:34 Para: FPC-Pascal users discussions
Assunto: Re: [fpc-pascal] New feature: IfThen() intrinsic

Maybe we shouldn't focus all that much on the " if " word..since all in all, it is meant to be differently from the language if-then-else What about using another word suggesting a choice?

   j := Switch(i < 32, 48, 21);
   j := Select(i < 32, 48, 21);
   j := Which(i < 32, 48, 21);

They look to me as a goog compromise between expressiveness (IfThen) and typing-laziness (iif).

Roberto

2016-02-01 20:24 GMT+01:00 Philippe Lévi :
iif ... sounds good to me! +1 !
Philippe

________________________________________
De: em nome de Marco van de Voort
Enviado: segunda-feira, 1 de fevereiro de 2016 16:22 Para: FPC-Pascal users discussions
Assunto: Re: [fpc-pascal] New feature: IfThen() intrinsic

In our previous episode, Maciej Izak said:

> iif is not semantic clear. IIF means "Immediate IF". Citation: "both truepart and the falsepart will be evaluated regardless of which one is actually returned." - https://en.wikipedia.org/wiki/IIf

Well, correct that then :)

Reply by email

Dennis
to Roberto P.: Maybe we shouldn't focus all that much on the " if " word..since all in all, it is meant…
Roberto P. wrote 13 lines
Maybe we shouldn't focus all that much on the " if " word..since all in all, it is meant to be differently from the language if-then-else What about using another word suggesting a choice? j := Switch(i < 32, 48, 21); j := Select(i < 32, 48, 21); j := Which(i < 32, 48, 21); They look to me as a goog compromise between expressiveness (IfThen) and typing-laziness (iif). Roberto

Switch, Select, Which
are all good except that they are very common English words. They might already be used by users in existing function names in their code.

I prefer

V := If Condition then ThenExpr else ElseExpr;

Beginners to Free Pascal can easily guess its meaning just by its look.

Dennis

Reply by email

Dennis Poon
to Jürgen Hestermann
Jürgen Hestermann wrote 8 lines
Am 2016-02-01 um 19:45 schrieb Dmitry Boyarintsev: > No matter what the language is, developers still want to write C... > for the shortness of script Such people should simply use C. Pascal C and I am glad that this is true.

In my humble opinion, the importance of "Shortness of script" is overrated.

Ease of reading and maintaining the code is far more important. Programmers spend most of their time debugging and modifying/extending existing code, not in writing the first draft of code.

Object Pascal excels in this area. That's why I like pascal much more than C.

Dennis

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply by email

LacaK
to Dennis: Switch, Select, Which are all good except that they are very common English words. They…
Show quoted text 7 lines
Switch, Select, Which are all good except that they are very common English words. They might already be used by users in existing function names in their code. I prefer V := If Condition then ThenExpr else ElseExpr;

+1
(for me is "if ... then ... else" also good understandable and looks nice; plus if it has precendence in other language (Oxygene) it is advantage also)

-Laco.

Reply by email

Maciej Izak
to Michael Schnell: It's iif in Oxygen. So why not keep that name ? -Michael

2016-02-01 10:59 GMT+01:00 Michael Schnell :

Show quoted text 9 lines
On 02/01/2016 09:35 AM, David Butler wrote: > > > Maybe call it "inlineif" or "iif", e..g > > x := iif (a < 3, 1, 2) > > It's iif in Oxygen. So why not keep that name ?

Same here. I see no reason to differ from it. Introducing new incompatibility is bad idea. For me is good to have booth (Oxygene compatible):

x := iif (a < 3, 1, 2);
V := If a < 3 then 1 else 2;

sometimes is better to use first option and sometimes is better to use second option. Both Oxygen compatible and very "pascalish".

Best regards, Maciej Izak

Reply by email

Maciej Izak
to Maciej Izak

2016-02-02 8:22 GMT+01:00 Maciej Izak :

Show quoted text 23 lines
2016-02-01 10:59 GMT+01:00 Michael Schnell : > On 02/01/2016 09:35 AM, David Butler wrote: > >> >> >> Maybe call it "inlineif" or "iif", e..g >> >> x := iif (a < 3, 1, 2) >> >> It's iif in Oxygen. So why not keep that name ? Same here. I see no reason to differ from it. Introducing new incompatibility is bad idea. For me is good to have booth (Oxygene compatible): x := iif (a < 3, 1, 2); V := If a < 3 then 1 else 2; sometimes is better to use first option and sometimes is better to use second option. Both Oxygen compatible and very "pascalish".

we can even mix to gain more clear code:

foo :=
  if Condition1 then
    iif(Condition2, ThenExpr1, ElseExpr1)
  else
    iif(Condition3, ThenExpr2, ElseExpr2);

much more readable than:

if Condition1 then
begin
  if Condition2 then
    foo := ThenExpr1
  else
    foo := ElseExpr1
end else
begin
  if Condition3 then
    foo := ThenExpr2
  else
    foo := ElseExpr2
end;
Best regards, Maciej Izak

Reply by email

Anthony Walter
to Sven Barth: Hello together! I've finally come around to add a feature that many people have asked for…

Sven,

I missed this post when you made it a two days ago. If someone hasn't already asked, does your implementation support short circuit evaluation?

For example:

BasketCount := IfThen(ShoppingList  nil, ShoppingList.Count, 0);

Where evaluating ShoppingList.Count will cause an exception if ShoppingList is nil.

Also the reverse should short circuit as well:

BasketCount := IfThen(ShoppingList = nil, 0, ShoppingList.Count);

Reply by email

Mark Morgan Lloyd
to LacaK: +1 (for me is "if ... then ... else" also good understandable and looks nice; plus if it…
LacaK wrote 11 lines
> Switch, Select, Which > are all good except that they are very common English words. They > might already be used by users in existing function names in their code. > > I prefer > > V := If Condition then ThenExpr else ElseExpr; +1 (for me is "if ... then ... else" also good understandable and looks nice; plus if it has precendence in other language (Oxygene) it is advantage also)

Plus it has precedenence in at least some ALGOL implementations (a quick read of my fading manual doesn't show whether it was still in ALGOL W). I've never understood why it was omitted from Pascal, although somebody's comment about operator priority and the heavy going that some texts make of describing nesting suggest that there are hazards, at least for people who aren't already familiar with the language.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Michael Van Canneyt
to Maciej Izak: 2016-02-02 8:22 GMT+01:00 Maciej Izak : we can even mix to gain more clear code: foo :=…
Maciej Izak wrote 9 lines
we can even mix to gain more clear code: foo := if Condition1 then iif(Condition2, ThenExpr1, ElseExpr1) else iif(Condition3, ThenExpr2, ElseExpr2); much more readable than:

Call me old fashioned, but then I think

   foo:=iif(Condition1,
            iif(Condition2, ThenExpr1, ElseExpr1),
            iif(Condition3, ThenExpr2, ElseExpr2));

is more clear.

The "if then" construct is really confusing.
"if then" is a statement, not an expression.

Michael.

Reply by email

Felipe Monteiro de Carvalho
to Michael Van Canneyt

If other people already use "iif" then maybe it is better to use the same name?

Also I vaguely remember at least a few functions in existing code named IfThen which would conflict with the new one.

But "iif", well I never saw anyone name a function like that...

Felipe Monteiro de Carvalho

Reply by email

Maciej Izak
to Michael Van Canneyt: Call me old fashioned, but then I think iif(Condition2, ThenExpr1, ElseExpr1),…

2016-02-02 10:07 GMT+01:00 Michael Van Canneyt :

Show quoted text 8 lines
Call me old fashioned, but then I think foo:=iif(Condition1, iif(Condition2, ThenExpr1, ElseExpr1), iif(Condition3, ThenExpr2, ElseExpr2)); is more clear. The "if then" construct is really confusing. "if then" is a statement, not an expression.

Yup, you are old fashioned :).

maybe is good idea to discuss "it then else" expression in dedicated thread "if-then-else expression".

conclusion of this thread:

*the best new name for "IfThen intrinsic" is iif*

unless someone has a good opposite arguments? Pros for iif:

- no conflicts with existing RTL code base (in this matter much much better than IfThen)
- compatible with existing pascal solution (Oxygene)
- short and logical name

Cons:
- a little different behavior than in other languages (but still compatible with Oxygene)
- I like &if ;)

Best regards, Maciej Izak

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt: Call me old fashioned, but then I think iif(Condition2, ThenExpr1, ElseExpr1),…
Michael Van Canneyt wrote
The "if then" construct is really confusing. "if then" is a statement, not an expression.

Exactly! I'm glad somebody noticed that too.

I'm fine with the iif() syntax. It is used in a few languages for many years, so is a common and known name.

Then again, I really don't know what the issue is here, because it is so simple to implement your own in Object Pascal. For example, the tiOPF's tiUtils.pas unit has had it for over 15 years now.

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp

Reply by email

Marco van de Voort
to Maciej Izak: 2016-02-02 10:07 GMT+01:00 Michael Van Canneyt : Yup, you are old fashioned :). maybe is…

In our previous episode, Maciej Izak said:

Show quoted text 12 lines
*the best new name for "IfThen intrinsic" is iif* unless someone has a good opposite arguments? Pros for iif: - no conflicts with existing RTL code base (in this matter much much better than IfThen) - compatible with existing pascal solution (Oxygene) - short and logical name Cons: - a little different behavior than in other languages (but still compatible with Oxygene)

How is it different behaviour from C then? The only practical application that I see is in from C conversions (like ++ and --), so that you don't have to rethink complex expressions that some @( thought up.

Of course one can find an use for any syntactic sugar, but then we should give up making a pascal, and simply declare FPC as the superset of all languages.

- I like &if ;)

I don't see the point. And if a funky character is needed then use another one, don't add a third overload to &. (statement to intrinsic instead of statement to identifier and octal)

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys: Exactly! I'm glad somebody noticed that too. I'm fine with the iif() syntax. It is used…
Graeme Geldenhuys wrote 12 lines
On 2016-02-02 09:07, Michael Van Canneyt wrote: > The "if then" construct is really confusing. > "if then" is a statement, not an expression. Exactly! I'm glad somebody noticed that too. I'm fine with the iif() syntax. It is used in a few languages for many years, so is a common and known name. Then again, I really don't know what the issue is here, because it is so simple to implement your own in Object Pascal. For example, the tiOPF's tiUtils.pas unit has had it for over 15 years now.

Try this (A a component or class with property Name):

N:=iif(Assigned(A),A.Name,'Nil');

You'll get a crash using regular functions because All arguments are evaluated prior to calling iif().

If IIF() is an intrinsic, then the compiler will only evaluate the argument that corresponds to the condition.

Michael.

Reply by email

Michael Van Canneyt
to Maciej Izak: 2016-02-02 10:07 GMT+01:00 Michael Van Canneyt : Yup, you are old fashioned :). maybe is…
Maciej Izak wrote 20 lines
2016-02-02 10:07 GMT+01:00 Michael Van Canneyt : > Call me old fashioned, but then I think > foo:=iif(Condition1, > iif(Condition2, ThenExpr1, ElseExpr1), > iif(Condition3, ThenExpr2, ElseExpr2)); > is more clear. > > The "if then" construct is really confusing. > "if then" is a statement, not an expression. Yup, you are old fashioned :). maybe is good idea to discuss "it then else" expression in dedicated thread "if-then-else expression". conclusion of this thread: *the best new name for "IfThen intrinsic" is iif*

I have no problem with this conclusion, I use IIF() since years. It exists in many other languages/tools, so it makes sense to use that. To my knowledge it has no conflicts with existing unit identifiers in code we distribute.

Michael.

Reply by email

Michael Schnell
to Graeme Geldenhuys: Exactly! I'm glad somebody noticed that too. I'm fine with the iif() syntax. It is used…
Graeme Geldenhuys wrote
Exactly! I'm glad somebody noticed that too.

Of course I did notice :-) .

V := If a < 3 then 1 else 2;

In fact extends a several language paradigms:

- a keyword (such as "if") returns a value
- a statement (such as "if ....", and the content of an if clause ) returns a value
- an expression (such as "1") is accepted as a statement (and hence allowed in a n if clause)

This _might_ be viable and doable, as its a pure optional extension.

-Michael

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt: Try this (A a component or class with property Name): N:=iif(Assigned(A),A.Name,'Nil');…
Michael Van Canneyt wrote 5 lines
N:=iif(Assigned(A),A.Name,'Nil'); You'll get a crash using regular functions because All arguments are evaluated prior to calling iif().

Okay, fair enough. Thanks for the example.

Then again, it is a relatively small corner case. I've not hit that issue in 15+ years using tiUtils. Maybe I was just lucky. ;-) Either way, I understand better now.

Regards,
- Graeme -

Reply by email

Maciej Izak
to Marco van de Voort: In our previous episode, Maciej Izak said: How is it different behaviour from C then? The…

2016-02-02 10:38 GMT+01:00 Marco van de Voort :

Show quoted text 13 lines
> - a little different behavior than in other languages (but still compatible > with Oxygene) How is it different behaviour from C then? The only practical application that I see is in from C conversions (like ++ and --), so that you don't have to rethink complex expressions that some @( thought up. Of course one can find an use for any syntactic sugar, but then we should give up making a pascal, and simply declare FPC as the superset of all languages.

I mean only IIF definition/behavior like in VB. In C exist "?:" conditional operator, different story.

Show quoted text 6 lines
> - I like &if ;) I don't see the point. And if a funky character is needed then use another one, don't add a third overload to &. (statement to intrinsic instead of statement to identifier and octal)

";)" emoticon means joke/not serious. Damn, you are really old fashioned.

the fact is one: iif is good new name for "IfThen" intrinsic.

I don't have any more to say.

Best regards, Maciej Izak

Reply by email

Michael Van Canneyt
to Maciej Izak
Maciej Izak wrote 10 lines
2016-02-02 10:38 GMT+01:00 Marco van de Voort : > > I don't see the point. And if a funky character is needed then use another > one, don't add a third overload to &. (statement to intrinsic instead of > statement to identifier and octal) ";)" emoticon means joke/not serious. Damn, you are really old fashioned. the fact is one: iif is good new name for "IfThen" intrinsic.

You see, we managed to find common ground :-)

Michael.

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys: Okay, fair enough. Thanks for the example. Then again, it is a relatively small corner…
Graeme Geldenhuys wrote 14 lines
On 2016-02-02 09:44, Michael Van Canneyt wrote: > > N:=iif(Assigned(A),A.Name,'Nil'); > > You'll get a crash using regular functions because All arguments are > evaluated prior to calling iif(). Okay, fair enough. Thanks for the example. Then again, it is a relatively small corner case. I've not hit that issue in 15+ years using tiUtils. Maybe I was just lucky. ;-) Either way, I understand better now.

Well, you must have been lucky indeed.
I hit it regularly in logging statements.

Michael.

Reply by email

Sven Barth
to Anthony Walter: I missed this post when you made it a two days ago. If someone hasn't already asked, does…
"Anthony Walter" wrote
Sven, I missed this post when you made it a two days ago. If someone hasn't

already asked, does your implementation support short circuit evaluation?

Show quoted text 6 lines
For example: BasketCount := IfThen(ShoppingList nil, ShoppingList.Count, 0); Where evaluating ShoppingList.Count will cause an exception if

ShoppingList is nil.

Also the reverse should short circuit as well: BasketCount := IfThen(ShoppingList = nil, 0, ShoppingList.Count);

You're mixing up two things. Short circuit evaluation in terms of Pascal is that in expressions using "and" and "or" the evaluation is aborted if the result is already determined. This is controlled by a compiler directive and is respected by all Boolean expressions.
What you mean is that the compiler does not evaluate all branches of the if and that is the main reason I introduced this intrinsic. In fact the IfThen() behaves just like an ordinary if-statement in that regard as I had mentioned in my original mail.

Regards,
Sven

Reply by email

Sven Barth
to Marco van de Voort: In our previous episode, Maciej Izak said: How is it different behaviour from C then? The…
"Marco van de Voort" wrote 5 lines
> - I like &if ;) I don't see the point. And if a funky character is needed then use another one, don't add a third overload to &. (statement to intrinsic instead of statement to identifier and octal)

He meant to use "if" as the name for the intrinsic which requires it to be called as "&if(...)" which would merely be a use of the identifier escape.

Regards,
Sven

Reply by email

Sven Barth
to Felipe Monteiro de Carvalho: If other people already use "iif" then maybe it is better to use the same name? Also I…

Am 02.02.2016 10:20 schrieb "Felipe Monteiro de Carvalho" <

: If other people already use "iif" then maybe it is better to use the same

name?

Also I vaguely remember at least a few functions in existing code named IfThen which would conflict with the new one.

That's one of the main arguments that let this thread explode...

But "iif", well I never saw anyone name a function like that...

Michael Van Canneyt AFAIK?

Regards,
Sven

Reply by email

Mark Morgan Lloyd
to Michael Van Canneyt: Call me old fashioned, but then I think iif(Condition2, ThenExpr1, ElseExpr1),…
Michael Van Canneyt wrote 8 lines
Call me old fashioned, but then I think foo:=iif(Condition1, iif(Condition2, ThenExpr1, ElseExpr1), iif(Condition3, ThenExpr2, ElseExpr2)); is more clear. The "if then" construct is really confusing. "if then" is a statement, not an expression.

Yes, and that's why to get the desired semantics it's more appropriate to use if then else rather than iif() etc.

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.

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.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Michael Van Canneyt
to Sven Barth: Am 02.02.2016 10:20 schrieb "Felipe Monteiro de Carvalho" < name? That's one of the main…
Sven Barth wrote 14 lines
Am 02.02.2016 10:20 schrieb "Felipe Monteiro de Carvalho" < >: > > If other people already use "iif" then maybe it is better to use the same name? > > Also I vaguely remember at least a few functions in existing code > named IfThen which would conflict with the new one. That's one of the main arguments that let this thread explode... > But "iif", well I never saw anyone name a function like that... Michael Van Canneyt AFAIK?

At least Firebird & Microsoft SQL Server and MS-Access contain it. FastReport uses it.

I use this since 15+ years, I didn't make up this name myself :-)

Michael.

Reply by email

Michael Van Canneyt
to Mark Morgan Lloyd: Yes, and that's why to get the desired semantics it's more appropriate to use if then…
Mark Morgan Lloyd wrote 20 lines
Michael Van Canneyt wrote: > Call me old fashioned, but then I think > foo:=iif(Condition1, > iif(Condition2, ThenExpr1, ElseExpr1), > iif(Condition3, ThenExpr2, ElseExpr2)); > is more clear. > > The "if then" construct is really confusing. > "if then" is a statement, not an expression. Yes, and that's why to get the desired semantics it's more appropriate to use if then else rather than iif() etc. 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.

I cannot remember a single case in 25+ years where I had to pay attention to this.

I think that people who rely on the order of the arguments evaluation need to rethink/restructure their code, because their code is IMHO fundamentally flawed: it is not think you should write robust code. And the reason is simple:

I can say with relative confidence that most programmers in my company can't even tell you what the order is, much less that they should respect it, even after 10 years of programming. So if they were to get their hands on code that does rely on it: no way to tell what would happen.

Hence, I think code relying on order of evaluation is not 'robust' at all.

(that said, I do understand that the compiler must understand and keep a strict order.)

Michael.

Reply by email

Mark Morgan Lloyd
to Michael Van Canneyt
Michael Van Canneyt wrote 21 lines
On Tue, 2 Feb 2016, Mark Morgan Lloyd wrote: >> The "if then" construct is really confusing. >> "if then" is a statement, not an expression. > > Yes, and that's why to get the desired semantics it's more appropriate > to use if then else rather than iif() etc. > > 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. I cannot remember a single case in 25+ years where I had to pay attention to this. I think that people who rely on the order of the arguments evaluation need to rethink/restructure their code, because their code is IMHO fundamentally flawed: it is not Jonas points, out, this is absolutely nothing to do with order of

evaluation (unless, by some stretch of semantics, you fold "whether" into "order" :-)

The only way that you can fairly implement an ifthen() or, in the general case, some sort of select() function, is if you convert the code fragments to be executed into anonymous functions and pass references to those as individuals or as an array for late evaluation. And that's basically the sort of hack that was derided in ALGOL.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

silvioprog
to Michael Van Canneyt: Call me old fashioned, but then I think iif(Condition2, ThenExpr1, ElseExpr1),…
Michael Van Canneyt wrote 15 lines
On Tue, 2 Feb 2016, Maciej Izak wrote: > we can even mix to gain more clear code: > > foo := > if Condition1 then > iif(Condition2, ThenExpr1, ElseExpr1) > else > iif(Condition3, ThenExpr2, ElseExpr2); > > much more readable than: > Call me old fashioned, but then I think

I don't think you are old fashioned. :-)

Show quoted text 5 lines
foo:=iif(Condition1, iif(Condition2, ThenExpr1, ElseExpr1), iif(Condition3, ThenExpr2, ElseExpr2)); is more clear.

+1.

The "if then" construct is really confusing. "if then" is a statement, not an expression.

I think strange this logic on the code above, and I totally agree with you. If it was accepted to ObjFPC, it would be the first language to accepet an `if` statement as an expression, sounding as an abbreviation in the language.

Silvio Clécio

Reply by email

Sven Barth
to Mark Morgan Lloyd: Yes, and that's why to get the desired semantics it's more appropriate to use if then…

Am 02.02.2016 11:42 schrieb "Mark Morgan Lloyd" <

Show quoted text 15 lines
: Michael Van Canneyt wrote: > Call me old fashioned, but then I think > foo:=iif(Condition1, > iif(Condition2, ThenExpr1, ElseExpr1), > iif(Condition3, ThenExpr2, ElseExpr2)); > is more clear. > > The "if then" construct is really confusing. > "if then" is a statement, not an expression. Yes, and that's why to get the desired semantics it's more appropriate to

use if then else rather than iif() etc.

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.

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.

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. Same with the IfThen-intrinsic I had added, it only evalutes the branch that is taken.
Please note that intrinsics are the exception, not the rule.

Regards,
Sven

Reply by email

John Lee
to Sven Barth
Sigh, thought everyone (eventually) agreed that we'd change to algol/ada
x:=if a>b then 1 else 2; so why are we going on & on & on about this?

john

Sven Barth wrote 44 lines
Am 02.02.2016 11:42 schrieb "Mark Morgan Lloyd" < >: > > Michael Van Canneyt wrote: > >> Call me old fashioned, but then I think >> foo:=iif(Condition1, >> iif(Condition2, ThenExpr1, ElseExpr1), >> iif(Condition3, ThenExpr2, ElseExpr2)); >> is more clear. >> >> The "if then" construct is really confusing. >> "if then" is a statement, not an expression. > > > Yes, and that's why to get the desired semantics it's more appropriate to use if then else rather than iif() etc. > > 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. > > 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. 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. Same with the IfThen-intrinsic I had added, it only evalutes the branch that is taken. Please note that intrinsics are the exception, not the rule. Regards, Sven _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply by email

Jürgen Hestermann
to Mark Morgan Lloyd: Yes, and that's why to get the desired semantics it's more appropriate to use if then…
Mark Morgan Lloyd wrote 5 lines
Michael Van Canneyt wrote: Yes, and that's why to get the desired semantics it's more appropriate to use if then else rather than iif() etc. 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.

Yes, I fully agree.
If the behaviour is/will be exactly the same as "if .. then ... else" then it should also get a name that shows this clearly.
Therefore, I would still vote for "IfThenElse(.. , .. , ..)". "InlineIf(.. , .. , ..)" would be ok too but not as clear as "IfThenElse".

If "IIF" in other languages is more of a function in these languages (so both branches are evaluated in all cases) then I would not use the same name in Pascal but implement a different behaviour. Would this be possible in other languages:

var c : char;
     s : string;
c := IfThenElse(Length(s)=0,' ',S[1]);

?

Reply by email