Recent

Author Topic: how to break out early of a case ?  (Read 66072 times)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: how to break out early of a case ?
« Reply #120 on: November 29, 2021, 10:58:49 pm »
The concrete difference between those two is that, if used properly, the first construct informs the programmer that the two variables in the declaration should be of the same type. 

But it can also be viewed as an coincidental side-effect of an old shorthand. Without concrete reasons, and only statements of intent the difference can't be easily settled.

To be honest: I don't know either way, both thoughts have occurred to me over the years.

But whatever the reason is, that kind of undocumented intent is IMHO a very shaky ground to build some grand consistency argument on top of.

What's next, reviewing of all block structures to omit vowels other than "e" and "i", because those are the ones that are in begin and end, for consistency's sake ?   (I'm glad that all those years of watching absurd British comedy finally pay off, making it easy to find ridiculous comparisons)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: how to break out early of a case ?
« Reply #121 on: November 29, 2021, 11:08:37 pm »
What's next, reviewing of all block structures to omit vowels other than "e" and "i",

No, i should be removed on account of its similarity to 1. And e should be removed in homage to Georges Perec's magnum opus.

Seriously chaps... there's no need to be silly

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: how to break out early of a case ?
« Reply #122 on: November 29, 2021, 11:12:06 pm »
But whatever the reason is, that kind of undocumented intent is IMHO a very shaky ground to build some grand consistency argument on top of.
Undocumented ?... it seems to me that one of the things programmers have to learn early in the process of learning to program is to group things that belong together (like declarations and sequences of code) and keeping separate, things that don't belong together (which usually goes by the more academically polished word "modularization".)

I have not seen any programming manuals document that the reader has to have the ability of recognizing individual glyphs, grouping them, associating a semantic meaning to specific groups in order to be able to read the fine manual.  Should I open a bug against the FPC documentation to have this undocumented requirement be brought to light ?


« Last Edit: November 29, 2021, 11:18:18 pm by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: how to break out early of a case ?
« Reply #123 on: November 29, 2021, 11:27:17 pm »
I have not seen any programming manuals document that the reader has to have the ability of recognizing individual glyphs, grouping them, associating a semantic meaning to specific groups in order to be able to read the fine manual.

https://en.wikipedia.org/wiki/Principia_Mathematica

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: how to break out early of a case ?
« Reply #124 on: November 29, 2021, 11:58:26 pm »
Should I open a bug against the FPC documentation to have this undocumented requirement be brought to light ?
You most definitively must!

Bart

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: how to break out early of a case ?
« Reply #125 on: November 30, 2021, 12:15:57 am »
Should I open a bug against the FPC documentation to have this undocumented requirement be brought to light ?
You most definitively must!

I've managed to write an appendix in a technical manual on the assumed difference between "male" and "female" in terms of connectors, but I think your suggestion would be straining credibility.

Seriously: I think it's a valid point, but I don't think that much can be done that isn't at least attempted by (E)BNF and "railroad diagrams".

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

munair

  • Hero Member
  • *****
  • Posts: 798
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: how to break out early of a case ?
« Reply #126 on: November 30, 2021, 02:47:35 pm »
What's next, reviewing of all block structures to omit vowels other than "e" and "i", because those are the ones that are in begin and end, for consistency's sake ?

Toying with keywords is not the same as completing a syntax that is already supported for 80% and that, by contrast, wouldn't break any compatibility. So it's not a fair comparison IMO.
keep it simple

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: how to break out early of a case ?
« Reply #127 on: November 30, 2021, 02:49:54 pm »
I have not seen any programming manuals document that the reader has to have the ability of recognizing individual glyphs, grouping them, associating a semantic meaning to specific groups in order to be able to read the fine manual.  Should I open a bug against the FPC documentation to have this undocumented requirement be brought to light ?

No, try to file at Webster's site. It is a disgrace if it isn't in there.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: how to break out early of a case ?
« Reply #128 on: November 30, 2021, 11:23:16 pm »
However as a counterexample I'd like to highlight the ALGOL-style conditional expression that Wirth unaccountably omitted from Pascal:

Code: [Select]
  a := if b then c else d;

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

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

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

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

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: how to break out early of a case ?
« Reply #129 on: December 01, 2021, 08:46:13 am »
I had added it back in January 2016 (see announcement mail of which the thread continued into February). After some heated discussions both on the public mailing list as well as the core one I removed it again in February. The addition of the intrinsic is still part of the version history and I think somewhere I still have a patch for the ifthenelse - expression (alternatively it would be easily derivable from the provided commit for the IfThen intrinsic).

Thanks for that. Hence https://lists.freepascal.org/pipermail/fpc-pascal/2016-February/046626.html followed by https://lists.freepascal.org/pipermail/fpc-pascal/2016-February/046641.html

I don't like flame wars, and from my POV the core team has made their position clear. But it still rankles that a fundamental element that apparently gave ALGOL no problems was omitted from Pascal.

I also don't like C-style usage of ? since it breaks the otherwise-close correspondence between operators and procedure/function invocation, which in all cases evaluate parameters before applying the operation.

But that's my personal opinion.

Code: Text  [Select][+][-]
  1. fn main() {
  2.     let condition = true;
  3.     let number = if condition { 5 } else { 6 };
  4.  
  5.     println!("The value of number is: {}", number);
  6. }
  7.  

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

munair

  • Hero Member
  • *****
  • Posts: 798
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: how to break out early of a case ?
« Reply #130 on: December 01, 2021, 10:07:31 am »
Code: Text  [Select][+][-]
  1. fn main() {
  2.     let condition = true;
  3.     let number = if condition { 5 } else { 6 };
  4.  
  5.     println!("The value of number is: {}", number);
  6. }
  7.  

MarkMLl

In my opinion this code is messy because the keywords IF and ELSE in such languages are both statements and operators. The syntax is trivial at best because it can be written in statements with the same effort and same amount of code. The only benefit is that the code is crammed on a single line. What benefit is that? There's absolutely no need here to make things more complicated for the compiler. A wise decision that Pascal didn't adopt it.
keep it simple

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: how to break out early of a case ?
« Reply #131 on: December 01, 2021, 10:10:41 am »
In my opinion this code is messy because the keywords IF and ELSE in such languages are both statements and operators. The syntax is trivial at best because it can be written in statements with the same effort and same amount of code. The only benefit is that the code is crammed on a single line. What benefit is that? There's absolutely no need here to make things more complicated for the compiler. A wise decision that Pascal didn't adopt it.

I'll leave you to argue that with the Rust community, and with the ALGOL-60 designers before them. I'm done with arguing.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

munair

  • Hero Member
  • *****
  • Posts: 798
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: how to break out early of a case ?
« Reply #132 on: December 01, 2021, 10:35:30 am »
In my opinion this code is messy because the keywords IF and ELSE in such languages are both statements and operators. The syntax is trivial at best because it can be written in statements with the same effort and same amount of code. The only benefit is that the code is crammed on a single line. What benefit is that? There's absolutely no need here to make things more complicated for the compiler. A wise decision that Pascal didn't adopt it.

I'll leave you to argue that with the Rust community, and with the ALGOL-60 designers before them. I'm done with arguing.

MarkMLl

Actually, discussions like these can be inspiring. I might just think of supporting a similar shorthand for the compiler I'm working on. But it should be clear and different from other statements, perhaps something like:
Code: Text  [Select][+][-]
  1. by condition { number = 5, 6 };

The benefit of such construct is that due to a different keyword (by) it could be processed separately and never reach the expression parser. Just a spontaneous idea.
keep it simple

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: how to break out early of a case ?
« Reply #133 on: December 01, 2021, 12:30:46 pm »
But that's my personal opinion.

Code: Text  [Select][+][-]
  1. fn main() {
  2.     let condition = true;
  3.     let number = if condition { 5 } else { 6 };
  4.  
  5.     println!("The value of number is: {}", number);
  6. }
  7.  

MarkMLl
I really like the python version:
Code: Pascal  [Select][+][-]
  1. myvar = 6 if condition else 7
By switching the if and value around, you can basically set a focus, the value you put first is so to say the "important" value. Also it allows really great chaining:
Code: Pascal  [Select][+][-]
  1. myvar = a if condition1 \
  2.    else b if condition2 \
  3.    else c if condition3 \
  4.    else d
It's (if used with linebreaks) a very clear syntax that is easy to read and understand and also resembles how you would write conditionals in mathematical notation

Compared to for example the condition first syntax:
Code: Pascal  [Select][+][-]
  1. myvar = if Condition1 then a
  2.    else if condition2 then b
  3.    else if condition3 then c
  4.    else d;
Here you have always to read the conditions (which might be long expressions themselves) before you get to the value.

It's a question on what a reader might focus, the thing you write first is the thing that the programmer will read and understand at first, while for the second part they might even need to scroll. I think that  it is more important to see what are the possible values, over what are the possible conditions.

Actually, discussions like these can be inspiring. I might just think of supporting a similar shorthand for the compiler I'm working on. But it should be clear and different from other statements, perhaps something like:
Code: Text  [Select][+][-]
  1. by condition { number = 5, 6 };

The benefit of such construct is that due to a different keyword (by) it could be processed separately and never reach the expression parser. Just a spontaneous idea.
Personally, just from looking at it, I think this solution isn't very great, because if I didn't have the context on what it is supposed to mean, I wouldn't understand it. Languages should be expressive on their own, reading a program  should be as easy as possible.

Also I think it would be really cluttered if it was chained
« Last Edit: December 01, 2021, 12:41:52 pm by Warfley »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: how to break out early of a case ?
« Reply #134 on: December 01, 2021, 01:02:46 pm »
I think the major parsing problem is if the ALGOL-style expression is used (for some crazy reason) when a function result is discarded, e.g.

Code: Pascal  [Select][+][-]
  1. { success := } if someSyscall(...) = 0 then true else false
  2.  

...which will, of course, be rejected by the compiler albeit for the wrong reason. But this is hardly the first time that the compiler's produced not quite the right error message.

MarkMLl
« Last Edit: December 01, 2021, 01:54:15 pm by MarkMLl »
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018