Recent

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

munair

  • Hero Member
  • *****
  • Posts: 781
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: how to break out early of a case ?
« Reply #120 on: November 29, 2021, 10:51:41 pm »
Who would prefer the second syntax if the first were available?
Not to mention that there is no good reason not to have the first option.  It's the natural option.

I remember having this discussion before and if memory serves me well, the grouped initialization syntax cannot be easily implemented in FPC. While I haven't looked at the FPC source myself, I can imagine that if the parser feeds the syntax directly to a AST structure, the initialization may be a problem.

SharpBASIC doesn't do it like that. It collects all declarations with type and initialization (immediate) and adds them to the symbol table. After the stack frame is setup the symbol table (with initializations) is read out and the variables are initialized.

The following code:
Code: Text  [Select][+][-]
  1. sub test()
  2.   dim a, b, c: int = 0;
  3.   dim s1, s2: str;
  4. do
  5.  
  6. end;

would generate:
Code: ASM  [Select][+][-]
  1.         push    ebp
  2.         mov     ebp, esp
  3.         sub     esp, 20
  4. ; load immediate
  5.         movsx   eax, byte [_sb_refn]
  6. ; save a
  7.         mov     [ebp - 4], eax
  8. ; save b
  9.         mov     [ebp - 8], eax
  10. ; save c
  11.         mov     [ebp - 12], eax
  12. ; create local variable string 's1'
  13.         call    _sb_create_strdesc
  14. ; save descriptor address
  15.         mov     [ebp - 16], eax
  16.  
  17. ; create local variable string 's2'
  18.         call    _sb_create_strdesc
  19. ; save descriptor address
  20.         mov     [ebp - 20], eax

With or without grouped initialization, the output would be the same, but we have the compiler to do the dirty work for us, as it should be.  ;)
« Last Edit: November 30, 2021, 12:11:48 pm by munair »
keep it simple

440bx

  • Hero Member
  • *****
  • Posts: 2624
Re: how to break out early of a case ?
« Reply #121 on: November 29, 2021, 10:57:15 pm »
Code: Pascal  [Select][+][-]
  1. var
  2.   a, b, c: integer = (0, 0, 0);
  3.   s1, s2: string;
  4. begin
  5. //..
  6. end;
I would not be in favor of that one because transpositions are a common error.  That construction makes it too easy to inadvertently swap initial values.



ETA:

I remember having this discussion before and if memory serves me well, the grouped initialization syntax cannot be easily implemented in FPC. While I haven't looked at the FPC source myself, I can imagine that if the parser feeds the syntax directly to a AST structure, the initialization may be a problem.
Yes, I remember that too.  From memory and, if I understood what was said at the time, apparently there is some code that is shared with other portions of the compiler that would not welcome the minor changes required in parsing an initial value. 

SharpBASIC doesn't do it like that. It collects all declarations with type and initialization (immediate) and adds them to the symbol table. After the stack frame is setup the symbol table (with initializations) is read out and the variables are initialized.
That's the best way of doing it.  Much more powerful and flexible.
« Last Edit: November 29, 2021, 11:19:19 pm by 440bx »
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 9778
  • FPC developer.
Re: how to break out early of a case ?
« Reply #122 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: 3680
Re: how to break out early of a case ?
« Reply #123 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: 2624
Re: how to break out early of a case ?
« Reply #124 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 on Windows 7 64bit.

MarkMLl

  • Hero Member
  • *****
  • Posts: 3680
Re: how to break out early of a case ?
« Reply #125 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: 4610
    • Bart en Mariska's Webstek
Re: how to break out early of a case ?
« Reply #126 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: 3680
Re: how to break out early of a case ?
« Reply #127 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: 781
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: how to break out early of a case ?
« Reply #128 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: 9778
  • FPC developer.
Re: how to break out early of a case ?
« Reply #129 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: 3656
  • Compiler Developer
Re: how to break out early of a case ?
« Reply #130 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: 3680
Re: how to break out early of a case ?
« Reply #131 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: 781
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: how to break out early of a case ?
« Reply #132 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: 3680
Re: how to break out early of a case ?
« Reply #133 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: 781
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: how to break out early of a case ?
« Reply #134 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

 

TinyPortal © 2005-2018