Recent

Author Topic: FPC Feature request/suggestion  (Read 19862 times)

Zoran

  • Hero Member
  • *****
  • Posts: 1829
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: FPC Feature request/suggestion
« Reply #120 on: April 28, 2020, 11:45:03 am »
My biggest problem with the Delphi implementation of inline variables is that it isn't always obvious what the visibility scope of a variable is.
I don't see much wrong with inline variables, they're reverting to the well-considered ALGOL-60 form.
They encourage messy and poorly organized code.
I totally agree with 440bx. The complexity, overhead (compiler-wise) and confusion (programmer-wise) outweigh the benefits.

In general, having all declarations in one section gives a non-trivial overview and is easier/faster for the compiler to process.

I agree too. 440bx already gave nice proposal for inline block-scopes syntax.
Unlike Delphi's inline variables, I would like this.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC Feature request/suggestion
« Reply #121 on: April 28, 2020, 12:11:31 pm »
My biggest problem with the Delphi implementation of inline variables is that it isn't always obvious what the visibility scope of a variable is.
I don't see much wrong with inline variables, they're reverting to the well-considered ALGOL-60 form.
They encourage messy and poorly organized code.
I totally agree with 440bx. The complexity, overhead (compiler-wise) and confusion (programmer-wise) outweigh the benefits.

In general, having all declarations in one section gives a non-trivial overview and is easier/faster for the compiler to process.

I agree too. 440bx already gave nice proposal for inline block-scopes syntax.
Unlike Delphi's inline variables, I would like this.

I didn't necessarily say that I liked them completely undelimited, and I consider Pascal's syntax with undelimited constant, type and variable sections to be little better than that of COBOL.

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

Otto

  • Full Member
  • ***
  • Posts: 226
Re: FPC Feature request/suggestion
« Reply #122 on: April 28, 2020, 01:25:40 pm »
Hello MarkMLl

[...]
More interesting is

Code: [Select]
  for var i: Integer := 1 to 10 do
  begin  // starts a new scope
    var j: integer := i;  // This should be possible
    var i: integer := i;  // But what about this?
    var k: integer := i;  // And this?
...
  end;

Again, Wirth decided not just to enforce a "variable must be declared before use" rule, but also broke ALGOL compatibility by moving variable to before a procedure/function's begin. I don't see much wrong with inline variables, they're reverting to the well-considered ALGOL-60 form.

MarkMLl

In Embarcadero® Delphi 10.3:

Code: Delphi  [Select][+][-]
  1. for var i: Integer := 1 to 10 do begin
  2.    var j: integer := i;  // This should be possible  -> Yes
  3.    // var i: integer := i;  // But what about this?  -> [dcc32 Error] Unit1.pas(36): E2004 Identifier redeclared: 'i'
  4.    var k: integer := i;  // And this?                -> Yes
  5. end;
  6.  

Kind regards.

munair

  • Hero Member
  • *****
  • Posts: 798
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: FPC Feature request/suggestion
« Reply #123 on: April 28, 2020, 02:05:52 pm »
In Embarcadero® Delphi 10.3:

Code: Delphi  [Select][+][-]
  1. for var i: Integer := 1 to 10 do begin
  2.    var j: integer := i;  // This should be possible  -> Yes
  3.    // var i: integer := i;  // But what about this?  -> [dcc32 Error] Unit1.pas(36): E2004 Identifier redeclared: 'i'
  4.    var k: integer := i;  // And this?                -> Yes
  5. end;
  6.  

From a higher level language point of view, declarations inside loops give the feeling/impression that they are being re-declared with every iteration, effectively disrupting the logic/readability of the code being looped. Declarations as static code should not be mixed with dynamic code. It's like old BASIC where every variable that was assigned out of the blue anywhere in code implicitly became a newly declared variable. It stimulates a disorderly / chaotic programming style, which should be discouraged at all times. 
keep it simple

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: FPC Feature request/suggestion
« Reply #124 on: April 28, 2020, 02:20:11 pm »
From a higher level language point of view, declarations inside loops give the feeling/impression that they are being re-declared with every iteration, effectively disrupting the logic/readability of the code being looped.
Couldn't agree anymore and, in addition to that, it makes it more difficult to see loop-invariants that may have slipped in there.  It makes everyone's job harder, the programmer's and the compiler's.  That's one of the many problems the user-defined inline scopes prevent.  Inline variables are just a hack, useful if used conservatively and with great care, a can of worms otherwise.

And, from a low-level language point of view... declaring DB, DW and DD (among others) in code is occasionally used for tricks or to include read-only data in a code segment but, mixing code and data is rarely a good idea (though used somewhat commonly to make reverse engineering slightly more difficult.)
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: FPC Feature request/suggestion
« Reply #125 on: April 28, 2020, 03:36:42 pm »
It's removing a check and adding a loop and presto, you're done! (global variables would be another topic) Here. For those that want to play around with it I've attached a patch. I won't commit this however (aside the fact that it would also need to be added for global variables for consistency).
Presto! ... you're already halfway there... you're not the kind of person that does only half... now you got to finish it. :)
(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: FPC Feature request/suggestion
« Reply #126 on: April 28, 2020, 03:39:21 pm »
Presto! ... you're already halfway there... you're not the kind of person that does only half... now you got to finish it. :)

:-)

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

Otto

  • Full Member
  • ***
  • Posts: 226
Re: FPC Feature request/suggestion
« Reply #127 on: April 28, 2020, 04:08:07 pm »
Hello PascalDragon.

Maybe with a little variation on the syntax of the FPC or a special mode of Lazarus we could have something like:

Code: Text  [Select][+][-]
  1.  var
  2.       Avariable:=0, AnotherVariable:=0 : integer;  
  3.  

Definitely no. The compiler needs to know the type first. Thus 440bx's suggestion would technically be possible, yours would not.

Thanks for the information.

(I should like to begin by to say that I am only marginally interested in this specific syntactic issue.)

However, I would like to have a clarification on the following general points:
  • Does the compiler need to know the type of the variable before the variable name, because it compiles in one step, and as soon as it encounters an error of this specific nature it stops permanently?
  • In these cases, there are no exceptions to allow adaptation to alternative Syntax, such as a possible "NewPascal mode"?
  • If you decide to adopt a possible "NewPascal mode", would it be possible to reverse the position of the type declaration order with that of a variable name (var integer: a:=0, b:=0;)?
  • Would it be possible to consider a special mode of Lazarus that would convert "alternative" statements to "canonical" FPC?

(The latter alternative I introduced in my first post of this thread in "or" mode, but I'm not sure that your answer also included this possibility or referred only to the other possibility)

Thank you in advance for your possible response.

 
Kind regards.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: FPC Feature request/suggestion
« Reply #128 on: April 28, 2020, 04:55:43 pm »
It's removing a check and adding a loop and presto, you're done! (global variables would be another topic) Here. For those that want to play around with it I've attached a patch. I won't commit this however (aside the fact that it would also need to be added for global variables for consistency).
Presto! ... you're already halfway there... you're not the kind of person that does only half... now you got to finish it. :)

I work with git-svn, I do many proof-of-concepts and discard them again. :P Also just looking at the case for global variables I think: nope, not going to touch that one.

However, I would like to have a clarification on the following general points:
  • Does the compiler need to know the type of the variable before the variable name, because it compiles in one step, and as soon as it encounters an error of this specific nature it stops permanently?

It needs to know the type so that it can parse it correctly. E.g. if it's string or integer. Also the syntax for initialized variables already is Name: Type = Value. Yours would add a second way (cause why shouldn't it work with a single variable?) which is something that should be avoided when designing a language.

  • In these cases, there are no exceptions to allow adaptation to alternative Syntax, such as a possible "NewPascal mode"?
  • If you decide to adopt a possible "NewPascal mode", would it be possible to reverse the position of the type declaration order with that of a variable name (var integer: a:=0, b:=0;)?

If a language mode is too incompatible we're inclined to say: nope, not going to support that. We need to maintain that after all and each diversion adds to the complexity of the parser.

  • Would it be possible to consider a special mode of Lazarus that would convert "alternative" statements to "canonical" FPC?

Not my area.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: FPC Feature request/suggestion
« Reply #129 on: April 28, 2020, 05:03:32 pm »
Would it be possible to consider a special mode of Lazarus that would convert "alternative" statements to "canonical" FPC?

I don't think it will go inside the default IDE.
But anyone could provide a 3rd party add-on package, which if installed, will provide it.

Or for personal use, you can write pascal-script editor macros that could assist you in converting such code.

ASerge

  • Hero Member
  • *****
  • Posts: 2222
Re: FPC Feature request/suggestion
« Reply #130 on: April 28, 2020, 05:58:27 pm »
By the way, I remembered one of the commandments of c++ (java): Do not declare more than one variable per declaration. Bad code
Code: C  [Select][+][-]
  1. int i, j = 1;
Is there a justification for that commandment or is it simply ordained by divine powers that appeared next to a burning hard drive ?
Sorry, I thought you were familiar with C. This code is bad because the variable i remains uninitialized, although it seems that it is also assigned a value like the variable j. It is this frequent error that gave rise to this commandments.

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: FPC Feature request/suggestion
« Reply #131 on: April 28, 2020, 06:02:50 pm »
Sorry, I thought you were familiar with C. This code is bad because the variable i remains uninitialized, although it seems that it is also assigned a value like the variable j. It is this frequent error that gave rise to this commandments.
I'm not familiar with C, I'm _too_ familiar with C and, one of the many reasons I strongly dislike it is because it's much too easy to overlook something because it is counter-intuitive.

Thank you for pointing out that oversight on my part.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

munair

  • Hero Member
  • *****
  • Posts: 798
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: FPC Feature request/suggestion
« Reply #132 on: April 28, 2020, 07:08:37 pm »
If it is of any help, the key part that collects one or more identifiers in a var-statement (both global and local) in SharpBASIC (rough schematic):

Code: FreeBasic  [Select][+][-]
  1. ' tmp dcl scope
  2. sys.scp_create()
  3.  
  4. ' collect identifier(s)
  5. do
  6.   i.tok = lex.cutok
  7.  
  8.   sys.tok_expect(tkLiteral.nIdentifier)
  9.   sys.idn_add(i)
  10.        
  11.   if lex.cutok.tid = tkSymbol.nComma then
  12.  
  13.     lex.getok()
  14.    
  15.   else
  16.  
  17.     exit do
  18.    
  19.   end if
  20.  
  21. loop
  22.  
  23. sys.tok_expect(tkSymbol.nColon)
  24.  
  25. ' // check datatype ...
  26.  
  27. ' // check initial value (if any) ...
  28.  
  29. ' process identifiers
  30. for ii = 0 to sys.idn_cnt() - 1
  31.  
  32.   ' // check identifier name ...
  33.        
  34.   ' actual scope
  35.   sys.scp_dec()
  36.  
  37.   ' // check duplicate ...
  38.        
  39.   sys.idn_add(i)            ' to symbol table
  40.   sys.scp_inc()             ' tmp dcl scope
  41.        
  42. next
  43.  
  44. ' destroy tmp scope
  45. sys.scp_destroy()

The compiler creates a temporary scope above the actual scope and saves the identifier(s) to it. If the datatype and possible initial value check out fine, the identifiers themselves are being checked and copied to their actual scope. Finally, the temporary scope is destroyed.
« Last Edit: April 29, 2020, 08:24:33 am by munair »
keep it simple

 

TinyPortal © 2005-2018