Re: language improvement suggestions (the spin off)

[marcov]

That's quite a fallacy.  Thousands of years went by before Rene Descartes showed how to unify Algebra and Geometry.  The fact that thousand of years went by before he did is, obviously, not a measure of the method's merit. 

No, it probably just meant that less people have stood on that junction before Descartes than that people have written nested ifs in Pascal the last few decades.

And note that I wrote "chance", not an absolute. Which should apply to your mathematical sensitivities.
Anyway the fact remains that you are the only one who actively reported that need or discussed a problem there.

What follows is simply a personal opinion, I believe you should consider being a little more open to changes in the language. 

You don't say why or what your philosophy about extension is. Stronger even, this sub thread is mostly about you evading that question with analogies from Math history.

The premises you consistently use to justify not including any new features in Pascal are either demonstrably false or of dubious value.

First I I assume you mean enhancements and not changes. Changes in a programming language are a no-no. Just like  tomorrow one doesn't pick a random character from the unicode set and say that now replaces + when addition is meant, so that + can be kept for set operations. A language or a notation is a contract. If you want to change fundamentals, start a new one. Doing so would invalidate most of the use of + in centuries of text or more.

.... As to demonstrably false or dubious: opinion, not fact. (and I can't even imagine what it is based on, except as a vehicle to push your opinion through).

Also I'm not entirely closed to enhancements, but IMHO in general they should make things possible, not be shorthands and other stylistics micromanaging. That is a simple litmus test for for language extensions for a production compiler as Free Pascal is. Unfortunately most of the proposals are in that fairly unintesting category.

Exceptions do happen, it even happened  this week in the async/await from C# copy thread. I actually could imagine things happening under the hood there that required a language expansion. But after some studying, it seemed the main reason was so that both parts could be in the same method, and that apparently any (part of) such method can operate as a closure in C#. (probably since it is under control of the runtime/JIT).

This is very hard in a natively compiled language (for obvious stack construction reasons, aborting a method removes its state from the stack) and the benefit seems to be fairly trivial.

So I opted for a more library approach.

[guest64953]

So I opted for a more library approach.

Something like objective C as an extension to standard C? 

[marcov]

So I opted for a more library approach.

Something like objective C as an extension to standard C? 

So objective C is compiled by a standard C compiler?

[guest64953]

OK. I read the first post. I don't understand much as you professionals but may I have my own opinion? I think readability is not really a problem for me but I prefer simplicity. At the first glance I think freebasic is an easier to read version of C, I even could use standard C libraries by #include once "crt/stdio.bi" but after some attempts I failed and revert back to plain C. A more wordy language with more shortcuts could make things easier to read and understand but more inconvenient to write. We should keep the balance between readability and simplicity. People could have his/her own adventures with his/her own dialects, e.g. {$mode objfpc-440x} I think the compiler's devs would be pleasant to merge these dialects. The dialects will prove themselves by the number of users of it. I know, something is clearly good, clearly superior or someone will not clearly good, clearly superior with others. After all, we're clearly very different person 

[guest64953]

So I opted for a more library approach.

Something like objective C as an extension to standard C? 

So objective C is compiled by a standard C compiler?

gcc -lobjc? 

[kupferstecher]

Also it raises the question whether a hypothetical this would reevaluate the left side or not.

An other plus of the concept, the compiler can fully optimise, as several "this"s describe a single access to the variable.

You didn't get my point.

I did get your point, but maybe I think to simple. For a variable its clear that it needs to be read from memory ("this"-part) and to be written back (assignment part). Only several reads (i.e. several "this") could be reduced to one. The same holds for properties. Thats why I wrote 'several "this"s describe a single access', and not that the statement results in a single access.

To be honest I didn't think it through for pointers or multiple dereferencing. But should be the same, one read and one write operation.

Now I tried to use inc() for properties, doesn't work. So what are we waiting for?

--
Besides the technical aspects, I understand that adding features is very difficult. To find an agreement in the community perhaps is more difficult than the Brexit-negotiations in the British parliament.
So sticking to Delphi syntax makes the development and the program environment more stable, the language won't drift away.

[marcov]

So I opted for a more library approach.

Something like objective C as an extension to standard C? 

So objective C is compiled by a standard C compiler?

gcc -lobjc? 

gcc is a frontend binary that actually passes to a different compler binary (cc1, cc1puls and probably whatever objc is)

[guest64953]

gcc is a frontend binary that actually passes to a different compler binary (cc1, cc1puls and probably whatever objc is)

Sorry. I used to think it's GNU C Compiler, but it is GNU Compiler Collection indeed 

[440bx]

Anyway the fact remains that you are the only one who actively reported that need or discussed a problem there.

Is that supposed to prove that a multi-branch statement isn't useful ?  Also, I didn't state it was a "need", I stated that it is a significantly simpler, readable, maintainable and understandable solution than building the equivalent if/then/else chain.

You don't say why or what your philosophy about extension is.

I'm not sure that the way I think about it could be called a philosophy but, to use that word, my philosophy is that there are logic flows which are very common in logical processes, as a result, it makes sense to have specific constructs to represent them.  That's why there are loop constructs such as "for", "repeat/until", etc or branching constructs such as "case", simply because they are common and having a construct dedicated to make them obvious is a very significant improvement over building them from scratch using "if"(s) and "goto"(s).

I already know what your reply is going to be but, I'll let you state it so I can address it directly.

Stronger even, this sub thread is mostly about you evading that question with analogies from Math history.

I don't see how you can claim I've evaded the question.  I have provided the reasons and examples throughout this thread.  The analogies to the field of Mathematics are there only to make it totally obvious that some of your justifications are unfounded and fallacious.  It took thousands of years for the Hindus to "invent" the number zero and the positional representation of numbers.  You cannot claim that "few" people experienced the problems present in other systems, such as Roman numerals, prior to its development.  IOW, whoever came up with the numeral zero and the positional system was hardly the first guy to face the many problems associated with the lack of zero and non-positional systems.

Ooops... sorry, it seems you are not very fond of Mathematical analogies and I just added another one.  I have a book about the development of the combustion engines, would analogies in that field improve your willingness to enhance the Pascal language ?... if yes, I'll review it and put it to good use.

First I I assume you mean enhancements and not changes.  Changes in a programming language are a no-no.

Yes, I've never suggested changing the way a current construct operates.

A language or a notation is a contract. If you want to change fundamentals, start a new one. Doing so would invalidate most of the use of + in centuries of text or more.

As stated above, I've never suggested doing such a thing.  I'll take this opportunity to make it clear that, in this particular case, I agree with you, a rare event.

.... As to demonstrably false or dubious: opinion, not fact. (and I can't even imagine what it is based on, except as a vehicle to push your opinion through).

That opinion is based on the verifiable fact that, just about anything anyone suggests elicits an immediate refusal on your part.  Imagine that!

Also I'm not entirely closed to enhancements, but IMHO in general they should make things possible, not be shorthands and other stylistics micromanaging.

I'm surprised you don't consider a "for" loop to be a "shorthand" or "stylistic micromanaging", after all, it can be done with "if" and "goto".

How is the "for" statement not "shorthand" and/or "stylistic micromanaging" ?... did Niklaus Wirth indulge in such things ?  BTW, could you accurately and precisely define what "micromanaging" means in the context of Pascal ?

That is a simple litmus test for for language extensions for a production compiler as Free Pascal is.

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

Unfortunately most of the proposals are in that fairly unintesting category.

According to you but, obviously not according to the "micromanagers" in charge of the COBOL language.

Exceptions do happen, <snip>
So I opted for a more library approach.

That doesn't sound like an exception happened, it sounds more like an exception _almost_ happened but (unsurprisingly) didn't.

If it's any consolation, I am fully aware that nothing like the EVALUATE statement is likely to be added to FPC anytime soon.  The points I wanted to make about the construct, I've already made earlier in this thread.

[guest64953]

You could think I'm stupid but I don't understand your EVALUATE syntax 

[Martin_fr]

You could think I'm stupid but I don't understand your EVALUATE syntax 

While I do not know anything about you or your intellect, I can tell you that not understanding "evaluate" from the sample(s) in this thread is definitely not a sign of stupidity.

I did not understand it either (not until clarifications). And I know I am not stupid.



Anyway, you just confirmed my reservations on the readability of "evaluate"...

[del]

It reminds me of TTL and truth tables:

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

1.     Evaluate True Also True
2.       When Age < 13 Also Sex = "M"
3.         Move "Young Boy" To Description
4.       When Age < 13 Also Sex = "F"
5.         Move "Young Girl" To Description
6.       When Age > 12 And Age < 20 Also Sex = "M"
7.         Move "Teenage Boy" To Description
8.       When Age > 12 And Age < 20 Also Sex = "F"
9.         Move "Teenage Girl" To Description
10.       When Age > 19 Also Sex = "M"
11.         Move "Adult Man" To Description
12.       When Age > 19 Also Sex = "F"
13.         Move "Adult Woman" To Description
14.       When Other
15.         Move "Invalid Data" To Description
16.     End-Evaluate
17.  

But I'm just here for the free beer.

[Martin_fr]

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.

As established it expresses a more specific intend as "else if" (though again that indent can be broken, e.g. by nesting "evaluates" (bad style or not, does not matter, it can be broken).
Remains the question how big a need there is to express such intend....

2)
In either case, IMHO it only matters (if at all) from a certain size/complexity upwards. For small problems both solutions are adequate.
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.

3)
The next part is generic. I make no judgment if your case falls into it. If other or you want to make such judgment based on the following statement, then that is their issue.

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

A statement that is probably common subject to abuse....

Well yes there is a point to having experts, and to having books by them (or in this case a language design).

But there is also the rule "no one shoe fits all". No expert can foresee all future use (and abuse) cases.
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.

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

[440bx]

You could think I'm stupid but I don't understand your EVALUATE syntax 

No, not stupid, you're just not used to it.  It's very simple, using the example in my first post (shown again):

Code: ASM  [Select][+][-]

1. EVALUATE TRUE                       ALSO A > B     ALSO X = Z
2.   WHEN <conditional expression 1>   ALSO TRUE      ALSO TRUE
3.     <statements applicable to above condition>
4.  
5.   WHEN <conditional expression 2>   ALSO TRUE      ALSO FALSE
6.     <statements applicable to above condition>
7.  
8.   WHEN <conditional expression n>   ALSO FALSE     ALSO TRUE
9.     <statements applicable to above condition>
10.  
11.   etc for the remaining conditions
12.  
13.   WHEN OTHER
14.     <statements applicable to above condition>
15. END-EVALUATE
16.  

Each column in a WHEN clause is matched against its corresponding column in the EVALUATE.  For instance, the first WHEN line

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

1.   WHEN <conditional expression 1>   ALSO TRUE      ALSO TRUE

is matched against the "TRUE", "A > B", "X = Z" in the EVALUATE.  The equivalent Pascal construct for that specific line is

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

1. if (<conditional expression 1>) and (A > B) and (X = Z) then <statements applicable to above condition>;

What may be a source of confusion is that the <conditional expression> can be placed in the EVALUATE clause or the WHEN clause. 

if the expression can vary, as in the first column in the example above, then it is placed in the WHEN clause because that allows each WHEN to specify a different expression to be matched against the TRUE in the EVALUATE clause.

If the expression does not change, as is the case with A > B in column 2 and X = Z in column 3 then it is best to specify it in the EVALUATE clause and match them against the desired logical value, i.e, TRUE, FALSE, ANY in the EVALUATE clause.

Also, what I used in the example is standard COBOL syntax.  If you'd like, you can see the entire syntactic possibility of the EVALUATE statement by Googling "COBOL evaluate statement" but, if you've never used COBOL there are some possibilities that will not be obvious and/or easy to understand.

HTH.

[Martin_fr]

Here is how it translates:

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

1.   EVALUATE TRUE                         ALSO A > B                 ALSO X = Z
2.       WHEN        <expression 1>        ALSO           TRUE        ALSO            TRUE
3. //     IF  TRUE = <expression 1>        AND  (A > B) = TRUE        AND   (X = Z) = TRUE
4.         <statements applicable to above condition>
5.      
6.       WHEN       <expression 2>         ALSO           TRUE        ALSO            FALSE
7. //ELSE IF  TRUE = <expression 2>        AND  (A > B) = TRUE        AND   (X = Z) = FALSE
8.         <statements applicable to above condition>
9.      
10.       WHEN       <expression n>         ALSO           FALSE       ALSO            TRUE
11. //ELSE IF  TRUE = <expression n>        AND  (A > B) = FALSE       AND   (X = Z) = TRUE
12.         <statements applicable to above condition>
13.      
14.       etc for the remaining conditions
15.      
16.       WHEN OTHER
17.         <statements applicable to above condition>
18.     END-EVALUATE
19.      

With the exception, that with"evaluate" any part in the evaluate is calculate only once (matters if there a function calls with side effects).

Also "evaluate" allows you do use other operators, not just "="

An of course using "if" you might use the more readable "not ..." instead of "false = (...)"