Lazarus

Free Pascal => General => Topic started by: jacmoe on February 12, 2017, 05:14:32 pm

Title: Annoying issues in Object Pascal - what are those?
Post by: jacmoe on February 12, 2017, 05:14:32 pm
I have been following Lazarus and Free Pascal for years..

I usually use C++ and Qt for desktop application development.
I never cared for C# and .NET.
Probably because I became a Delphi addict in 1997.
(I left that for C and C++ because I wanted to do graphics programming, and because Borland screwed up)..

I have read the excellent article Quick Modern Object Pascal for Programmers (http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html)

In my mind, compared to other languages, modern Object Pascal does feature of lot of good things: properties, interfaces, classes, even low level stuff like pointers and memory management.

I am tired of C++, and having a break from it, devoting my time to learn proper C (c11), Rust, Python and Racket (Scheme).

But, when I picked up Lazarus - finally, a week ago, because the time was right! I noticed that I was actually writing fully featured desktop applications easily. Using modules, abstract interfaces and other advanced stuff that would have taken a lot of effort in other languages.

I know that a lot of people are using Javascript for user interfaces and they even create desktop applications in it. Kudos to them. I am not going to touch that!

OK.
So, what's the catch?

.. as much as I enjoy coding in Object Pascal, it DOES have a variety of annoying limitations that simply aren't present in other languages.) What does all this mean? In my opinion, it means FPC and Lazarus have far more "on their plate" that most people think: without them, Object Pascal would almost certainly drift completely into the "legacy" category.

I have enough experience with programming languages to know that nothing is perfect.
But I am curious - what are those annoying limitations?

For me, what I really like:
easy deployment
no runtime
painless cross compilation
properties and event handling without a complicated MOC compiler
you don't have to be a language lawyer to use advanced features
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Thaddy on February 12, 2017, 05:19:41 pm
Me too ....


Always boils down to the same:
- first they're gonna mention anonymous methods.... I predicted it first...
- then they mix up strongly typed compiled languages with dynamic languages
- then they start complaining about missing features that in reality are just libraries
etc.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: jacmoe on February 12, 2017, 05:51:05 pm
I am looking at the foundation page, and it looks like anonymous functions is being worked on.

I don't know how active the projects are - Lazarus and Free Pascal, but it doesn't look too bad.

I do like that it is open source.

I almost forgot to mention another feature that I really appreciate:
Unit compilation.
Compile once!
How awesome is that, compared to C++, when working on larger projects.
A small change, and then you have to wait for a looooooong compile..

That this is a strongly typed compiled language is one of the major features of FPC.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Phil on February 12, 2017, 06:01:36 pm
But I am curious - what are those annoying limitations?

Offhand, nothing pops into my head as being an "annoying limitation" for me personally, so let me rephrase the question: What would keep someone coming from another language from landing on Pascal and sticking? Or, perhaps, what would someone coming from another language miss as they begin writing little test apps to see if Pascal is right for them?

Well, say you're coming from Python. As you write those little test apps, you might find yourself missing...

- Doing multiprocessing in 5 lines of code.

- Opening, parsing and working with a CSV file in 5 lines of code.

- Tuples as function return values (without declaring it as a type). (Swift has this too.)

- Indenting to indicate code blocks instead of begin/end or braces. Surprisingly, this is a feature I found myself liking about Python. Not only does it dispense entirely with begin/end and braces, making for cleaner-looking code, it also forces programmers to indent consistently.

That sort of thing.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: marcov on February 12, 2017, 06:14:27 pm
As Phil demonstrates, most of those arguments are highly subjective. (well actually, the tuples bit is a hard fact, though returning a dynamic array of variant will get you far in many cases).

IMHO it is the usual overfocus on language, one can bicker about minor variations and omissions at infinitum, but they really don't save that many time anymore when the base requisites are met.

More interesting is to consider that that desktop apps are Delphi/Lazarus home turf. If you want to find defects you will have to go out of that comfortable bubble, to webapps, service apps etc. Yes they are possible, and there are some frameworks, but none as complete and dominant as LCL is for desktop apps.

Then there are other aspects, like quality of debugging (weak compared to commercial offering), no cheap shared hosting for webapps (like PHP or to some degree asp.net).
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: jacmoe on February 12, 2017, 06:20:03 pm
That you need to declare variables in a separate section before being able to use them - sort of like old C - could be seen as an annoying issue by some.
Personally, I like that, because it forces you to think a bit more, and it also makes it easier to overlook the code.

I don't mind the 'begin - end' blocks - I am used to curly braces in C / C++.

Python is a different beast (a snake) than Lazarus/FPC (a cheetah) - it is very expressive. And I enjoy it. But I wouldn't use it for larger projects.

Opening and parsing and working with a CSV file with LCL is probably just a matter of dropping a CSV component on a form and use it in an action with a file dialog.
Probably not 5 lines, but extremely rapid.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Phil on February 12, 2017, 06:22:35 pm
Then there are other aspects, like quality of debugging (weak compared to commercial offering), no cheap shared hosting for webapps (like PHP or to some degree asp.net).

Right, it's not the language per se that has kept Pascal out of Web apps, or mobile development, or even whole areas of programming. Case in point: GIS. Join the "community of one" and do GIS with Pascal (https://macpgmr.github.io/MacXPlatform/PascalDynLibs_3.html) or join the thousands of Python developers who have been doing GIS for years (http://plugins.qgis.org/plugins)?

Pascal itself is quite adaptable. For example, it even fits into the world of Xcode and Objective C pretty well (https://macpgmr.github.io/MacXPlatform/WebAppOverview_3.html#EmbeddedBrowser). It's just that nobody embraces it in these new areas.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: jacmoe on February 12, 2017, 06:27:26 pm
More interesting is to consider that that desktop apps are Delphi/Lazarus home turf. If you want to find defects you will have to go out of that comfortable bubble, to webapps, service apps etc. Yes they are possible, and there are some frameworks, but none as complete and dominant as LCL is for desktop apps.
Yes, indeed.
I am aware that desktop applications is not exactly 'what everyone is doing' these days.
However, if you want to do that, what options are there?
Java? With clunky syntax, huge libraries and a runtime to boot?
.NET (C#) with runtime requirement?
C++ and Qt with complexities and MOC compilers?
Or WxWidgets with C++ and MFC-like macros?

For me, Lazarus definitely makes desktop application development great again.

Right, it's not the language per se that has kept Pascal out of Web apps, or mobile development, or even whole areas of programming. Case in point: GIS. Join the "community of one" and do GIS with Pascal (https://macpgmr.github.io/MacXPlatform/PascalDynLibs_3.html) or join the thousands of Python developers who have been doing GIS for years (http://plugins.qgis.org/plugins)?

Pascal itself is quite adaptable. For example, it even fits into the world of Xcode and Objective C pretty well (https://macpgmr.github.io/MacXPlatform/WebAppOverview_3.html#EmbeddedBrowser). It's just that nobody embraces it in these new areas.

I find Object Pascal to be surprisingly modern. But, you are right: there is a lot of power in numbers.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: jacmoe on February 12, 2017, 06:51:23 pm
Tuples as return values would be really nice to have.
But that's not really a limitation of the language per se..
I see that Free Pascal is constantly being improved - it is evolving - so perhaps it will be implemented some day.

I am more interested in more underlying issues - Akira has a list of "annoying issues that other languages simply does not have" - that makes me curious!
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Akira1364 on February 12, 2017, 06:57:04 pm
.. as much as I enjoy coding in Object Pascal, it DOES have a variety of annoying limitations that simply aren't present in other languages.) What does all this mean? In my opinion, it means FPC and Lazarus have far more "on their plate" than most people think: without them, Object Pascal would almost certainly drift completely into the "legacy" category.

I have enough experience with programming languages to know that nothing is perfect.
But I am curious - what are those annoying limitations?

I was actually mostly referring to Delphi specifically when I said that, as part of the overall point I was trying to make that FPC/Lazarus are the future of Object Pascal and Delphi isn't. For example, I can't count the number of times I've been at work and really wanted to use a string-based case statement, only to remember that only FPC supports that.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: jacmoe on February 12, 2017, 07:03:12 pm
That's great to hear!

It is also my impression that Object Pascal, as implemented by FPC/Lazarus, has moved beyond whatever Delphi (and other Pascal implementations) has to offer.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Phil on February 12, 2017, 07:09:38 pm
I am aware that desktop applications is not exactly 'what everyone is doing' these days.
However, if you want to do that, what options are there?

Well, leaving aside that it's 2017 and not 2007, one way to approach this question is to lay out the app requirements and work toward a tool, rather than start with a tool and work toward the app.

For example, is this hobby work? If so, then pick anything that's fun to use. If that's Lazarus, fine. No consequence whatsoever if you make the wrong choice.

Commercial work? For example, consumer-facing app. Well, you'd probably want to submit it to Apple's App Store and Microsoft's store, so for me that would mean using Xcode on the Apple side and Visual Studio on the Windows side, the idea being that you don't want to face _any_ limitations on the platform side and you don't want to risk a rejection at submission time. Write the app twice? Not a happy thought, but maybe put the non-UI code into a dynamic library so you can use it unchanged in both apps. I don't know anything about MS's store requirements, but Apple permits dynamic libs (.dylib) as part of a submitted app bundle. (And remember, now you're not too far away from iOS.)

Business-to-business work? Does the company expect source code too? Will they be extending it? Do they have code of their own they want to add? Etc. Again, let the app requirements drive the choice of tool.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: jacmoe on February 12, 2017, 07:23:01 pm
I agree.

I am not really talking about larger shops for whom shipping apps on the Apple app store and the MS store is going to be a viable option.
And who has the funds to cover licenses, subscription fees, whatever.

Smaller shops, however.
And let's not forget about tool building. There is a lot of tools being developed and used in-house.
I think Lazarus offers a compelling alternative to .NET, Python (with GUI).

Whatever makes you productive!

I am well aware that I probably ain't going to be using Lazarus/FPC on the day job.

But that is on a tangent, because this topic is really about Object Pascal as a language (as implemented by Lazarus/Free Pascal).


Edit:
The same reasoning could be made about other 'fringe' languages / technologies, like Racket, Lisp, OCaml - this is the reason why good old C++ is still going strong.. despite the fact that it really isn't suitable for desktop GUI applications.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Phil on February 12, 2017, 07:27:04 pm
And who has the funds to cover licenses, subscription fees, whatever.

Sorry, not following you here. Explain a bit?
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: jacmoe on February 12, 2017, 07:30:33 pm
Windows is not free. Visual Studio is not free if you want to create apps for Windows Phone.
I know next to nothing about Apple, but don't you need to be in their developer program?
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Phil on February 12, 2017, 07:34:32 pm
Windows is not free. Visual Studio is not free if you want to create apps for Windows Phone.
I know next to nothing about Apple, but don't you need to be in their developer program?

So you're going to develop and test and submit for Windows... but without Windows? Huh?

You were talking about desktop, not phone. Huh?

Xcode is free. $99 / year to submit apps for any of Apple's 4 platforms (macOS, iOS, watchOS, tvOS).


Title: Re: Annoying issues in Object Pascal - what are those?
Post by: jacmoe on February 12, 2017, 07:37:41 pm
I got the answer that I wanted.
Thanks.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Lupp on February 13, 2017, 06:45:05 pm
It's not about an issue but about a kind of desire. In the time when I programmed a few things next to really useful software of the time (short episodes from1965 through 1968 mainly using ALGOL 60) there was rarely a program not heavily relying on static arrays declared locally - to procedures, functions or to the then existing "blocks" which were something like procedure bodys without an interface and working with global variables - and dimensioned based on numbers calculated from variables or passed via parameters.
Up to this day I did not understand for what reason these locally static arrays are no longer supported. I cannot see a relevant problem with the implementation - and what could be done in the 1960es on self-made (by university institutes) computers using compilers written by students should be feasible also in 2017. Procedures can allocate and dispose memory. Why shouldn't they also be able to use the memory mapping needed for the access to array elements? It isn't really difficult to simulate this memory mapping for a dynamic array. But why should this be necessary? Why not also create a way to pass dimensioned arrays to procedures? It should just require to keep and pass a few metadata whether explicit or implicit. Much simpler than so many things nowadays supported by languages and implemented in compilers!
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: ASerge on February 13, 2017, 07:05:15 pm
It's not about an issue but about a kind of desire...
FPC supports static arrays when the size is known at compile time, and dynamic arrays when the dimension is determined at run time.
It's also supported generic arrays parameters, which take any of these types as a parameter.
What do you want?
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Thaddy on February 13, 2017, 08:16:28 pm
@Lupp
Local static arrays are supported and allocated on the stack. For huge arrays you may set the stack size to a higher value.
Local dynamic arrays are always allocated on the heap. To protect the stack, because the size is not known at compile time and the max stack size is fixed after compilation.

Btw: this is the case with any language that supports dynamic arrays. Algol 60 doesn't support locally allocated dynamic arrays...

Maybe you mean a locally allocated pointer to a dynamic array  on the heap (Algol 60 doesn't support that either...)

You are talking rubbish.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Lupp on February 13, 2017, 11:35:54 pm
Quote from: Thaddy
Algol 60 doesn't support locally allocated dynamic arrays...
This is not correct. I do not know if there still exists a machine capable of running a true ALGOL60 compiler of old times. I replace "does" with "did" therefore. One of the two computers I actually used with ALGOL60  was the PERM, operative since 1956 (yet without an ALGOL compiler first) and moved to the Deutsches Museum, München, in 1974. The other one was by ICT (later ICL) from the UK, put into operation in 1967  for a German scientific institution, the Gesellschaft für Strahlenforschung, Neuherberg, where I did some programming and consulting and lectured on ALGOL60 in 1968.

ALGOL itself was not exclusively designed as a programming language, but in the first place as a means to describe algorithms in detail and aiming at reproducible results also if humans made paper sheets to perform the calculations. None of the compilers I knew implemented the language to its full extent. In specific there was none which implemented the (interesting!) concept of "call by name for expressions as actual parameters" (Report1 11.1) above an experimental level.

However, arrays declared locally with index ranges calculated from variables or parameters were fully implemented by the compilers on both the machines. This feature was also part of the IFIP subset of ALGOL60 definition. (Recursive procedures were not.) See also attached odt which contains two relevant pages from the Report as read by IRIS V14. The element type ('real') was implicit.

1Report: ALGOL-Manual der ALCOR-Gruppe, Richard Baumann (Bearb.), Oldenbourg, München 1965

(ALCOR was a blend for "Algorithm Converter", the compilers.)
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: ASerge on February 14, 2017, 06:03:58 am
This is not correct...
You are right. From this (http://www.softwarepreservation.org/projects/ALGOL/book/Randell_ALGOL_60_Implementation_1964.pdf) on 2.2.1.1 (p. 78) "Dynamic array are also implemented using the stack". Is it important where the data is allocated for an array? FPC have SetLength(A, n). Moreover, n can be calculated in the same block, reassign and use with new value for new array allocation. This is not true for Algol.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: marcov on February 14, 2017, 07:08:10 am
C has alloca

But usually these things are only used in embedded programming, since it makes assumptions about the size of the stack and/or puts limits on e.g. temporary string variables.

Title: Re: Annoying issues in Object Pascal - what are those?
Post by: avra on February 14, 2017, 10:45:13 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;

I also find more readable avoiding unnecessary begin/end with a modula 2 like syntax (but this is unlikely going to ever happen in fpc):
Code: Pascal  [Select]
  1. if a = 1 then
  2.  b:= 1;
  3.  c:= 3;
  4. else
  5.  b:= 2;
  6. end;
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Handoko on February 14, 2017, 11:03:29 am
I like the idea if-then-else without begin block, but I wonder how (Modula2) understand multilevel if:

Code: Pascal  [Select]
  1. if i = 1 then
  2.   if a = 1 then
  3.     b := 1;
  4.     c := 3;
  5. else
  6.   b := 2;
  7. end;

Where should the else belong to?
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: marcov on February 14, 2017, 11:08:45 am
Avra, while I agree in principle, I think changing, the compatibility break, the forever upgrading from sources on the web is hundred-plus times worse than the problem to begin with.

It is always said to be an one time choice only, but in practice the transition drags on nearly forever. (and even worse if you dual use with Delphi). It is one of the reasons I stopped using $mode objfpc, it is full of this kind of "innovations"
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: minesadorada on February 14, 2017, 11:21:24 am
The begin..end construction may be sometimes annoying when you are coding, but I find it a godsend when debugging months later - especially if the code is JEDI formatted.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: marcov on February 14, 2017, 12:12:21 pm
Where should the else belong to?

_each_ if has an end. Always. So because the ELSE is within the inner if's end, it is the else of the inner if.  The indentation is wrong.

Code: [Select]
   if x then
       if y then
         c:=1
         d:=1;
       else  (* y *)
         c:=2;
         d:=3;
        end;  (* y *)
    else (* x *)
      e:=4;
      d:=4;
    end; (* x *)


Some other things are also better in M2, like the end of a procedure being different from other ones. Some things are worse (case sensitivity IMHO was the wrong decision, and using the procedure name as differing factor for the end procedure block was also, specially nowadays when deeply nested procedure hierarchies are rarer)

I would now do

Code: [Select]
procedure xx;
begin
   if then
    x:=1;
  else
   y:=1;
   end;
end proc;

and always either procedure or function irrespective on the returnvalue.

But again, I think that all this only causes more trouble than it solves to change that now (either as new language, which are really hard to get of the ground (http://phoronix.com/scan.php?page=news_item&px=GNOME-Vala-Bassi)), and even worse in an existing dialect (language with codebase)
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Lupp on February 14, 2017, 12:49:32 pm
(Concerning the fibre "arrays locally declared with calculated dimenions but fix then till disposal" again.)
"Locally Static Arrays", LSA henceforth

What I talked of was arrays that were declared (the ALGOL terms again) typically for the scope of the body of a subroutine and could be dimensioned for as many index positions as wanted with index ranges calculated from variables or parameters (constants, too, of course). These arrays were disposed on exit from the sub. To change that, ALGOL60 included the 'own' concept which I did not find implemented with one of the compilers I used.

To use arrays of this kind, very often 2D, I nearly inevitably had a reason when programming during my youth. The many examples from the (old) literature about ALGOL may sufficiently explain this. (I disliked FORTRAN but I had to read programs written in this language. It also supported the feature. I don't know anything about recent versions of FORTRAN.)

@ASerge: Both the machines of old times I mentioned were "single task" (below of which ran the management, of course). They distinguished LOW memory: faster and easily addressable in a specific way (somehow like a cache) ... and HIGH memory ("big" up to a few thousand numbers in the binary formats of the time). The PERM also had an experimental "Magnettrommelspeicher". Single task isn't in need of distinguishing between stack (allocated on load program) and heap (allocatable on request).

@ASerge ("What do you want?"), @Thaddy ("Maybe you mean..."): Despite my poor English I am confident to have expressed with sufficient precision what I mean and what I want. As I did not use Lazarus/FPC much for many years I may be wrong with some respects, however. Please tell me.

1. Array parameters in FPC are always "dynamic" in a specicific sense and thus basically 1D. If I want to use them for 2D (e.g.) tasks I have to implement a memory mapping myself. This is less efficient than a generic memory mapping - and it's annoying. Am I wrong insofar?
2. In addition the memory management must be prepared to change the array's size. Creating a "secondary stack" might avoid this. Wrong?
3. The relevant difference between a LSA of two dimensions or higher and a dynamic array as seen from the compiler's view is not its allocation (stack or heap) but the means to organize the access to the single elements. For LSA we need the meta information about it's type (The dimensions! The element type is known in Pascal anyway.) When passing a LSA as a parameter this meta information must also be passed. Otherwise the array is not usable with its intended way of indexing. Wrong?
4. As compared with many constructs added to programming languages and to computer capabilities since the times of ALGOL and PERM, the implementation of LSA should be an easy hack. Wrong?
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Lupp on February 14, 2017, 01:17:34 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?
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: ASerge 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;
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: bytebites 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
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Lupp 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?
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: jacmoe 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.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: ASerge 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.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: ASerge 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.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: lazjump 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.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Phil 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
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: ASerge 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
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Thaddy 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.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: jacmoe 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..
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: bee 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.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Thaddy 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).
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Zoran 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.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: Thaddy 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.
Title: Re: Annoying issues in Object Pascal - what are those?
Post by: marcov on February 17, 2017, 12:03:41 pm

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.  

They are not similar. One is dynamic array, one is open array. The mistake is not that they are incompatible, but that the same syntax is used for two different things.

Title: Re: Annoying issues in Object Pascal - what are those?
Post by: marcov on February 17, 2017, 12:06:52 pm
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 think this is the best point in the try..except..finally discussion.

In Delphi, you need finally so often to free resources, so if you are going to invent a new language dialect, you might want to tackle that (e.g. with RAII, GC), rather than micromanaging typing. (which is nearly never a good idea)