* * *

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

Phil

  • Hero Member
  • *****
  • Posts: 1956
Re: Annoying issues in Object Pascal - what are those?
« Reply #15 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).



jacmoe

  • Full Member
  • ***
  • Posts: 241
    • Jacmoe's Cyber SoapBox
Re: Annoying issues in Object Pascal - what are those?
« Reply #16 on: February 12, 2017, 07:37:41 pm »
I got the answer that I wanted.
Thanks.
more signal - less noise

Lupp

  • New member
  • *
  • Posts: 30
Re: Annoying issues in Object Pascal - what are those?
« Reply #17 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!
« Last Edit: February 13, 2017, 06:49:13 pm by Lupp »

ASerge

  • Full Member
  • ***
  • Posts: 235
Re: Annoying issues in Object Pascal - what are those?
« Reply #18 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?

Thaddy

  • Hero Member
  • *****
  • Posts: 3049
Re: Annoying issues in Object Pascal - what are those?
« Reply #19 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.
« Last Edit: February 13, 2017, 08:24:15 pm by Thaddy »

Lupp

  • New member
  • *
  • Posts: 30
Re: Annoying issues in Object Pascal - what are those?
« Reply #20 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.)
« Last Edit: February 13, 2017, 11:47:13 pm by Lupp »

ASerge

  • Full Member
  • ***
  • Posts: 235
Re: Annoying issues in Object Pascal - what are those?
« Reply #21 on: February 14, 2017, 06:03:58 am »
This is not correct...
You are right. From this 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.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5190
Re: Annoying issues in Object Pascal - what are those?
« Reply #22 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.


avra

  • Hero Member
  • *****
  • Posts: 841
    • Additional info
Re: Annoying issues in Object Pascal - what are those?
« Reply #23 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;
ct2laz - Easily convert components and projects between Lazarus and CodeTyphon

Handoko

  • Hero Member
  • *****
  • Posts: 829
  • My goal: build my own game engine using Lazarus
Re: Annoying issues in Object Pascal - what are those?
« Reply #24 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?

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5190
Re: Annoying issues in Object Pascal - what are those?
« Reply #25 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"

minesadorada

  • Hero Member
  • *****
  • Posts: 529
  • Retired
Re: Annoying issues in Object Pascal - what are those?
« Reply #26 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.
GPL Apps: Health MonitorRetro Ski Run
OnlinePackageManager Components: LazAutoUpdate, LongTimer, PoweredBy, ScrollText, PlaySound, CryptINI

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5190
Re: Annoying issues in Object Pascal - what are those?
« Reply #27 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), and even worse in an existing dialect (language with codebase)
« Last Edit: February 14, 2017, 03:39:55 pm by marcov »

Lupp

  • New member
  • *
  • Posts: 30
Re: Annoying issues in Object Pascal - what are those?
« Reply #28 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?
« Last Edit: February 14, 2017, 01:22:49 pm by Lupp »

Lupp

  • New member
  • *
  • Posts: 30
Re: Annoying issues in Object Pascal - what are those?
« Reply #29 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?

 

Recent

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