Ann: DeCoperators

[Thaddy]

This is a utility that takes {$coperators} contaminated pascal code and replaces all C-style operators with sane Pascal:
Example:

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

1. program testcoperators;
2. {$ifdef fpc}{$mode objfpc}{$endif}
3. var
4.   a,b,c,d:integer;
5.   e,f:double;
6.   s:string;
7. begin
8.   a+=a;a -= a; e/=f;
9.   s:='a line with some calculation like a-=a in the middle';
10.   c *= d;a += a;
11. end.

Becomes:

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

1. program testcoperators;
2. {$ifdef fpc}{$mode objfpc}{$endif}
3. var
4.   a,b,c,d:integer;
5.   e,f:double;
6.   s:string;
7. begin
8.   a := a + a;a := a - a; e := e / f;
9.   s:='a line with some calculation like a := a - a in the middle';
10.   c := c * d;a := a + a;
11. end.

Maybe I should skip the string feature? Or as option?
Maybe I should make the spacing configurable?

Let me know if you like it....

(currently needs trunk to compile. I will de-trunk it, because that are just two lines)

[Thaddy]

I have added a version for 3.2.x above.

[dseligo]

It would be nice if FPC and Lazarus are cleaned first.

[440bx]

I find the goal of removing the presence of C operators to be of dubious value.

I would give some thought to implementing the feature correctly instead, using something like what Ada uses.

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

1.   SomeVar { which may be a long complex qualified identifier } := @ <operator> <expression>
2.  

The "@" stands for the RHS in the LHS.  In spite of the "@" already being in use in Pascal for other purposes, it seems it could be used for this purpose as there does not seem to be possible to create an ambiguity with current use (current usage does not allow @ followed by an operator anywhere.)

if that new feature was added to FPC (using @ to represent the LHS) then a utility to "massage" the old syntax would be a nice thing to have.

Also, semantically it makes a lot more sense than the C approach of creating new operators.  The @ does not create any operators, it is simply a shorthand representation of the LHS.  As simple as it gets.

[n7800]

This is a utility that takes {$coperators} contaminated pascal code and replaces all C-style operators with sane Pascal

This is a really interesting function! It would be great if it were implemented using CodeTools and made into an IDE package.

Actually, the existing "JEDI Code Format" package comes to mind, this would be a great addition to it. By the way, there are already some settings for spaces. @Thaddy, would you like to create a feature request?

[440bx]

This is a utility that takes {$coperators} contaminated pascal code and replaces all C-style operators with sane Pascal:
Example:

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

1. program testcoperators;
2. {$ifdef fpc}{$mode objfpc}{$endif}
3. var
4.   a,b,c,d:integer;
5.   e,f:double;
6.   s:string;
7. begin
8.   a+=a;a -= a; e/=f;
9.   s:='a line with some calculation like a-=a in the middle';
10.   c *= d;a += a;
11. end.

Becomes:

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

1. program testcoperators;
2. {$ifdef fpc}{$mode objfpc}{$endif}
3. var
4.   a,b,c,d:integer;
5.   e,f:double;
6.   s:string;
7. begin
8.   a := a + a;a := a - a; e := e / f;
9.   s:='a line with some calculation like a := a - a in the middle';
10.   c := c * d;a := a + a;
11. end.

Whenever I write some utility that changes code I make sure I can match the changes to the original code.  In the examples you provided that means the following:

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

1. program testcoperators;
2. {$ifdef fpc}{$mode objfpc}{$endif}
3. var
4.   a,b,c,d:integer;
5.   e,f:double;
6.   s:string;
7. begin
8.   a+=a;a -= a; e/=f;
9.  
10.   < more statements >
11. end.

Becomes:

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

1. program testcoperators;
2. {$ifdef fpc}{$mode objfpc}{$endif}
3. var
4.   a,b,c,d:integer;
5.   e,f:double;
6.   s:string;
7. begin
8.   {!decop a+=a;} {!decop a -= a; } {!decop e/=f; }
9.   a := a + a;a := a - a; e := e / f;
10.  
11.   < more statements >
12. end.

That way I can verify every change before accepting it.  Once I've ensured everything is as it should be then, I run another utility that gets rid of the {!decop .... } comments.

Last thing I need is some utility to create hard to find bugs.

Honestly, I wouldn't use a utility that can potentially make such sweeping changes in code.  I would implement it as a macro which I'd run on an as-needed basis, that way, the change and verification occurs on the spot and one by one (which in the case of C operators use is fine.)

ETA:

The macro would not act on the entire file, it would act on a _single_ instance of a statement implemented using a C operator.  In the example, that means the macro would be invoked 3 times since there are 3 expressions that use C operators.

It's slower to do it that way but, it's much safer and takes a whole lot less time than having to hunt for a bug that happened as a result of a utility that swept through the code making changes that are difficult to visually locate.

[Martin_fr]

Whenever I write some utility that changes code I make sure I can match the changes to the original code.  In the examples you provided that means the following:

Reasonable. So, I guess for me the comments would not be the best option...

To me the answer to this is: git (or any version control system of choice, including copy of the file/folder). And then a visual diff.
With version control, I can also go back, if I didn't see anything, but a year later notice something strange.
- Don't want to keep the comments for a year
- Comments are more work to compare than a nice visual diff-utility.

[440bx]

- Comments are more work to compare than a nice visual diff-utility.

I get rid of the comments as I verify the change is correct.

[Martin_fr]

- Comments are more work to compare than a nice visual diff-utility.

I get rid of the comments as I verify the change is correct.

Yes, I understand. And I didn't mean to say comment are generally the worse way (Hence "Reasonable"). I just meant to say my personal preference is different.

Diffs allow me to use tools like Meld/WinMerge.

Git allows me to commit small amends, and squash at the end. So I can track what I have done (if the overall amount requires this).
And I can go back in a year should I need to.

Also Diff against a temporary copy, and Meld/WinMerge allow me to update the lines that I checked. Then the diff goes away step by step.
(That could even by a branch, so I can do other work in between, and merge it to avoid it showing in the diff).

-------------------
Comments allow all that do, except they don't have the nice "the following chars/words in this line changed" highlight.

And you need the "repeat search" kept on the pattern for the comment. Or how do you get to the next comment? So if you need other searches in between...

Advantage comments: You only need one App open. I need 2 (3 if you count git, in case I actually involve it). But, I have plenty of screen space, so I can cover that.

[440bx]

I think your method is reasonable too.

Personally, I prefer to meticulously verify everything myself, this means, I don't rely on a version control system.  Before I initiate any major change, I keep an archived copy of the entire project then proceed to make incremental changes and repeat this cycle until the project is complete.

If I need to find differences among versions of my project, something which is _extremely_ rare, I use BeyondCompare.  I say extremely rare because I usually have a detailed and complete list of changes in my mind made since the last archive.  I use BeyondCompare when I don't trust my recollection to be complete or fully accurate and, that only happens when I failed to partition the project into reasonable chunks.

I find VCSs useful for teams of programmers.  For a single programmer, I believe that they should not be needed because the programmer can (and should) track his/her work and should not need a vcs to do that (maybe a few more years on my back and I may need a vcs but, fortunately, not yet.)

That's why when I use some automated thing to make changes to code, I want the original code to be present in commented out form and the new code to be immediately underneath the commented out code.  That way I can quickly verify every change.  Also, it is extremely rare that I would use a program to make wholesale changes throughout source code, I cannot even remember if I ever used such a program.  The closest I come to that is to use my editor to do search/replace on a group of files (which may be very large) that make up a project but, that means, I inspect/approve every change before it happens.
 
This is also one of the reason I am very careful with the use of A.I.  When that stuff generates code, I re-read _every single line_ of code the thing generated and, I won't have it any other way no matter the size of the project.

[Thaddy]

It would be nice if FPC and Lazarus are cleaned first.

FPC is clean. Lazatus not. fpc packages also not all clean, but the compiler is very clean.

[Thaddy]

@440bx

The matching is strictly line by line. No lines are added or removed.
There is no need for diff style comparisons. But you have the code and it is as easy as storing the changed line info from the main DefussLine function.

[Thaddy]

I find the goal of removing the presence of C operators to be of dubious value.

For one it is a requirement to have compiler patches accepted or any utility code that is maintained by the core team.

Decorating the code with extra lines is a very bad idea in a line based parser.
I can add a diff writer though, that is very easy., needs a small change in Defussline().

(If you really care, I could also simple call git to do that.)

[440bx]

For one it is a requirement to have compiler patches accepted or any utility code that is maintained by the core team.

hmmmm... considering how often FPC releases happen, it's not much of a requirement but, ok.

Decorating the code with extra lines is a very bad idea in a line based parser.

The extra lines are temporary and only exist to make visual verification easy and simple, they are deleted as part of the verification process. 

I hope you don't simply presume the program worked without any verification. 

[Thaddy]

I hope you don't simply presume the program worked without any verification.

It is tested against some packages that I know use the shortcuts like the new fcl-css and rtl-generics (generics.hashes.pas). Passed.
There are packages, though, where it would definitely fail and those are the code that do Pascal parsing like fcl-passrc: because that also parses the shortcuts, we would damage the code. There are also corner cases I encountered in comments, so I will skip the comments/string literals in the next version.