* * *

Author Topic: Annoying issues in Object Pascal - what are those?  (Read 7366 times)

ASerge

  • Sr. Member
  • ****
  • Posts: 431
Re: Annoying issues in Object Pascal - what are those?
« Reply #30 on: February 14, 2017, 01:24:54 pm »
@Lupp
See example:
Code: Pascal  [Select]
  1. type
  2.   T1 = array of Integer;
  3.   T2 = array of array [1..100] of Integer;
  4.   T3 = array of array of Integer;
  5.   T4 = array [1..100] of array of Integer;
  6.   T5 = array [1..10, 5..20, 3..40] of array [1..6] of array of Integer;
  7. var
  8.   A1: T1;
  9.   A2: T2;
  10.   A3: T3;
  11.   A4: T4;
  12.   A5: T5;
  13.   N: Integer;
  14. begin
  15.   N := 8;
  16.   SetLength(A1, N);
  17.   A1[1] := 1;
  18.   SetLength(A2, N);
  19.   A2[2, 10] := 2;
  20.   SetLength(A3, N, 4);
  21.   A3[5, 3] := 3;
  22.   SetLength(A4[88], N + 2);
  23.   A4[88, N + 1] := 4;
  24.   SetLength(A5[1, 6, 22, 4], N - 2);
  25.   A5[1, 6, 22, 4, N - 3] := 5;
  26. end;
All memory free at procedure end;

bytebites

  • Full Member
  • ***
  • Posts: 117
Re: Annoying issues in Object Pascal - what are those?
« Reply #31 on: February 14, 2017, 01:53:31 pm »
Concerning the syntax (and semantics) of alternatives, whether complete: if ... then ... else  or incomplete: if ... then

I prefer to understand begin  end as a pair of parentheses for the purpose of making one item out of many  like ( )  [ ]  do in different contexts. C, C++ actually use the curly brackets for the case of statements where Pascal uses reserved words for better distinctness (and out of old tradition) .

Unpaired parentheses are a plague!

If there will be changes in this field one day I would prefer to abandon these wry pairs:    record   end  and   case   end.
Are there more?
At least
class end
try except/finally end

Lupp

  • New member
  • *
  • Posts: 30
Re: Annoying issues in Object Pascal - what are those?
« Reply #32 on: February 14, 2017, 03:11:42 pm »
@ASerge: It's not completely clear to me if you wanted to tell me "You are wrong!", and if so with which one of my theses.

What I see is a demonstration of how you suggest to get dynamic arrays of many dimensions. These are shaped to a size calculated from a varianble only with respect to one (the last one by index position) dimension.

I cannot see a demonstration about how
- to get a satisfying surrogate for array[1..m, 1..n] of Double
= to write a procedure for, say, the multiplication of two arrays callable like MatMult(Left, Right, RowsLeft, CommonSize, ColsRight, Result)
= (Editing) ...or, even much better, without the three sizing parameters.
This is: Without the need of mapping pairs of indices to 1D.

What did I miss?
« Last Edit: February 14, 2017, 04:45:54 pm by Lupp »

jacmoe

  • Sr. Member
  • ****
  • Posts: 259
    • Jacmoe's Cyber SoapBox
Re: Annoying issues in Object Pascal - what are those?
« Reply #33 on: February 14, 2017, 03:15:09 pm »
Coming from C/C++ and having a good grasp on Python and Javascript, while being a PHP developer also, I happen to really appreciate begin - end pairs.  ;D

To me, begin / end pairs - especially when written in all lowercase - sort of blends into the background, but are so much better in explaining block levels than whitespace (Python) or braces (most other languages).

Yes, it is verbose, but I like that verbosity because it reads well.
It is much more difficult to read out loud C++ code.
In FPC, a class constructor is called 'constructor', and abstract methods are called 'abstract'.
Yes, it's wordy, but you sort of need to learn to love it. It is Pascal, after all.
more signal - less noise

ASerge

  • Sr. Member
  • ****
  • Posts: 431
Re: Annoying issues in Object Pascal - what are those?
« Reply #34 on: February 15, 2017, 01:56:44 am »
- to get a satisfying surrogate for array[1..m, 1..n] of Double
= to write a procedure for, say, the multiplication of two arrays callable like MatMult(Left, Right, RowsLeft, CommonSize, ColsRight, Result)
= (Editing) ...or, even much better, without the three sizing parameters.
This?
Code: Pascal  [Select]
  1. program Project1;
  2.  
  3. {$APPTYPE CONSOLE}
  4.  
  5. type
  6.   T2DArray = array of array of Double;
  7.  
  8. function Init2DArray(M, N: Integer): T2DArray;
  9. begin
  10.   SetLength(Result, M, N);
  11. end;
  12.  
  13. function Multiply2DArray(const A, B: T2DArray): T2DArray;
  14. var
  15.   i, k: Integer;
  16. begin
  17.   SetLength(Result, Length(A), Length(A[0]));
  18.   for i := 0 to High(A) do
  19.     for k := 0 to High(A[0]) do
  20.       Result[i, k] := A[i, k] * B[i, k];
  21. end;
  22.  
  23. procedure Print2DArray(const A: T2DArray);
  24. var
  25.   i, k: Integer;
  26. begin
  27.   for i := 0 to High(A) do
  28.   begin
  29.     for k := 0 to High(A[0]) do
  30.       Write(A[i, k]:5:2, '  ');
  31.     Writeln;
  32.   end;
  33.   Writeln;
  34. end;
  35.  
  36. var
  37.   A, B, C: T2DArray;
  38. begin
  39.   A := Init2DArray(2, 3);
  40.   B := Init2DArray(2, 3);
  41.   A[0, 0] := 1; A[0, 1] := 2; A[0, 2] := 3;
  42.   A[1, 0] := 4; A[1, 1] := 5; A[1, 2] := 6;
  43.   B[0, 0] := 7; B[0, 1] := 8; B[0, 2] := 9;
  44.   B[1, 0] := 10; B[1, 1] := 11; B[1, 2] := 12;
  45.   C := Multiply2DArray(A, B);
  46.   Print2DArray(A);
  47.   Print2DArray(B);
  48.   Print2DArray(C);
  49.   ReadLn;
  50. end.

ASerge

  • Sr. Member
  • ****
  • Posts: 431
Re: Annoying issues in Object Pascal - what are those?
« Reply #35 on: February 15, 2017, 02:35:34 am »
The only annoying thing for me is that something like this is not yet possible:
Code: Pascal  [Select]
  1. try
  2.   ...
  3. except
  4.   ...
  5. finally
  6.   ...
  7. end;
Not very useful. Often used option
Code: Pascal  [Select]
  1. try
  2.   Alloc;
  3.   try
  4.     DoSome;
  5.   finally
  6.     Free;
  7.   end;
  8. except
  9.   HandleErrors;
  10. end;
not covered by this pattern.
Ideologically different design. Try finally to conserve resources, but try except for error handling.

lazjump

  • Jr. Member
  • **
  • Posts: 61
Re: Annoying issues in Object Pascal - what are those?
« Reply #36 on: February 15, 2017, 03:32:29 am »
I think the opposite.

Years ago I read the source of VCL and as long as I remember they almost always had try...except inside try...finally. This is the most often usage. Not the opposite.

try...except...finally...end would be very useful and used often.


The only annoying thing for me is that something like this is not yet possible:
Code: Pascal  [Select]
  1. try
  2.   ...
  3. except
  4.   ...
  5. finally
  6.   ...
  7. end;
Not very useful. Often used option
Code: Pascal  [Select]
  1. try
  2.   Alloc;
  3.   try
  4.     DoSome;
  5.   finally
  6.     Free;
  7.   end;
  8. except
  9.   HandleErrors;
  10. end;
not covered by this pattern.
Ideologically different design. Try finally to conserve resources, but try except for error handling.
I thought Delphi was expensive until I learned the price of ExtJS

Phil

  • Hero Member
  • *****
  • Posts: 2305
Re: Annoying issues in Object Pascal - what are those?
« Reply #37 on: February 15, 2017, 04:21:24 am »
The only annoying thing for me is that something like this is not yet possible:
Code: Pascal  [Select]
  1. try
  2.   ...
  3. except
  4.   ...
  5. finally
  6.   ...
  7. end;
Not very useful.

Other languages have a "unified" try/except/finally. That doesn't preclude the use of nested try/finally and try/except as in the 2nd example.

https://www.python.org/dev/peps/pep-0341/

https://msdn.microsoft.com/en-us/library/dszsf989.aspx

In Pascal and other languages, try/finally and try/except (or catch) are really two different things, but confusingly introduced by the same try keyword. try/finally is about doing things that have to be done to clean up properly, completely unrelated to whether an exception occurred. try/except is only about handling the unexpected exception condition.

The Swift language does it in a way that keeps the two concepts separate: do-catch, like try/except. And defer, which can be used any number of places in a code block. Any time resources have been allocated, you can immediately use defer to specify the clean up. One obvious advantage is that the cleanup code is physically close to the resource allocation. In the other languages, the cleanup code in finally is often many lines away from where the resources were allocated. See example at bottom of page here:

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/ErrorHandling.html

ASerge

  • Sr. Member
  • ****
  • Posts: 431
Re: Annoying issues in Object Pascal - what are those?
« Reply #38 on: February 15, 2017, 05:00:27 am »
Years ago I read the source of VCL and as long as I remember they almost always had try...except inside try...finally. This is the most often usage. Not the opposite.
try...except...finally...end would be very useful and used often.
I quickly try this code:
Code: Pascal  [Select]
  1. procedure ParseFile(const FileName: string; Result: TStrings);
  2. var
  3.   Source, Sorted: TStringList;
  4.   i, Level, GroupCount: Integer;
  5.   Line, TryLine, Group: string;
  6. begin
  7.   Sorted := TStringList.Create;
  8.   try
  9.     Sorted.Sorted := True;
  10.     Sorted.Duplicates := dupAccept;
  11.     Source := TStringList.Create;
  12.     try
  13.       Source.LoadFromFile(FileName);
  14.       Level := 0;
  15.       TryLine := '';
  16.       for i := 0 to Source.Count - 1 do
  17.       begin
  18.         Line := Source[i];
  19.         if AnsiEndsText('try', Line) then
  20.         begin
  21.           Inc(Level);
  22.           TryLine := TryLine + 'try ';
  23.         end;
  24.         if AnsiEndsText('finally', Line) then
  25.         begin
  26.           Dec(Level);
  27.           TryLine := TryLine + 'finally ';
  28.           if Level <= 0 then
  29.           begin
  30.             Sorted.Append(Trim(TryLine));
  31.             TryLine := '';
  32.             Level := 0;
  33.           end;
  34.         end;
  35.         if AnsiEndsText('except', Line) then
  36.         begin
  37.           Dec(Level);
  38.           TryLine := TryLine + 'except ';
  39.           if Level <= 0 then
  40.           begin
  41.             Sorted.Append(Trim(TryLine));
  42.             TryLine := '';
  43.             Level := 0;
  44.           end;
  45.         end;
  46.       end;
  47.     finally
  48.       Source.Free;
  49.     end;
  50.     Group := '';
  51.     GroupCount := 0;
  52.     for i := 0 to Sorted.Count - 1 do
  53.     begin
  54.       Line := Sorted[i];
  55.       if Group <> Line then
  56.       begin
  57.         if Group <> '' then
  58.           Result.Append(Format('%-3d: %s', [GroupCount, Group]));
  59.         Group := Line;
  60.         GroupCount := 1;
  61.       end
  62.       else
  63.         Inc(GroupCount);
  64.     end;
  65.     if GroupCount > 0 then
  66.       Result.Append(Format('%-3d: %s', [GroupCount, Group]));
  67.   finally
  68.     Sorted.Free;
  69.   end;
  70. end;
  71.  
  72. procedure TForm1.Button1Click(Sender: TObject);
  73. begin
  74.   Memo1.Clear;
  75.   ParseFile('c:\Program Files (x86)\Borland\Delphi7\Source\Rtl\Common\Classes.pas',
  76.     Memo1.Lines);
  77. end;
And get result:
Code: Pascal  [Select]
  1. 12 : try except
  2. 84 : try finally
  3. 2  : try try except except
  4. 2  : try try except finally
  5. 1  : try try finally except
  6. 7  : try try finally finally
  7. 1  : try try try finally finally except
  8. 1  : try try try finally finally finally
  9. 1  : try try try try except finally finally finally
  10. 1  : try try try try finally finally finally finally
  11. 1  : try try try try finally finally try except except finally
Line 4, line 9 and may be line 11 it's not used often. In most cases, they are used separately

Thaddy

  • Hero Member
  • *****
  • Posts: 4525
Re: Annoying issues in Object Pascal - what are those?
« Reply #39 on: February 15, 2017, 07:15:36 am »
Line 4, line 9 and may be line 11 it's not used often. In most cases, they are used separately
Hm. then they should be used more often, because the finally protects also resources from within an exception block.
I use it all the time. I thought most real programmers would ..
Because you can really recover from the exception gracefully and without memory leaks.
It's even best practice.
« Last Edit: February 15, 2017, 07:17:17 am by Thaddy »
"Logically, no number of positive outcomes at the level of experimental testing can confirm a scientific theory, but a single counterexample is logically decisive."

jacmoe

  • Sr. Member
  • ****
  • Posts: 259
    • Jacmoe's Cyber SoapBox
Re: Annoying issues in Object Pascal - what are those?
« Reply #40 on: February 15, 2017, 08:47:08 pm »
I think it is really unfortunate that try except and try finally are separate.

Coming from other languages, it is not very intuitive.

That is an annoying issue in my book.
Easy to work around, but annoying none the less IMO.

Edit:
Thinking about it, having a try except nested in a try finally could be a more explicit way of expressing how try except finally actually works..
« Last Edit: February 15, 2017, 08:54:09 pm by jacmoe »
more signal - less noise

bee

  • Sr. Member
  • ****
  • Posts: 306
Re: Annoying issues in Object Pascal - what are those?
« Reply #41 on: February 17, 2017, 03:14:28 am »
My own complain about modern Pascal limitations:

1. try…except and try…finally being separated. Too many words to type while it can be simplified as try…except…finally.

2. Dedicated block for vars and consts is a limitation when you need to create consts on the fly or in the middle of a program, such as:
Code: Pascal  [Select]
  1. const x = function(a)

3. Incompatible type for similar data type, such as:
Code: Pascal  [Select]
  1. type
  2.   aoi: array of integer;
  3.  
  4. function a(i: array of integer);
  5.  

4. More helper on basic types, such as for array, so newcomers don't need to dig the docs.

5. More complex data type such as tuples and dictionaries.

I think modern Pascal can learn from Swift which I think a new programming language that brings old features with better syntaxes.
-Bee-

A long time pascal lover.

Thaddy

  • Hero Member
  • *****
  • Posts: 4525
Re: Annoying issues in Object Pascal - what are those?
« Reply #42 on: February 17, 2017, 05:02:38 am »
Well dictionaries are both in rtl-generics and in FGL (where it's called map, same thing, though).
"Logically, no number of positive outcomes at the level of experimental testing can confirm a scientific theory, but a single counterexample is logically decisive."

Zoran

  • Hero Member
  • *****
  • Posts: 1148
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: Annoying issues in Object Pascal - what are those?
« Reply #43 on: February 17, 2017, 10:01:50 am »
Line 4, line 9 and may be line 11 it's not used often. In most cases, they are used separately
Hm. then they should be used more often, because the finally protects also resources from within an exception block.
I use it all the time. I thought most real programmers would ..
Because you can really recover from the exception gracefully and without memory leaks.
It's even best practice.

I wonder if there is a real difference between these two procedures (because, in Proc2, DoCleanup is executed, whether or not DoSomething raises exception, same as in Proc1, right?):

Code: Pascal  [Select]
  1. procedure Proc1;
  2. begin
  3.   try
  4.     try
  5.       DoSomething;
  6.     except
  7.       HandleExceptions;
  8.     end;
  9.   finally
  10.     DoCleanup;
  11.   end;
  12. end;
  13.  

and

Code: Pascal  [Select]
  1. procedure Proc2;
  2. begin
  3.   try
  4.     DoSomething;
  5.   except
  6.     HandleExceptions;
  7.   end;
  8.   DoCleanup;
  9. end;
  10.  

EDIT:
Ah, I was too quick, I see what you mean:
because the finally protects also resources from within an exception block.
« Last Edit: February 17, 2017, 10:05:29 am by Zoran »

Thaddy

  • Hero Member
  • *****
  • Posts: 4525
Re: Annoying issues in Object Pascal - what are those?
« Reply #44 on: February 17, 2017, 11:27:31 am »
As an aside I found some generic tuple code for Delphi on github and after some minor changes that works on FPC - only trunk - too..
Have to ask Malcolm if I can use it/publish it for FPC.
"Logically, no number of positive outcomes at the level of experimental testing can confirm a scientific theory, but a single counterexample is logically decisive."

 

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus