functional IF

[jamie]

However as a counterexample I'd like to highlight the ALGOL-style conditional expression that Wirth unaccountably omitted from Pascal:

Code: [Select]

  a := if b then c else d;

since this can't easily be emulated using a function and is such a common idiom in mainstream ALGOL derivatives- by which I of course mean C etc.- that its absence is embarrassing.

Hasn't there has been talk about this, ifthen() becoming an intrinsic and only evaluating the sides as necessary.   (because objective pascal needed it???)

I don't know if it happened in the end. Maybe Pascaldragon knows.

I had added it back in January 2016 (see announcement mail of which the thread continued into February). After some heated discussions both on the public mailing list as well as the core one I removed it again in February. The addition of the intrinsic is still part of the version history and I think somewhere I still have a patch for the if … then … else - expression (alternatively it would be easily derivable from the provided commit for the IfThen intrinsic).

You keep threatening us with that addition!, I am still waiting!

 Show me the code so I can convert these C programs over better since they are loaded with things like that and need to really do some heavy workarounds to avoid unwanted function calls.
 
 Also, This  If then Else etc should work nested wise too! 

 I am not asking for must, just show me the CODE! 

Jamie

[Thaddy]

Regarding the ifthen intrinsic that did not last long, there is now something similar in main because of implicit function specialization. It is also nestable.
[slight mod done later]

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

1. {$mode delphi}{$h+}
2. {$modeswitch implicitfunctionspecialization}
3. {$modeswitch functionreferences}
4. uses
5.   sysutils;
6.  
7. type
8.   TMyref = reference to procedure;
9.  
10.   procedure test1;
11.   begin
12.     writeln('test1');
13.   end;
14.  
15.   procedure test2;
16.   begin
17.     writeln('test2');
18.   end;
19.  
20. var
21.   a:integer = 100;b:integer = 50;
22.   c:string = 'test';d:string = 'test';
23.   e:double = 1.0;f:double = 1.0;
24.   g,h:TMyref;
25. begin
26.   g := test1;
27.   h := test2;
28.   ifthen(true,g,h)();
29.   ifthen(false,g,h)();
30.   writeln(ifthen(b < a,b,a));                
31.   writeln(ifthen(c = d,'equal','not equal'));
32.   c := extract(d);
33.   writeln(ifthen(c = d,'equal','not equal'));
34.   writeln(ifthen(e = f,e,f):2:2);
35. end.

[jamie]

@thaddy
  Not the same and never will be unti the operation is intrinsic to avoid executing unwanted code.

[Thaddy]

I know, but it is close and has very little speed penalty due to the nature of generics.

[Warfley]

Was bored and wanted to see how long it takes to build something like that:

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

1. var
2.   s: string;
3. begin
4.   s := if 0 < 1 then 'Foo' else 'Bar';
5.   WriteLn(s);
6. end.

It's roughly 30 lines of code and took 15 minutes to create the attached patch for fpc main

[jamie]

Was bored and wanted to see how long it takes to build something like that:

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

1. var
2.   s: string;
3. begin
4.   s := if 0 < 1 then 'Foo' else 'Bar';
5.   WriteLn(s);
6. end.

It's roughly 30 lines of code and took 15 minutes to create the attached patch for fpc main

Does it work for a parameter inside a function parms list ?

Can the foo or bar be replaced with another construct of this to return the value, nested?
Jamie

[Warfley]

It's a completely normal expression you can use anywhere. The type of the expression is the type of the result of the if branch. That said, I have not looked to much into where in the operator precedence it falls, so best to use brackets, but the following should work just fine:

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

1. s := if cond1 then 'Foo' else
2.      if cond2 then 'Bar' else
3.      'Baz';

When you use incompatible types it will show on the else branch:

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

1. s := if 0<1 then 'Foo'
2.      else 32; // Error expected StringConstant got ShortInt

[Fibonacci]

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

1. uses SysUtils;
2. var
3.   s: string;
4. begin
5.   s := 'test';
6.   writeln(if (if s = 'test' then 0 else 1) < 1 then if GetTickCount <> 123 then FormatDateTime('hh.nn.ss', Now+if true then 1 else 0) else 'Foo' else 'Bar');

Awesome, merge it

[jamie]

Yes, please meege and relase fpc with that in it. Ill put my delphi away.

[MarkMLl]

Yes, please meege and relase fpc with that in it. Ill put my delphi away.

I certainly feel it would be worth getting that into the feature-request list, since it was a feature missing from Wirth's original language rather than just-another-recently-tacked-on-frill. Even if we expect the core team to continue to reject such things.

MarkMLl

[Warfley]

Creating the patch was the easy part, if I wanted to make a merge request it would take at least double the time to make test cases for it lol

But aside from that, I'm not happy with it, because it's a bit weird to have this for if but not for other statements. What about case?

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

1. s := case state of
2.   0: 'Foo';
3.   1: 'Bar';
4.   2: 'Baz';
5.   else 'FooBar';
6. end;

Or what about try-except:

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

1. s := try functionThatCanFail() except 'Error';

And when try-except is in there, what about raise:

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

1. s := try functionThatCanFail() except on E: ESomeException do 'Bar' except raise;

Also useful for incomplete cases:

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

1. s := case State of
2. 1: 'Foo';
3. 2: 'Bar';
4. else raise EUnknownState.Create(state);
5. end;

[jamie]

Well, either way, as long as it returns as a result.

If long as we can do that as an expression that works well too and may look cleaner.

Jamie

[440bx]

the posts about implementing the if else as an rvalue should probably be split into another thread as that has nothing to do with break out early of a case statement.

[MarkMLl]

Creating the patch was the easy part, if I wanted to make a merge request it would take at least double the time to make test cases for it lol

I'm tempted to ask "what can we do to help?" but since the patch took you 15 minutes it would probably take more than 30 for you to explain the additional detail :-)

But aside from that, I'm not happy with it, because it's a bit weird to have this for if but not for other statements. What about case?

That's a possibility I've raised in the past, but I'd make two comments.

First, the if-then-else expression was in ALGOL-60 and, via C, is in most of its derivatives. There is no general acceptance of an if-case-else expression, although I suspect that aspects of it overlap with some of the tuple handling that I believe Sverah has looked at.

Second, Pascal's case statement does not have a mandatory else/otherwise part, but a case expression would have to have one.

Third, if <expression> then <statement-or-expression1> else <statement-or-expression2> associates a boolean true (variously described as either <expression> evaluating to 1 or to non-zero) with <statement-or-expression1>. However, one would reasonably expect a case-else expression to evaluate from zero upwards, which immediately gets conceptually messy. (Detail: I've tackled this in the scripting stuff that runs my business, and ended up defining distinct expressions to handle the two variants).

OK, that's three. Sorry. If I had to rate them, I'd say that they're already in order of importance.

MarkMLl

[440bx]

All of this is off-topic.

Please get back on topic, which is, breaking out early of a case statement.