Re: language improvement suggestions (the spin off)

[440bx]

1) As detailed several times, with regards to readability, I am not sure if it is always more readable than "else if".

It is definitely more readable, though I concede that is true only if the statement is reasonably well formatted.

What it may not be is intuitive to someone who doesn't know the COBOL language.  I can think of some examples that would be unintelligible to a programmer who has not used COBOL yet would be crystal clear to any COBOL programmer who knows the language reasonably well.

Also this is about readability, not anything else.

No, it isn't only about readability.  It is also about code complexity.  A multi branch conditional table is noticeably more complex when expressed using if/then/else than when it is expressed using a construct such as evaluate that reflects the table structure.

that indent can be broken, e.g. by nesting "evaluates" (bad style or not, does not matter, it can be broken.

The intent cannot be broken.  An EVALUATE statement is an n-dimensional table.  EVALUATE within EVALUATE is used in the somewhat rare case that the columns of a table are also tables.

Remains the question how big a need there is to express such intend....

The existence of constructs such as "for", "repeat/until", "case", etc makes it clear that there is plenty of value of making intent clear since all of them can be built using "if" and "goto". 

2)
In either case, IMHO it only matters (if at all) from a certain size/complexity upwards. For small problems both solutions are adequate.

Expressing an n-dimensional structure using a chain of binary choice constructs (if) leaves a great deal to be desired. 

However, if a problem becomes so complex that you need to replace "elseif" with a special "elseif" replacement just to keep it readable, then my experience says its a design problem, and you should refactor or change the overall approach.

It's not a matter of complexity.  It's a matter of matching the right tool for the right job.  If statements to implement multi branch logical tables are akin to using a screwdriver as a hammer.  It can be done that way but, it's far from being optimal or elegant.  It's just a kludge.

"the experts decided" or more commonly "It is in the book".

It's not just the experts.  The EVALUATE statement is very common in COBOL programs because it is very useful and very clear.  That's like saying that the "for" statement should not be implemented because "the experts decided" or "it's in the book" (in this case the Pascal standard.)   In the case of the EVALUATE and the "for" statement, they exist because they are useful and the "experts" noticed that.

But there is also the rule "no one shoe fits all".

True.  The EVALUATE statement should be used to represent multi-branch decision tables.  Using it for something else is quite likely to be one of those cases where the shoe isn't a good fit.

No expert can foresee all future use (and abuse) cases.

Programmer deficiencies cannot be used as an argument not to implement constructs that are useful.

Therefore something being "in the book" does not mean it fits a particular case. It only means, one should consider it, and check if it fits.

It has already been clearly established that the EVALUATE statement is an excellent fit to deal with multi branch conditionals.  No surprise there, that's what the statement is designed to do.  Likewise, it's no surprise either that a "for" loop is a good fit when looping is required, that's what it was designed to do.

Now, if someone wants to wear a shoe on their head then, it is quite likely not to be a good fit since a shoe wasn't designed to be a hat.  That said, if someone wants to abuse their shoes, they are free to do so.  For the record, the experts cannot be blamed for that.

Unfortunately I have seen many examples where even really good programmers went blindly for "its in the book".

Unfortunately, those things do happen but, the fact that programmers make mistakes does not subtract in any way from the logical abilities of a programming construct.

[Martin_fr]

Also this is about readability, not anything else.

No, it isn't only about readability.

This was about my statement "this" (the particular statement, of which "only about readability" was part).

I expressed that I made my statement only with concern to readability.
And that this statement was not meant to include anything else.

So yes => it is.

[440bx]

This was about my statement "this" (the particular statement, of which "only about readability" was part).

I didn't realize you were referring to this.  I thought you were referring to the usefulness of the EVALUATE statement.

I expressed that I made my statement only with concern to readability.
And that this statement was not meant to include anything else.

So yes => it is.

I am going to presume you are still referring to this and not to the EVALUATE statement.  That this can be quite a source of confusion.

[Martin_fr]

The below, does not address the pre-eval nature of "evaluate. This is because it is not part of the quotes to which I answer. Also keeping in mind, that for the pre-eval:
- there are other means (the may be better or worse...) => discussed in other posts on this thread
- they only matter/apply where side-effects are in place.  (as for the readability of repeating those parts of the expression, see previous posts on "as" alias. We do disagree, but it appears a matter of taste. Also it has a point in the light of my "squeeze" reply in a previous post)

So when replying to my answers, keep in mind that each answer only deals with a certain part of the "evaluate". Which is the part that I got from reading the text I quoted from you. Apologies if I misread you on any of them.

that intent can be broken, e.g. by nesting "evaluates" (bad style or not, does not matter, it can be broken.

The intent cannot be broken.  An EVALUATE statement is an n-dimensional table.  EVALUATE within EVALUATE is used in the somewhat rare case that the columns of a table are also tables.

It can.
1) (actually does not conflict with the intent) => nested exists for both "if" and "evaluate".

1a) (off topic) "else if" would be more clear towards its intent if it was "elseif" (one word). In fact "elseif" represents the same intent. (only it does not on the top line).
   (again either and any can be nested)

2) breaking intent

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

1.   EVALUATE TRUE                         ALSO A > B                 ALSO X = Z  // intent THREE conditions
2.       WHEN        <expression 1>        ALSO           TRUE        ALSO            TRUE     // has THREE conditons
3.      
4.       WHEN       ( (<expression 2>) and (<expression 3>) )         ALSO           TRUE        ALSO            FALSE  // has FOUR conditions => broken intent
5.  

Yes very bad style. But again
"evaluate" does not prevent bad style
"if" does not enforce good style
same thing, just different wording.

Remains the question how big a need there is to express such intent....

The existence of constructs such as "for", "repeat/until", "case", etc makes it clear that there is plenty of value of making intent clear since all of them can be built using "if" and "goto". 

Off topic, this one line is not part of my argument: "whitespace" and "brainfuck" are also turing complete.


The difference of "if goto" and "<any loop construct>" is a bit bigger... But that aside, your argument would then just be reduced to having 3 different loop statements.
Are they needed? Topic for a discussion of its own.


This particular quote, seems to me to get away from the question, if or what value there is to "evaluate".
It seems to simply say, if claims of it not being valuable (or it being redundant) were true, then it could/should still be included because (of the claim) that the same was done for "several loops".

I think there is no point of arguing, what should or could be if that claim about evaluate being redundant were true.
That leads to the kind of  "two wrong, don't make one right" issue.

(While IMHO not successful)... You are presenting your arguments against the "redundant" claim in the rest of your post. So lets keep the arguing to those.

2)
In either case, IMHO it only matters (if at all) from a certain size/complexity upwards. For small problems both solutions are adequate.

Expressing an n-dimensional structure using a chain of binary choice constructs (if) leaves a great deal to be desired. 

If n = 1 or n =2 then => I see no problem.
If n =.... well, (and we will not agree on the exact "n" at which "else if" becomes harder to read, but really all that matters is that there is some "n")....

I already expressed that for an "n" that big, I find "evaluate" equally hard to read (if not harder, due to the lack of "as" alias / but again I know on that we disagree).
So yes "else if" becomes hard to read. But "evaluate" does not solve it (for me)

  => that said: read my previous reply about "squeeze" on one screen.
Yes I would probably myself use it for that. (If I find myself to lazy to go for a better solution). But that is not "readable". "squeezing" is far from readable. Even if "squeezed" on one screen may in this very particular case be a bit more readable than an "elseif" that does not fit the screen.

In the end, it comes down to
- your claim (for which no evidence exists, other that "its in the book"): "this is a common scenario"
- and my claim (equally unproven): a) "I have not experienced the need myself" b) "if it does happen, it is an indicator for bad design, and should be solved refactoring"
NOTE to the above (keep together when quoting): without your "it is commonly needed" claim, what is the point. For some rare edge cases, there is no need to introduce it.
That still holds true, even if there are already other constructs (maybe loops) present, that equally have no other standing, than some rare edge cases, or even less. (two wrong, don't make one right)

However, if a problem becomes so complex that you need to replace "elseif" with a special "elseif" replacement just to keep it readable, then my experience says its a design problem, and you should refactor or change the overall approach.

It's not a matter of complexity.  It's a matter of matching the right tool for the right job.  If statements to implement multi branch logical tables are akin to using a screwdriver as a hammer.  It can be done that way but, it's far from being optimal or elegant.  It's just a kludge.

"multi branch logical tables" implies some complexity.

Yes a table can have only ONE cell. But that would not need "evaluate", or would it?
See my above answer to when "n" becomes bigger.

As a matter of completeness, about your "hammer" analogy: I think the difference between "else if" and "evaluate" is at best using a 150gram hammer, where a 100gram hammer would have been good enough. Most people would not even know the exact weight of the hammer they need. Yes, there is a need for hammers of different weight, a sledge hammer is no good if you want to hang a small picture, but the diff between a 100g and 150g hammer does in 99% of all cases not matter, not even for people who know how to calculate the exact weight needed.
Concluding that back to "evaluate", maybe it matters in 1% (100 - 99) of all cases ("1" is a randomly chosen figure, standing for "a (very) low percentage", which is based on my personal experience of over 30 years of programming of my own, and in teams with others.

"the experts decided" or more commonly "It is in the book".

It's not just the experts. 

My comment was only directed the following statement of yours (from another post in this topic)

Before you say that is not the case, the folks who design the COBOL language obviously don't agree, if they did, they would not have added it to the 1985 standard.

I assume you give those people some expert status? And you used their decision (putting it in the standard aka "in the book") as argument.

Whereas I say, based on this, there is a point to look at it, and see if it fits into the different scenario of Pascal. (I.e., it being in the standard is in itself not an argument)
As well, as:
- Was there decision good to begin with? (Could be....)
- Is it still good, or have other techniques evolved to replace it (other techniques here does not refer to "else if" / see references do design/refactor)

No expert can foresee all future use (and abuse) cases.

Programmer deficiencies cannot be used as an argument not to implement constructs that are useful.

Bit out of context. I never said features should be avoided, because any feature can be abused. Then there would be no programming at all.

I said, that just because someone (expert or not) at sometime found that something is useful for specific cases...
Then that does not mean, that this will apply forever.
Also cases may not always be the same, and even in exactly identical cases something better may have emerged to replace it. (We are in the year 2019, not 1985).

As for details on something better (as that question may now raise): As I have not myself experienced the need for the "original solution", I never had to look for this "something better".
That does not mean it does not exist....

It has already been clearly established that the EVALUATE statement is an excellent fit to deal with multi branch conditionals. 

Has it? Then why is there still a discussion?

You have always claimed that.

I have agreed that some elements of it, are of interest.
At the same time, I have also questioned if situations where their "interesting" property might be applied, actually arise (commonly, or at least with some regularity (I am aware you claim they do)).
And also, if when they arise, they arise in a valid situation.

Where they do arise in case of bad design, I think it should not be used as argument. It does not sound good to say "we need it, so we can get away with bad design"
=> I know, you have not said that. I do not imply you have.
=> I merely underline, that out of the IMHO very few cases, which may seemingly need "evaluate" we have to filter out any cases, that merely exists because something else (design or otherwise) went wrong before.

This is a bit theoretical. To further that point entire projects, which currently contain "evaluate" would need to be analysed. A task for which I do not have the time.
Still the assumption, that such situations may exists remains valid. The extend to which this is the case is entirely open. (As are any other figures about what happens how frequently)

[Rainbow6]

Hi,

this very long and interesting thread still lives on.

It has already been clearly established that the EVALUATE statement is an excellent fit to deal with multi branch conditionals.  No surprise there, that's what the statement is designed to do.  Likewise, it's no surprise either that a "for" loop is a good fit when looping is required, that's what it was designed to do.

But I have a question, do you have a real world (not a constructed) example of a real production use of a multi-condition-multi-branch-conditional in hard coded form?

I sure love COBOL (as I said before) because its such an underrated language today, but if I want to use COBOL, I use COBOL. I would never come to the idea, to add the RPG primary/secondary cycle processing to Pascal, because it belongs to RPG - even if I think, that cycle processing is one of the most powerful language features a language could have.

Regards,
Daniel

EDIT:

P.S.: When EVALUATE was added to the COBOL-85 standard, the EVALUATE statement was in active use for several years. So EVALUATE was invented in the late 70s and early 80s - this was the time, when decision tables were used in hard code - but even in the late 80s and early 90s everyone "outsourced" most of the business logic into databases. So EVALUATE is also a "child of its time".

As I said before - I never saw a large EVALUATE statement with multiple conditions in 25 years of professional mainframe and midrange programming with COBOL in real production use. When I saw one, it were in small one-time-use Programms, which everyone would simplify to a single SQL statement today.

[Martin_fr]

This was about my statement "this" (the particular statement, of which "only about readability" was part).

I didn't realize you were referring to this.  I thought you were referring to the usefulness of the EVALUATE statement.

I expressed that I made my statement only with concern to readability.
And that this statement was not meant to include anything else.

So yes => it is.

I am going to presume you are still referring to this and not to the EVALUATE statement.  That this can be quite a source of confusion.

Please re-read the original post were I made this statement. It is about "evaluate"

And the part you quoted, and you said it was incorrect, was a part were I explained what I referred to, in my statement immediately preceding that sentence.

- I made my statement/answer
- I then declared the intent of this one statement

That intent (regarding my answer) was "it is only about readability"
So that statement is correct. It declared my intention, and that intention still stands (again regarding that particular one answer)

The entire discussion in this thread has touched many aspects, readability being one of them, but not the only one.
The particular statement of mine, was about readability, and only that.

EDIT:
Here is the actual full original quote:

The EVALUATE statement makes it possible to represent multi-branch conditions with much greater clarity than any of the currently available Pascal constructs.   Before you say that is not the case, the folks who design the COBOL language obviously don't agree, if they did, they would not have added it to the 1985 standard.  Probably a bunch of "micromanagers".

1) As detailed several times, with regards to readability, I am not sure if it is always more readable than "else if".
As always there are some cases....
Also this is about readability, not anything else.

I answer to your part about "clarity" (aka readability?) => And that is what I answered to.

If there was anything else, I did not answer to it...

[440bx]

This discussion is definitely getting a lot more involved in surprising ways...  no problem I will try to address the points you made.

So when replying to my answers, keep in mind that each answer only deals with a certain part of the "evaluate". Which is the part that I got from reading the text I quoted from you. Apologies if I misread you on any of them.

And my apologies if I misunderstood what you intended and offered a reply that didn't apply.

<following quote is out of sequence but is more logical here>

(as for the readability of repeating those parts of the expression, see previous posts on "as" alias. We do disagree, but it appears a matter of taste. Also it has a point in the light of my "squeeze" reply in a previous post)

I still maintain that the evaluate statement is significantly more readable than nested if/then/else(s).  I support that statement by citing that it is very rare (and that is an understatement) for a Pascal programmer to forego the use of a case statement in favor of nested if/then/else.  While someone could claim that is done for performance purposes, that reason cannot be used for case statements that involve strings. 

Therefore, strictly because of readability - not to mention visualization ease - an FPC programmer will prefer to use a case statement to compare against string constants over nested if/then/else.

If you believe the use of a case statement is not dictated by greater readability and understandability in the case of constant string comparisons then I would like to know why your viewpoint diverges.

2) breaking intent

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

1.   EVALUATE TRUE                         ALSO A > B                 ALSO X = Z  // intent THREE conditions
2.       WHEN        <expression 1>        ALSO           TRUE        ALSO            TRUE     // has THREE conditons
3.      
4.       WHEN       ( (<expression 2>) and (<expression 3>) )         ALSO           TRUE        ALSO            FALSE  // has FOUR conditions => broken intent
5.  

The intent isn't broken because of a compound expression. It still matches <compound expression> to the result in the evaluate.  The table structure does not change whether the statements are simple or compound conditions.

"evaluate" does not prevent bad style
"if" does not enforce good style
same thing, just different wording.

I believe we can agree on the fact that no statement can enforce good style or prevent bad style.  That said, no matter how bad the style is, it is _not_ possible to turn an evaluate statement into something other than a table structure just like no matter how bad the style may be, it is not possible to change the fact that an "if" statement is a binary choice.

Remains the question how big a need there is to express such intent....

The existence of constructs such as "for", "repeat/until", "case", etc makes it clear that there is plenty of value of making intent clear since all of them can be built using "if" and "goto". 

Off topic, this one line is not part of my argument: "whitespace" and "brainfuck" are also turing complete.

You brought it up: how big a need there is to express such intent.  Programmers prefer "for", "repeat/until", etc over "if whoknowswhat then goto Somewhere" and, I strongly believe the reason is because it is much clearer not to use "if/goto", which caters to the fact that there is a "need" to make programs as clear as possible which includes intent.

The difference of "if goto" and "<any loop construct>" is a bit bigger... But that aside, your argument would then just be reduced to having 3 different loop statements.
Are they needed? Topic for a discussion of its own.

for clarity and ease of understanding, that is a definite yes.  Are they needed if the language offers "if" and "goto" then the answer is no, because "if" and "goto" can create any kind of loop a programmer can dream of.

Don't go Marcov on me!

This particular quote, seems to me to get away from the question, if or what value there is to "evaluate".

Simplicity, clarity, precise and accurate intent, ability to express n dimensional tables using a construct that clearly indicates the table structure since that's the construct's raison d'etre.

2)
In either case, IMHO it only matters (if at all) from a certain size/complexity upwards. For small problems both solutions are adequate.

Expressing an n-dimensional structure using a chain of binary choice constructs (if) leaves a great deal to be desired. 

If n = 1 or n =2 then => I see no problem.

There is a readability and complexity problem. Specifically, consider the case of the arguments being strings.  Using "if" the if statement has to call a function to determine if the string variable matches the string constant, if there are multiple possible strings then there will be a bunch of "or"(s).  A simple case statement (in FPC only) does it much more clearly and simply, no need to call a function to determine equality and every string constant is separated by a comma.  An evaluate statement does it just as simply since in the case of n = 1, it is basically a case statement (except that it allows for variables instead of only constants.)

If n =.... well, (and we will not agree on the exact "n" at which "else if" becomes harder to read, but really all that matters is that there is some "n")....

It should be quite obvious that if nested if/then/else are already vastly inferior in the case of n = 1 (see above) that will only get worse as n increases.

I'm going to summarize the EVALUATE situation, as follows:

1. an EVALUATE statement is a case statement that allows multiple columns.
2. an EVALUATE statement is a case statement that allows comparing against _variables_ not just constants.

The above should make it rather clear that an EVALUATE statement is just a case statement with the usual restrictions removed from it. 

I support my assertion that EVALUATE is _vastly_ superior, in every way, for multi branch logic than nested if/then/else simply by citing that, except for very rare exceptions, the great majority of Pascal programmers would always choose a case statement over nested if/then/else if there are no limitations preventing them from using it and, that assertion is supported by the fact that when comparing a string against multiple constant values, most Pascal programmers prefer using a case statement over the equivalent nest of if/then/else.

Moreover, I believe _you_ would prefer using the case statement over nested if/then/else in that case too.   Feel free to let me know if I am mistaken and why.

But I have a question, do you have a real world (not a constructed) example of a real production use of a multi-condition-multi-branch-conditional in hard coded form?

Sure!.  I'll use the Windows API for that purpose.  Consider a call to CreateFileEx.  If it fails it returns INVALID_HANDLE_VALUE, in that case an EVALUATE statement against GetLastError() can be used to determine if remedial action is possible and do it in the WHEN clause. If remedial action is not possible, get the error message from FormatMessage and present it to the user.

As I said before - I never saw a large EVALUATE statement with multiple conditions in 25 years of professional mainframe and midrange programming with COBOL in real production use.

I don't know the count of how many I've seen but it's in the _many_ thousands.

When I saw one, it were in small one-time-use Programms, which everyone would simplify to a single SQL statement today.

Not every COBOL program is written to access a database.  There are countless COBOL programs that deal with files of one type or another which have to check for what errors, if any, took place and take reasonable action as a result.    One of the very nice things an EVALUATE statement can be used for is to make error reporting much more precise.  For instance, if an error occurs in one context, it may be recoverable but, may not be if it occurred in a different context.  The error code and the possible contexts can be "evaluate"d simultaneously to produce a table of how specific errors are handled depending on the context they occurred and, the error messages tailored appropriately.  That saves a lot of time and headaches to those who have to figure out why the program failed and how to correct the failure for subsequent successful execution. 

[Martin_fr]

2) breaking intent

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

1.   EVALUATE TRUE                         ALSO A > B                 ALSO X = Z  // intent THREE conditions
2.       WHEN        <expression 1>        ALSO           TRUE        ALSO            TRUE     // has THREE conditons
3.      
4.       WHEN       ( (<expression 2>) and (<expression 3>) )         ALSO           TRUE        ALSO            FALSE  // has FOUR conditions => broken intent
5.  

The intent isn't broken because of a compound expression. It still matches <compound expression> to the result in the evaluate.  The table structure does not change whether the statements are simple or compound conditions.

In that case it is arguable that an if statement (with repeated "else if" is also always a table. If a condition, becomes "true = true" it simply is empty (including an empty separator). The processing result is still the same.

The above "evaluate" is like a nested table, where in some rows, an existing cell, is split into 2 horizontal cells (compound expression). That simply breaks the relation between headers "evaluate" and data "when" in the table.

That is, of course the compound expression, pulls in entirely new data. (shortened, please assume any amount of ALSO

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

1.   EVALUATE TRUE                        
2.       WHEN        a=1
3.       WHEN        (a>2 and a<5)      // does not necessarily break / still tests the same element
4.       WHEN        (a=9 and something_unrelated=x)      // clearly not the intent of evaluate => breaks the intent

it is _not_ possible to turn an evaluate statement into something other than a table structure just like no matter how bad the style may be, it is not possible to change the fact that an "if" statement is a binary choice.

How to you compare  "table" and "binary choice"?

"binary choice" is a table: 2 rows. Each row has (depending on view) either 1 column (compound condition) or n columns
"table" is a 1of n choice => which is (internal implementation can differ) a serious of binary choices (for each "when" line).

evaluate "table" in contrast to "case" allows variable expressions in each "when" (where case only allows constants).
Due to this, evaluate is not a "1 of n" hash lookup. It is indeed a check each when, until one matches. Exactly as "else if" does.

Hence in terms of "table" or "binary choice" => evaluate and "else if" are the same.

Again, an "if else if ..." is perfectly capable of encoding a table. The only different are:
- IF  does not "shout" at you that it is a table.  "elseif" in one word would give some hint at least that it is "1 of n"
- IF does not enforce the columns, empty columns (true=true) can optional be omitted. So you get an extra option. Nice if you like it. If you do not like it, include the "true=true"
- IF does include the "alias". We disagree here, but I see that has a huge benefit. (except in the squeeze on one screen issue). After all Pascal is meant to be verbose. (begin instead of { )

The evaluate saves some work about the "pre-eval".
It adds some work, to ensure columns are matched (due to the missing alias).
And whenever you change a condition you must re-align the remainder of the line (and maybe all others, if you increased length, and pushed the "also" out).
For the "if" you can do the formatting. In cases where it is not readable without.

The existence of constructs such as "for", "repeat/until", "case", etc makes it clear that there is plenty of value of making intent clear since all of them can be built using "if" and "goto". 

You brought it up: how big a need there is to express such intent.  Programmers prefer "for", "repeat/until", etc over "if whoknowswhat then goto Somewhere" and, I strongly believe the reason is because it is much clearer not to use "if/goto", which caters to the fact that there is a "need" to make programs as clear as possible which includes intent.

The for vs goto, was something you brought up.... (unless you somehow included my pun on "whitespace" but it does not really seem to match this either.....

Anyway for vs goto, is like sledge hammer vs 50gram hammer..... Or even further apart.
I really fail to see the connection, between for vs goto and if vs evaluate.

Besides no one says, that there is not a level at which something that can be done one way (in your case "if goto"), might not be better done with a dedicated different command (in this case "for" or "while","repeat").

What is said, is that it depends on various things, if such an alternate form is sensible or not. Some of those factors are (and there are probably many more)
- How for apart are the 2 constructs (IMHO goto vs for => light-years / if vs evaluate => living in the same small room)
- How many separate use cases exist for each statement on its on?

The latter is a point for you, "goto" is avoided by so many, one could argue it should not exist. Anyway, if that were the case, a mistake from the past (adding goto) does not make a future mistake (adding evaluate) any better)

So in order for this argument of yours to not become void, you would have to show:
- that for-vs-goto and if-vs-eval are much more alike than I believe. (I left out some arguments I could give here, because I see no point going down this road. It will quickly become absurd, and I want to avoid that)
- that goto on its own actually has a merit for existence, and is not a mistake from the past.
  "goto"  (at least within the same proc), can usually be substituted, either by "if" or by a "loop" (to jump back).
  rare case may be possible to construct where that replacement is not possible (no proof required), but do they exist in real life?

Some more text from you on the topic followed, which I believe to be covered by the above....

Don't go Marcov on me!

Whatever that means.

There is a readability and complexity problem. Specifically, consider the case of the arguments being strings.  Using "if" the if statement has to call a function to determine if the string variable matches the string constant, if there are multiple possible strings then there will be a bunch of "or"(s).  A simple case statement (in FPC only) does it much more clearly and simply, no need to call a function to determine equality and every string constant is separated by a comma.  An evaluate statement does it just as simply since in the case of n = 1, it is basically a case statement (except that it allows for variables instead of only constants.)

A "case" statement differs in many ways from an "evaluate"
- only one value to lookup
- only constants in the lookup (case labels)

A case statement is a great deal more readable than an "evaluate".

To rephrase my opinion: An "evaluate" is a highly cluttered "case"-ish statement (-ish, owed to the 2nd diff)
"cluttered" => not readable.

Not 100% sure on your "calling function", but I believe your refer to the compilers implementation details, and potential optimizations? In which case that has no importance for the language design (not with the computing power that  a compiler has to its avail, to make the necessary optimization, independent of the design

If n =.... well, (and we will not agree on the exact "n" at which "else if" becomes harder to read, but really all that matters is that there is some "n")....

It should be quite obvious that if nested if/then/else are already vastly inferior in the case of n = 1 (see above) that will only get worse as n increases.

No one talks about nested if then else

if else if => is a waterfall concept.
Even though, yes in pascal there is no "elseif" but only "else if". And technically the latter is a nesting. But for the use case that we discuss here, it does act 100% as a waterfall. So nesting IMHO is not an argument.

If however, you feel really strong about the syntax expressing that it is free of nesting => all you need is an "elseif" in one word.

I'm going to summarize the EVALUATE situation, as follows:

1. an EVALUATE statement is a case statement that allows multiple columns.
2. an EVALUATE statement is a case statement that allows comparing against _variables_ not just constants.

The above should make it rather clear that an EVALUATE statement is just a case statement with the usual restrictions removed from it. 

And removing the restrictions makes it cluttered.

Incidently I came up with the same conclusion above, before even reading it from you....

But I have a question, do you have a real world (not a constructed) example of a real production use of a multi-condition-multi-branch-conditional in hard coded form?

Sure!.  I'll use the Windows API for that purpose.  Consider a call to CreateFileEx.  If it fails it returns INVALID_HANDLE_VALUE, in that case an EVALUATE statement against GetLastError() can be used to determine if remedial action is possible and do it in the WHEN clause. If remedial action is not possible, get the error message from FormatMessage and present it to the user.

I actually like to see that in code

I don't know the count of how many I've seen but it's in the _many_ thousands.

Cant argue what I have no access to. But I have yet to find the google query to find them (assuming they are in open source on the net)

[440bx]

After this reply - which will be short - I am done explaining a construct that is _evidently_ vastly superior to the disgraceful chains of if/then/else that must be used in Pascal due to the many limitations of its case statement.

In that case it is arguable that an if statement (with repeated "else if" is also always a table. If a condition, becomes "true = true" it simply is empty (including an empty separator). The processing result is still the same.

The above "evaluate" is like a nested table, where in some rows, an existing cell, is split into 2 horizontal cells (compound expression). That simply breaks the relation between headers "evaluate" and data "when" in the table.

Simply: no.  There is nothing in a chain of if/then/else statements that makes a tabular structure readily identifiable.  Such a chain could be anything.

It makes no difference whatsoever that a WHEN column is expressed using a compound condition, there is still a structural, readily identifiable correspondence between the WHEN column and the EVALUATE column. 

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

1.   EVALUATE TRUE                        
2.       WHEN        a=1
3.       WHEN        (a>2 and a<5)      // does not necessarily break / still tests the same element
4.       WHEN        (a=9 and something_unrelated=x)      // clearly not the intent of evaluate => breaks the intent

[/code]

It doesn't break the intent at all.  It is still a one column table.  There is still a structural correspondence of the first (and only in this case) column in the WHEN with the first (and only in this case) in the EVALUATE.

In stark contrast, in a multi branch table implemented with a chain of if/then/else the occurrence of an "and" leaves the reader wondering if the expression after the "and" associates with the previous column (if any) or the next. 

How to you compare  "table" and "binary choice"?

A table and/or an evaluate statement is an n x m arrangement of values.  An if statement has no arrangement.

Due to this, evaluate is not a "1 of n" hash lookup. It is indeed a check each when, until one matches. Exactly as "else if" does.
Hence in terms of "table" or "binary choice" => evaluate and "else if" are the same.

I don't care how the compiler implements it.  I care that when I see "EVALUATE", I know I have a table in front of me.  When I see nested if/then/else, I know I have a mess in front of me.  As far as being the same, they might be for the compiler but certainly not for the programmer.

- IF  does not "shout" at you that it is a table.  "elseif" in one word would give some hint at least that it is "1 of n"

As previously stated, the presence of an "elseif" does not guarantee a table structure.  EVALUATE "shouts" table because it is a table.  "elseif" shouts "binary roadkill ahead".

- IF does not enforce the columns, empty columns (true=true) can optional be omitted. So you get an extra option. Nice if you like it. If you do not like it, include the "true=true"

Not enforcing the columns proves that a chain of if/then/else is not a table.  The EVALUATE strictly enforces columns (that's what a table does) and if the value of a column does not matter then the match value is the keyword "ANY" (not some cheesy clutter in the form of (true = true) but omitting it destroys any semblance to a table that binary roadkill is trying to emulate.

And whenever you change a condition you must re-align the remainder of the line (and maybe all others, if you increased length, and pushed the "also" out).

Yes, that is true.  That's why I use an editor that can move rectangular columns of text very easily and in very few keystrokes.  I use that feature in all languages because I align everything no matter what language I am programming in.

For the "if" you can do the formatting. In cases where it is not readable without.

I've noticed there is a great abundance of such cases, in most cases, I neither format them nor read them, I file them instead.

I really fail to see the connection, between for vs goto and if vs evaluate.

simple, the presence of an "if xxx then goto" which may be used to implement a loop, does not guarantee it implements a loop.  The same way, a chain of if/then/else do not guarantee they implement a table while the evaluate statement does.

a future mistake (adding evaluate) any better)

that one is priceless.  You're saying that a construct that is nothing but a case statement with all current limitations removed is a "mistake".   Now, I'm really starting to understand why improvements are so unappreciated around here.

Don't go Marcov on me!

Whatever that means.

It means you're using Marco's fallacious argument that, if there is already a way to do it then, no other way is needed.  A wonder why Pascal even exists, Assembler can do everything Pascal can and then some.  Let micromanagers loose, they start microoptimizing and you get compilers! it's terrible!.

A case statement is a great deal more readable than an "evaluate".

You really have to give serious consideration to practice reading.  Properly formatted, they are about the same but, in a multi branch evaluate there is more to read than in a simple case.  That is normal and it doesn't make it less readable.

To rephrase my opinion: An "evaluate" is a highly cluttered "case"-ish statement (-ish, owed to the 2nd diff)
"cluttered" => not readable.

I hate to point this out but, your opinions seem to be the opinions of an individual who is yet to code his first EVALUATE statement.  I agree with you that the opinion of experts should not be assumed to be "truth" and that places the opinion of those who are not experts in context too.

Not 100% sure on your "calling function", but I believe your refer to the compilers implementation details, and potential optimizations?

if you use if/then/else chains to compare strings to constants instead of using a case statement, you'll have to call a comparison function in your if.  This isn't a matter of optimizations, that is a fact, it is also a fact that it will add yet more clutter to that deficient construct (just in case, if/then/else, that one.) OTOH, the case statement does the comparison without having to call a function because as you pointed out, the compiler does the work for you.  Good compiler!

I won't elaborate on what follows but in COBOL, if the programmer structures his data and conditions well, it is possible to create named sets of strings and test if a particular string is in the named set.    I know, it's a lousy feature, it can be done with a loop and an if/then/else chain.

And removing the restrictions makes it cluttered.

Priceless part deux!
 

I actually like to see that in code

The code for that is trivial. 

Cant argue what I have no access to. But I have yet to find the google query to find them (assuming they are in open source on the net)

I have no idea if and how many times it has been used in open source project but, the number of EVALUATE statements I've code _easily_ go into the many thousands, adding the ones I've seen coded by other programmers and, "many thousands" is actually quite an understatement.


Conclusion (for real this time) :

I find it absurd to spend this much time to explain the benefits of the EVALUATE statement when it is crystal clear that the probability of enabling pigs to fly to Mars is higher than the probability of it being added to FPC.

Because of this, I am done.

I enjoyed the discussion, thank you.  (The End, AFAIC)

[Martin_fr]

Yeah well its the point that we start repeating.

Anyway, I got most of your points. I don't agree with many of them.

But the point is, that in 30 years and all the teams I have worked with, I have not personally come across the need for it.
Maybe just lucky me? (or unlucky if you a right, and I missed something really great?)

In any case, so there are 10000 of usages out there (your word for it). The problem is I have no way to verify if they are needed (or could have been done in a different better way / assuming support for such a way).
Maybe they were needed. Maybe not. I do not know.
Not going to find out either:
- do not have access to them (i.e. lots of them)
- not the time, to study many other projects for this

That leaves an impasse on the question, is it needed. your word against mine.

If it were actually needed, I would still like it in a different form. Introducing table constraints can be done in many ways. Such as the "as" alias, which you do not like.

The experiment that would be interesting, but can't be done:
If you did not know the feature yet, and were not used to a particular implementation of it => how would you design it.

I know, I would (if I would do them at all) do some things different, I already wrote about some of them.

Alternative:

Introduce TTuple

And

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

1. case TTuple(...) of
2.   TTuple(...) : ;
3.   TTuple(...) : ;
4.   TTuple(...) : ;
5. end;
6.  

It is different:
- the labels must be constants.
- it only has equality test (no range in ...)
- It would not have the names, in front of each value as I would like....

But it be a table.
It only evals once.
It enforces the column count.

It might be useful for other stuff. So the "case TTuple" would be a side effect, and the argument would come from other parts of the feature.
 
I have currently no particular opinion if TTuple should actually be added


EDIT:
Maybe (just an idea), since we have so different experience in coming across the feature...
Maybe it is bound to certain styles associated only with certain languages?
Or preferences of doing certain kind of project in certain languages?

As for "styles associated", when I switched back to Pascal, after more than a decade away, I missed a lot of features from other languages. And I would have sworn each and every of them is a natural must have.
Today, I do many of those things that I missed in alternative ways. And usually those alternatives a better.

Obviously if this might apply to evaluate is outside my judgment.

[VTwin]

So I went the extra mile and googled: github cobol "evaluate" "also" cbl
https://github.com/Apress/beg-cobol-for-programmers/blob/master/978-1-4302-6253-4_Coughlan_Ch05/Listing5-9.cbl

A winner for "short" (as in, least amount of writing)

But the only one who will be happy is my optometrist, when I will need new glasses. This hurts my eyes.

Reading it, on each line I go: "21 throu 99" of what?
The statement takes the expression "Qty = 21 throu 99", tears it appart, puts half of it in one line, and the other half somewhere else....

I do not know, if this example is an abuse, or the desired form of use.... But it is not good.

Also found https://github.com/uwol/proleap-cobol-parser/blob/master/src/test/resources/io/proleap/cobol/ast/tandem/Evaluate.cbl
Not better. Putting each ALSO into a new line slightly helps, but...

 

[VTwin]

I can see the release manifest for that release

- NOW WITH NEW COBOL FEATURES ! 

That will win us the hearts of new programmers. 

 

[del]

I have the eyes of an engineer and to me it looks like a neat stack of logic functions. LIke a block diagram. Swap 'em in, swap 'em out. OTOH a lot of Pascal is still pretty alien to me, so I'm not carrying a lot of prejudices regarding what "looks good" and what doesn't.

[winni]

Hi!

And now back to reality:

The last time I spoke to a COBOL programmer was in the early 90th.

She was a newbie and worked for the software department of a bank.
She coded the whole day inputmasks. And nothing else.
She was not very excited about her job.

@del
You here? I thought your browser exploded!?

Winni

[del]

Hi!

And now back to reality:

The last time I spoke to a COBOL programmer was in the early 90th.

She was a newbie and worked for the software department of a bank.
She coded the whole day inputmasks. And nothing else.
She was not very excited about her job.

@del
You here? I thought your browser exploded!?

Winni

That's quite a story - thanks for sharing.