Recent

Author Topic: Re: language improvement suggestions (the spin off)  (Read 16996 times)

440bx

  • Hero Member
  • *****
  • Posts: 5010
Re: language improvement suggestions (the spin off)
« on: November 24, 2019, 02:40:27 am »
Introduction of a new statement along with new keywords will not improve the readability of the program at all.
The readability improvement(s) will depend on the statement's expressiveness compared to that of existing statements, not on its being new or old.

Especially that it doesn't add anything new to the language but only replaces the existing syntax. For me this is unnecessary noise
I do have to agree that if it doesn't add anything then its value is definitely questionable.  It should be mentioned that _clarity_ is something and, it is very valuable in programming.

Try the following with "if"/"else":
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 1>   <the remaining combinations of true/false for the other 2 expressions>
  6.  
  7.   WHEN <conditional expression 2>   ALSO TRUE      ALSO FALSE
  8.     <statements applicable to above condition>
  9.  
  10.   WHEN <conditional expression 2>   <the remaining combinations of true/false for the other 2 expressions>
  11.  
  12.   WHEN <conditional expression n>   ALSO FALSE     ALSO TRUE
  13.     <statements applicable to above condition>
  14.  
  15.   WHEN <conditional expression n>   <the remaining combinations of true/false for the other 2 expressions>
  16.  
  17.   etc for the remaining conditions
  18.  
  19.   WHEN OTHER
  20.     <statements applicable to above condition>
  21. END-EVALUATE
  22.  
What a nice mess of "if"/"else" that produces in Pascal and C.  Not to mention that this construction makes it very easy to verify that every possible condition of interest is in the list and, if instead of variables such as A and B are used, functions with side effects in their parameters are used, the statement is stable (since they are evaluated only once) unlike the equivalent if/else chain in Pascal and C.

Not only such a construct is much cleaner, it is stable and easily verifiable for correctness.  That construct allows creating multivariable logic tables that are very easy to read, understand and verify, and if all that wasn't enough, because of the way it is structured, it is much easier and simpler for the compiler to generate optimized code for it than for the equivalent "if"/"else" mess.

(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10837
  • Debugger - SynEdit - and more
    • wiki
Re: Re: language improvement suggestions (the spin off)
« Reply #1 on: November 24, 2019, 02:45:39 am »
The readability improvement(s) will depend on the statement's expressiveness compared to that of existing statements, not on its being new or old.
Not confirming, just restating. You say: What we currently have is too complex. So you want to replace it. You will end up adding, and the result is even more complex.
https://xkcd.com/927/

440bx

  • Hero Member
  • *****
  • Posts: 5010
Re: Re: language improvement suggestions (the spin off)
« Reply #2 on: November 24, 2019, 03:06:28 am »
The readability improvement(s) will depend on the statement's expressiveness compared to that of existing statements, not on its being new or old.
Not confirming, just restating. You say: What we currently have is too complex. So you want to replace it. You will end up adding, and the result is even more complex.
No.  What I'm saying is that there are common logical constructs that could be made _simpler_ hence easier to understand and maintain with constructs the language, Pascal in this particular case, is currently missing.  IOW, have _simple_ constructs that simplify the expression of complex logical relationships.  The "evaluate" statement is a good example of that.  It is easy to understand, easy to use and it greatly simplifies expressing multivariate logical relationships.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10837
  • Debugger - SynEdit - and more
    • wiki
Re: Re: language improvement suggestions (the spin off)
« Reply #3 on: November 24, 2019, 03:30:39 am »
Missing the point. My last statement was not about, if your example makes something better or worse.
My last statement only said, that better or worse (in cases of extending a language) is almost always a matter of view.
Better for you. Worse for someone else.

Well actually it was including that it gets worse, but not because your Syntax is worse, but because there are more options for the syntax for the same thing.

To make this even more clear. By showing that it is well possible to see it as worse, I wanted to show that both views are possible.
And by referring to the image, I wanted to keep it light, and not make it about my opinion vs yours (for the latter see below)


As for my view (since you successfully dragged we into a deja vu):
I have no idea what your "evaluate" statement attempts to do. Which means so far, it has not improved readability. It has brought it down to zero.
It looks like it may be from some sql dialect, but I could not find which.

« Last Edit: November 24, 2019, 03:44:18 am by Martin_fr »

440bx

  • Hero Member
  • *****
  • Posts: 5010
Re: Re: language improvement suggestions (the spin off)
« Reply #4 on: November 24, 2019, 04:22:07 am »
Missing the point.
I admit to have concentrated on "You will end up adding, and the result is even more complex." and my point is that adding shouldn't be seen as adding complexity, it can be seen as adding simplicity (when it does, which is what it should do.)

My last statement only said, that better or worse (in cases of extending a language) is almost always a matter of view.
Better for you. Worse for someone else.
Your including the word "almost" in there makes it difficult to argue otherwise.  I agree to a limited extent.   My premise is that inter-related logical relationships can be graphed and, the complexity of the resulting graph can be mathematically determined.  If a language construct result in the creation of a simpler graph for the same set of logical relationships than another construct, then that construct has demonstrably simplified the problem regardless of someone's feelings of having had their life made more complex as a result.

IOW, 2 + 2 = 4 is simpler than 1 + 1 + 1 + 1 = 4 in spite of the fact that someone may feel that their life got more complex because their fingers aren't glued together in pairs.

Well actually it was including that it gets worse, but not because your Syntax is worse, but because there are more options for the syntax for the same thing.
And any simplifications are definitely welcome. 

As for my view (since you successfully dragged we into a deja vu):
It's a pleasure to drag you into these things :)  (of course, in a friendly manner.)

I have no idea what your "evaluate" statement attempts to do. Which means so far, it has not improved readability. It has brought it down to zero.
I will promptly remedy that. 
Code: ASM  [Select][+][-]
  1. 1.EVALUATE TRUE                       ALSO A > B     ALSO X = Z
The first column compares any expression against TRUE, the second column compares the expression A > B against its corresponding ALSO value ("true", "false" or "any" for such an expression), the same thing for the third column.  In Pascal code the first WHEN line would be:
Code: Pascal  [Select][+][-]
  1. if (<conditional expression 1>) and (A > B) and (X = Z) then
  2. begin
  3.   <statements ... >
  4.  
  5.   break;  // there is no break in Pascal but just to indicate that the statement ends on the first match.
  6. end
and so on for the rest of the conditions.  One, but not the only one, of the nice things about that construct is that the conditions (A > B) and (X = Z) don't have to be retyped for every test.  One of the reason it's nice is because since both are only typed once, the chances of getting one of them wrong is much smaller than when they have to be retyped n times.  Another very nice thing about it is that it makes it really easy to determine if every possibility appears, for instance, if the value of the two expressions in the ALSO column must be tested then the count of conditions (appearance of WHEN clauses) should be n * 4, if it isn't then some condition has been missed.

Conclusion: the same construct using "if"/"else" requires retyping the expressions which opens the door to errors and verifying that every possible condition has been taken into account is cumbersome because they are buried in the midst of "if"/"else" syntactic elements.

It looks like it may be from some sql dialect, but I could not find which.
It is from COBOL85 and above.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10837
  • Debugger - SynEdit - and more
    • wiki
Re: Re: language improvement suggestions (the spin off)
« Reply #5 on: November 24, 2019, 02:02:01 pm »
Your including the word "almost" in there makes it difficult to argue otherwise. 
Good, because that (adding > complex?) has been discussed on this forum for myriads of times. Not again.


Quote
and so on for the rest of the conditions.  One, but not the only one, of the nice things about that construct is that the conditions (A > B) and (X = Z) don't have to be retyped for every test.
ok, so it saves  a few local vars.

Or reordering into 4 big blocks, for each bool/bool variation.

Quote
One of the reason it's nice is because since both are only typed once, the chances of getting one of them wrong is much smaller than when they have to be retyped n times.
But as the number of column grows the chances are introduced that you get a true/false swapped between 2 columns. (I guess you cant miss it, as the total count will be checked)

Quote
  Another very nice thing about it is that it makes it really easy to determine if every possibility appears, for instance, if the value of the two expressions in the ALSO column must be tested then the count of conditions (appearance of WHEN clauses) should be n * 4, if it isn't then some condition has been missed.
Code: Pascal  [Select][+][-]
  1. if        (<conditional expression 1>)                             and          {not}  AbOK          and             {not}    XzOK           then
With the correct spacing, you achieve exactly the same.
It is just replacing each keyword by another, (and the local tmp var)


Syntactic sugar. Important to your case (or style), but not to mine. (good for some, bad for other)

This last sentence refers to the many other sugar feature requests, in which this kind of statement was heavily debated already. If you must, repeat your site of the argument. Mine was stated often enough and needs no repetition (I just reiterate the thesis).

lainz

  • Hero Member
  • *****
  • Posts: 4689
  • Web, Desktop & Android developer
    • https://lainz.github.io/
Re: Re: language improvement suggestions (the spin off)
« Reply #6 on: November 24, 2019, 02:14:09 pm »
The readability improvement(s) will depend on the statement's expressiveness compared to that of existing statements, not on its being new or old.
Not confirming, just restating. You say: What we currently have is too complex. So you want to replace it. You will end up adding, and the result is even more complex.
https://xkcd.com/927/

 :D true

In Kotlin there is when and the IDE (IntelliJ or Android Studio) suggests and converts from if, else if, else if.. automatically.

https://kotlinlang.org/docs/reference/control-flow.html#when-expression

It can be used to remove nested if..else.

Thaddy

  • Hero Member
  • *****
  • Posts: 16580
  • Kallstadt seems a good place to evict Trump to.
Re: Re: language improvement suggestions (the spin off)
« Reply #7 on: November 24, 2019, 02:41:11 pm »
In Kotlin there is when and the IDE (IntelliJ or Android Studio) suggests and converts from if, else if, else if.. automatically.

https://kotlinlang.org/docs/reference/control-flow.html#when-expression

It can be used to remove nested if..else.
Code: Pascal  [Select][+][-]
  1. {$macro on}{$define when:=case}{$define but:=else}
« Last Edit: November 24, 2019, 02:42:58 pm by Thaddy »
But I am sure they don't want the Trumps back...

lainz

  • Hero Member
  • *****
  • Posts: 4689
  • Web, Desktop & Android developer
    • https://lainz.github.io/
Re: Re: language improvement suggestions (the spin off)
« Reply #8 on: November 24, 2019, 03:15:52 pm »
Code: Pascal  [Select][+][-]
  1. {$macro on}{$define when:=case}{$define but:=else}

Yes is stated on the documentation I linked is a replacement of case (switch in C).

But I didn't know that Pascal case is meant to replace if..else like this:

Code: Text  [Select][+][-]
  1. fun main() {
  2.     val a = true
  3.     val b = true
  4.     val c = false
  5.     val d = true
  6.     when {
  7.         a && b && c -> println("1")
  8.         a && b && d -> println("2")
  9.     }
  10. }

Is possible in Pascal with case?

The example is not the best, but is meant to replace nested if else, adding all combinations in a vertical way.

This doesn't compile:
Code: Pascal  [Select][+][-]
  1. var
  2.   a, b, c, d: boolean;
  3. begin
  4.   a := true;
  5.   b := true;
  6.   c := false;
  7.   d := true;
  8.  
  9.   case true of
  10.      a and b and c: writeln('1');
  11.      a and b and d: writeln('2');
  12.   end;
« Last Edit: November 24, 2019, 03:27:56 pm by lainz »

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Re: Re: language improvement suggestions (the spin off)
« Reply #9 on: November 24, 2019, 06:12:35 pm »
This doesn't compile:
Code: Pascal  [Select][+][-]
  1. var
  2.   a, b, c, d: boolean;
  3. begin
  4.   a := true;
  5.   b := true;
  6.   c := false;
  7.   d := true;
  8.  
  9.   case true of
  10.      a and b and c: writeln('1');
  11.      a and b and d: writeln('2');
  12.   end;
However, this does compile:
Code: Pascal  [Select][+][-]
  1.     case (a and b and c) of
  2.        True: WriteLn('1');
  3.        False: case (a and b and d) of
  4.                 True: WriteLn('2');
  5.               end;
  6.     end;

lainz

  • Hero Member
  • *****
  • Posts: 4689
  • Web, Desktop & Android developer
    • https://lainz.github.io/
Re: Re: language improvement suggestions (the spin off)
« Reply #10 on: November 24, 2019, 06:45:15 pm »
Yes, but that misses the point of simplify the reading fo the code.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10837
  • Debugger - SynEdit - and more
    • wiki
Re: Re: language improvement suggestions (the spin off)
« Reply #11 on: November 24, 2019, 06:45:37 pm »
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.  

I still do not know, if this behaves like a waterfall if ... if else ... if else; or like simple consecutive "if". The latter meaning that more than one block can be entered.

In any case, one thing that "case" is about, is that only one and no more case-section can be entered.
Therefore case-labels have to be constants, and not expressions or variables (so the compiler can check at compile time).

Otherwise the above is just case with tuples. (If tuples were a pascal feature. Tuples have been discussed before, no need to repeat that here, if needed then continue any of their existing threads)
Code: Pascal  [Select][+][-]
  1. case TTuple(val, a>b, c>d) of
  2.   TTuple(1,True,True): ;
  3.   TTuple(1,True,False): ;
  4. end;
Assuming TTuple is a language feature and returns a constant.
Also assuming that like for strings, case would have special handling for tuples.


None of the above is to say that I am in any way in favour of any of this.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10837
  • Debugger - SynEdit - and more
    • wiki
Re: Re: language improvement suggestions (the spin off)
« Reply #12 on: November 24, 2019, 07:06:45 pm »
Yes, but that misses the point of simplify the reading fo the code.
As I tried to point out, that really is not a point.

Readability is to a good measure a personal matter. What is readable to one person, may not be readable at all to another.

That is not to say that there are not certain things that are pretty much affecting all people the same when it come to readability. Like "scrambled and obscured" vs "one of many ways to format code and descriptive identifier names".

But as anyone can see from looking at different projects, even code formatting is not straight format. Different people find different indentation/spacing/line-breaking style helpful. And what is most read-able for one, is least readable for another.

What is IMHO not helpful is if styles are mixed. (Unless you like having to constantly adapt while reading the code). The more styles are on offer, the more this mix will happen. Unless you have no 3rd party interference at all.
Just doing an LCL project, already exposes you to: RTL style, LCL style, your style, and maybe 3rd party packages.


As I mentioned at the begin of the above, this is not against new features. This is about using readability as an argument for new features or changes.
When looking at the overall experience of the many users of FPC (rather than just the few for whom the change is highly desirable), then unless substantial research data exists to show otherwise, it is probably that
any potential gain in one place, will be lost in another.

This conclusion stems from the idea that without any knowledge ("substantial research"), it would be unlikely to assume the best or the worst case.
Best case: The change improves readability.
Worst case: The change decreases readability.
Assumption in absence of knowledge: It does neither (Or very little in one of the two directions). => Not doing anything is not an argument for changing something.

lainz

  • Hero Member
  • *****
  • Posts: 4689
  • Web, Desktop & Android developer
    • https://lainz.github.io/
Re: Re: language improvement suggestions (the spin off)
« Reply #13 on: November 24, 2019, 07:27:58 pm »
I can agree with that. Is true that reading depends on your knowledge of the language, I can't even read and I doubt I will read and understand all pascal code out there anyways.

Adding more stuff can simplify the reading, but if you know what are you reading, you must know that extra stuff and what it means.

Of course case is not the same as if..else, and has an optimization behind. But the ones that don't know about compiler things, can't say if is easy or not to add a new feature or if it will break a lot of stuff anyways, that is another point.

For example I can't read easily or understand what it does the ifThen at the first time, but is there and some may say cool is easier to read, but I can't get it, so I can relate what one will feel seeing the case without constants...

440bx

  • Hero Member
  • *****
  • Posts: 5010
Re: Re: language improvement suggestions (the spin off)
« Reply #14 on: November 24, 2019, 09:03:17 pm »
Good, because that (adding > complex?) has been discussed on this forum for myriads of times. Not again.
I'm not really sure what you're saying there but, I am as disinterested in discussing that as you are.  That one is taken care of. :)

ok, so it saves  a few local vars.

Or reordering into 4 big blocks, for each bool/bool variation.
It does a whole lot more than that and, I will also address the following statements of yours, all in one shot:
With the correct spacing, you achieve exactly the same.
It is just replacing each keyword by another, (and the local tmp var)
When using "if"/"else" to implement the equivalent of that EVALUATE statement, the expressions, in this case A > B and X = Z have to be retyped but, that's not the really bad part, the really bad part is that the programmer who is maintaining that code has to _read_ every statement and ensure that the conditions _match_ in every subsequent statement.   

With the EVALUATE statement, the programmer knows immediately just by reading the EVALUATE statement that A > B and X = Z are the _only_ two other expressions involved.  It isn't necessary to read _every_ single if/else statement to ensure the conditions are the same and to match them with every previous if/else and every if/else that follows.  This makes the code significantly easier to understand and maintain and that is _not_ syntactic sugar, that is a logical flow that reflects much more accurately the program logic than a nest of if/else statements.

Just in case the advantage of the above isn't completely clear, consider this
Code: Pascal  [Select][+][-]
  1. type
  2.   TSOMERANGE = 0..20;
  3.  
  4.   <more stuff here>
  5.  
  6.   for i in TSOMERANGE do <statements here>
that construct is a significant improvement over
Code: Pascal  [Select][+][-]
  1. for i := low(TSOMERANGE)..high(TSOMERANGE) do < statements here>
and the reason is because in the first case the low and high bounds of the loop are expressed in a single expression, that is, atomically; whereas in the second case the programmer has to _read_ two expressions, low() and high() - which may not necessarily refer to the same type - to determine what the bounds of the for loop are.

Similarly with the EVALUATE statement, reading the EVALUATE clause tells the programmer what expressions are involved in columns 2 and 3 immediately.  There is _no_ need to read every statement and ensure that the expressions in column 2 and 3 are always the same.  That is not syntactic sugar, that is simply cleaner, much easier to understand and maintain code.

In addition to that, the conditions used in an if/else sequence are _not_ guaranteed to be stable/constant.  For instance, if instead of variables A, B, X and Z, functions which take A, B, X and/or Z as var parameters are used and the functions change the value of the parameters A, B, X and/or Z, then using an if/else chain would not yield the correct result since the function values would potentially change every time the function is called which is necessary to evaluate each if statement.

And, if all that wasn't enough, that construction makes it much easier for the compiler to generate optimal code, i.e, code that isn't evaluating the expression in column 2 and 3 again and again and again and again... yuk!

Just for the record, I am not asking for the EVALUATE to be implemented in Pascal (though, it would be very nice if it were - I wouldn't be against it ;)), my intention is to show that there are control flow structures that would really improve the language.  In addition to that, that construction is already in use in a major language (COBOL and possibly others) where it has proven to produce significantly more readable and maintainable code when dealing with multi-branch conditions.


Syntactic sugar. Important to your case (or style), but not to mine. (good for some, bad for other)

This last sentence refers to the many other sugar feature requests, in which this kind of statement was heavily debated already. If you must, repeat your site of the argument. Mine was stated often enough and needs no repetition (I just reiterate the thesis).
This isn't syntactic sugar unless the definition of syntactic sugar includes constructs such as, for instance, "for" and "repeat/until" loops. It is a much clearer and powerful way of expressing multi-branch conditions just as "for" and "repeat/until" loops are a much cleaner and more powerful way of implementing loops without having to resort to "goto" or some other contorted way of controlling program flow.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

 

TinyPortal © 2005-2018