functional IF

[Warfley]

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

If you want to, just write tests. Positive tests like:

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

1. var
2.   s: String;
3. begin
4.   s := if 0 < 1 then 'Foo' else
5.        if 1 < 2 then 'Bar' else
6.        'Baz';
7.   WriteLn(s);
8.   if (s<>'Foo') then
9.     Halt(1);
10. end.
11.  

Or negative tests like:

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

1. {%FAIL}
2. var
3.   s: String;
4. begin
5.   s := if 0 < 1 then 'Foo' else 32;
6.   Halt(1);
7. end.

But the reason I just put a little patch here instead of creating a merge request is simply because I don't think this would be accepted. It's a very small update which, if you look a the intrinsic already was commited, but not accepted. And while I personally think doing it as an intrinsic is a bad idea (if it looks like a function it should behave like a function, while the explicit purpose of this is to not behave like a function), I don't think things are different for this.

Also I still have a long list of merge requests from last year I did not have the time to follow up on, so I don't want to open another. That said, I might work a bit more on this patch just for funsies and see where it is going

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

The thing with case is quite simply it's first very efficient, but more so allows to easily compare multiple values like:

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

1. case State of
2. 2, 5, 8, 10..15: 'Foo'
3. else 'Bar'

Would be in if-then-else:

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

1. if (state=2) or (state=5) or (state=8) or ((state>=10) and (state<=15)) then 'Foo' else 'Bar'

And yeah, case needs to either be exhaustive, or have an else statement, or another solution would be to raise an error (maybe even re-use range errors) when the value falls outside of the covered cases.

[jamie]

Those that don't want it don't need to use it, correct?

I mean, its not going to change the rest of the compiler's functionality.

I personally would like to see that intrinsic of at least the IF <Boolean> THen ,,,,,,

As for the CASE, that I can see would get a little messy however, I guess you could also include that too, and like I said, those that don't like it don't need to use it, period!

  I use the IFThen a lot but it really suffers when calling functions for the results. it should work like a real iF then else etc.

 Of course, Delphi does not have this, yet but that isn't an excuse. Give them time and they will have it too.

Jamie

[Thaddy]

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

If you accept that ISO 10206 is an extension to ISO 7185 then, according to the standard, otherwise is mandatory if not all cases are covered. The  compiler throws a warning in all dialects but ExtPas where it should throw an error.

[MarkMLl]

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

If you accept that ISO 10206 is an extension to ISO 7185 then, according to the standard, otherwise is mandatory if not all cases are covered. The  compiler throws a warning in all dialects but ExtPas where it should throw an error.

It's mandatory in Modula-2 as well, and I always use it as a point of good practice.

MarkMLl

[440bx]

It's mandatory in Modula-2 as well, and I always use it as a point of good practice.

MarkMLl

Talking about "good practice"... good practice includes abstaining from posting off-topic material particularly when you and the others have been explicitly asked not to.

Keep talking about "good practice"... your behavior and that of others really show how much you care about it.

[Joanna]

440bx
It is easy to break out early from a case statement just put your code inside a procedure or function and call that from inside the case statement. The procedure/function can contain an exit.

[440bx]

440bx
It is easy to break out early from a case statement just put your code inside a procedure or function and call that from inside the case statement. The procedure/function can contain an exit.

that solution is obvious but it has the _severe_ downside that the code is all over the place instead of in a single block.

[bytebites]

that solution is obvious but it has the _severe_ downside that the code is all over the place instead of in a single block.

Why don't you follow your own rule?

[440bx]

that solution is obvious but it has the _severe_ downside that the code is all over the place instead of in a single block.

Why don't you follow your own rule?

I do follow my own rules.  One of them is that if someones asks a question, the polite thing to do is to provide an answer.  I provided a short one because, in this thread, her question is off-topic and consequently so is the answer but, being polite took precedence.

If you or her, asks additional off-topic questions then I will inform you or her that there will be no answer because the question is off-topic.  I hope that clarified my rules for you.

[bytebites]

that solution is obvious but it has the _severe_ downside that the code is all over the place instead of in a single block.

Why don't you follow your own rule?

I do follow my own rules.  One of them is that if someones asks a question, the polite thing to do is to provide an answer.  I provided a short one because, in this thread, her question is off-topic and consequently so is the answer but, being polite took precedence.

If you or her, asks additional off-topic questions then I will inform you or her that there will be no answer because the question is off-topic.  I hope that clarified my rules for you.

Mark was polite too. So the rule is invent new rule if you want follow a rule.

[440bx]

Mark was polite too. So the rule is invent new rule if you want follow a rule.

You're off topic.

[Joanna]

440bx you can put the code in a procedure declared inside the current procedure where the case statement is located. That would definitely not be “all over the place“. If this is not possible I’m curious to see your code.
How many lines long is your procedure?

[bytebites]

Mark was polite too. So the rule is invent new rule if you want follow a rule.

You're off topic.

Says forum cop.

[creaothceann]

While I'm not that fond of if (littering the code with branches doesn't sound very helpful, unless it is known that the conditions follow a pattern at runtime and aren't random) it looks like a way to save a little bit of typing.

I'd rather have a way to ensure that the compiler uses branchless code (conditional moves) when I know that the condition is quite unpredictable... At the moment for simple integer values that involves writing a branchless test that continues with using bitwise operations (with 0 or -1) or multiplications (with 0 or 1).

[Zoran]

Those that don't want it don't need to use it, correct?

Absolutely not correct.

By the way, I really like the particular feature and if it gets into language, I'll use it a lot.
My point is that the quasi argument that "You don't have to use some feature" is always very wrong.

Once the new feature is in the language, you can't avoid it -- you will encounter it in the sources and you will need to read and understand this code.

So please, never use this argument.