Recent

Author Topic: The future of Free Pascal  (Read 228501 times)

Paul_

  • Full Member
  • ***
  • Posts: 143
Re: The future of Free Pascal
« Reply #345 on: June 22, 2017, 09:11:33 pm »
Thank you, both looks much simpler than what I'm using.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: The future of Free Pascal
« Reply #346 on: June 22, 2017, 09:12:56 pm »
Whenever i change the Textfile I had to Change the number of the Array too, and I Sooooooooo didn't liked that !!!!!

The problem is the whole "copy and paste in source" idea driven too far, a different solution would be to use resources.

I had the same problem with shader source code (not being recompiled after run), changed to resources and am very happy with it.

Thaddy

  • Hero Member
  • *****
  • Posts: 14203
  • Probably until I exterminate Putin.
Re: The future of Free Pascal
« Reply #347 on: June 22, 2017, 09:18:03 pm »
Or the second Code: you only have to write a vararray to TmyPoint-conversion and overload the assignment operator then 
Funny that your code fragment ended up the same  8-)
Anyway, since we now have implicit array constructors, going through a vararray scenario is not necessary in trunk. The code is also way more efficient.
But, trunk only!
Specialize a type, not a var.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: The future of Free Pascal
« Reply #348 on: June 22, 2017, 09:20:54 pm »
Or the second Code: you only have to write a vararray to TmyPoint-conversion and overload the assignment operator then 
Funny that your code fragment ended up the same  8-)
Anyway, since we now have implicit array constructors, going through a vararray scenario is not necessary in trunk. The code is also way more efficient.
But, trunk only!

And array only. Though maybe you can work around it with some conversion operator. (e.g. from array of two singles to tpoint etc)

Thaddy

  • Hero Member
  • *****
  • Posts: 14203
  • Probably until I exterminate Putin.
Re: The future of Free Pascal
« Reply #349 on: June 22, 2017, 09:25:11 pm »
@Marco
Default property. Hasn't arrived yet... Will be... :D ;) O:-)
Specialize a type, not a var.

m.abudrais

  • Jr. Member
  • **
  • Posts: 52
Re: The future of Free Pascal
« Reply #350 on: June 22, 2017, 09:36:02 pm »
i liked the string helper  :D, i didn't know about it before.
thank you.

jc99

  • Hero Member
  • *****
  • Posts: 553
    • My private Site
Re: The future of Free Pascal
« Reply #351 on: June 23, 2017, 12:21:51 am »
Or the second Code: you only have to write a vararray to TmyPoint-conversion and overload the assignment operator then 

And array only. Though maybe you can work around it with some conversion operator. (e.g. from array of two singles to tpoint etc)
Sorry, I meant conversion operator of cause. from array to TMyPoint
« Last Edit: June 23, 2017, 12:26:47 am by jc99 »
OS: Win XP x64, Win 7, Win 7 x64, Win 10, Win 10 x64, Suse Linux 13.2
Laz: 1.4 - 1.8.4, 2.0
https://github.com/joecare99/public
'~|    /''
,_|oe \_,are
If you want to do something for the environment: Twitter: #reduceCO2 or
https://www.betterplace.me/klimawandel-stoppen-co-ueber-preis-reduzieren

jc99

  • Hero Member
  • *****
  • Posts: 553
    • My private Site
Re: The future of Free Pascal
« Reply #352 on: June 23, 2017, 12:25:23 am »
Whenever i change the Textfile I had to Change the number of the Array too, and I Sooooooooo didn't liked that !!!!!

The problem is the whole "copy and paste in source" idea driven too far, a different solution would be to use resources.

I had the same problem with shader source code (not being recompiled after run), changed to resources and am very happy with it.
I also had resource in mind, but in this special case it had to be a hard-coded Array of Strings coming from an include-file.
OS: Win XP x64, Win 7, Win 7 x64, Win 10, Win 10 x64, Suse Linux 13.2
Laz: 1.4 - 1.8.4, 2.0
https://github.com/joecare99/public
'~|    /''
,_|oe \_,are
If you want to do something for the environment: Twitter: #reduceCO2 or
https://www.betterplace.me/klimawandel-stoppen-co-ueber-preis-reduzieren

segfault

  • Full Member
  • ***
  • Posts: 107
Re: The future of Free Pascal
« Reply #353 on: June 29, 2017, 06:45:40 pm »
I find it strange that there seems to be a widespread perception among many programmers that Pascal is a "dead" language. A typical comment is "What!, people still use Pascal?"

Delphi/Object Pascal is currently at position 13 on the Tiobe index, ahead of Go, Visual Basic, and objective C. That's hardly "dead".

I have a theory about this; it maybe because Pascal was once great (throughout the 80's and up to the mid 90's or so when I first learned it at Uni), but has since given way to C++, Java, and scripting languages like Python, so it's now relatively obscure. It's "dead" in comparison to what it once was, but still more popular than more niche languages such as Lisp or Fortran, which never really had a heyday as general purpose languages. Even though Lisp and Fortran are even older than Pascal, you don't seem to hear the comment "What!, people still use Lisp?".

RAW

  • Hero Member
  • *****
  • Posts: 868
Re: The future of Free Pascal
« Reply #354 on: June 29, 2017, 08:34:07 pm »
Quote
I find it strange that there seems to be a widespread perception among many programmers that Pascal is a "dead" language. A typical comment is "What!, people still use Pascal?"
Me too...
On the other hand the "BIG MONEY" is telling people what is right and what is not or what to do and what not... so it's easy to take a look where the MONEY goes and who controls the MONEY and who creates the opinion for the vast majority of people.

Pascal was great and is still great...  :P
(Yeah, I couldn't deny myself...  :D)
Windows 7 Pro (x64 Sp1) & Windows XP Pro (x86 Sp3).

Thaddy

  • Hero Member
  • *****
  • Posts: 14203
  • Probably until I exterminate Putin.
Re: The future of Free Pascal
« Reply #355 on: June 29, 2017, 11:08:44 pm »
http://blog.therealoracleatdelphi.com/2016/04/google-chrome-and-delphi.html

This is not Delphi specific. Same goes for FPC or Lazarus. The speed with which you can do serious programming in a compiled language still exceeds most other languages. At least for me. Even if I spend a lot of time doing C and C++ work and a (huge) bit of Java and Python, I usually prototype in Object Pascal.
« Last Edit: June 29, 2017, 11:13:00 pm by Thaddy »
Specialize a type, not a var.

segfault

  • Full Member
  • ***
  • Posts: 107
Re: The future of Free Pascal
« Reply #356 on: June 30, 2017, 11:23:24 am »
Pascal was great and is still great...  :P

Agreed! If the masses don't realize that, it's their problem.  :D

taazz

  • Hero Member
  • *****
  • Posts: 5368
Re: The future of Free Pascal
« Reply #357 on: July 10, 2017, 06:45:10 am »
What's wrong with
Code: Pascal  [Select][+][-]
  1. f:=open("file.txt")
?

Sorry, but you didn't bother to understand my point. It wasn't only about some techniques of opening a file.
I tend to think the task would require writing another compiler without backward compatibility.

For example, an interface that can declare only the name of a procedural type, without actual types:
Code: Pascal  [Select][+][-]
  1. IContextManager = Interface
  2.   deferred __enter__: FuncOrProcType;
  3.   procedure __exit__;
  4.   procedure __rescue__(ex: Exception);
  5. end;
  6.  

^^Here, the type of __enter__ would be determined by a compiler at an implementation site, in a class. Only the name is enforced by the interface, this opens an ability to create "object protocols".
__enter__ can be implemented as a function or procedure, with any arguments and return types.

Such interface leads to rich semantics that use those required methods in a compiler:
Code: Pascal  [Select][+][-]
  1. Using TheCustomer, SomeOtherObject to name1, OtherHelperContext to name2 do
  2.     begin
  3.     // here needed environment(context) is ensured by these "context managers" above
  4.     name1.someMethod;
  5.     name2.interestingMethod;
  6.     end;
  7.  

A compiler would insert calls to __enter__ methods for each object in "TheCustomer, SomeOtherObject to name1, OtherHelperContext to name2", where name1 and name2 would require that __enter__ is implemented as a function rather than a procedure.
On exit for a using statement compiler would insert calls to __exit__ methods.

More organized memory management.
Quote
So, that construction somehow partly replaces RAII of C++, gives some "design by contract" abilities.
Also it can be used to program transactions with rollbacks.
Or using draw procedures in some graphic contexts, or action procedures in a game.
Sorry but you didn't bother to understand mine, the only thing that is not supported currently is to the variable names, otherwise here is a short demonstration how to get exactly the same behavior that you demonstrated today no need for a new compiler.
Code: Pascal  [Select][+][-]
  1.   { TEvsFile }
  2.  
  3.   TEvsFile = object
  4.   private
  5.     FFileStream : TFileStream;
  6.   public
  7.     Constructor init;
  8.     Destructor done;override;
  9.     procedure Open(const aFileName:TFilename);
  10.     Function Read(var aBuffer; aCount: Longint): Longint; override;
  11.     Function Write(const aBuffer; aCount: Longint): Longint; override;
  12.     Function Seek(const aOffset: Int64; aOrigin: TSeekOrigin): Int64; override;
  13.   end;
  14.  
  15.   Constructor TEvsFile.init;
  16.   begin
  17.     FFileStream := nil;
  18.   end;
  19.  
  20.   Destructor TEvsFile.done;
  21.   begin
  22.     FFileStream.Free;
  23.   end;
  24.  
  25.   procedure TEvsFile.Open(const aFileName: TFilename);
  26.   var
  27.     vMode :Word;
  28.   begin
  29.     if Assigned(FFileStream) then FFileStream.Free;
  30.     if FileExists(aFileName) then vMode := fmOpenReadWrite or fmShareExclusive else vMode:=fmCreate;
  31.     FFileStream := TFileStream.Create(aFileName, vMode);
  32.   end;
  33.  
  34.   Function TEvsFile.Read(var aBuffer; aCount: Longint): Longint;
  35.   begin
  36.     FFileStream.Read(aBuffer, aCount);
  37.   end;
  38.  
  39.   Function TEvsFile.Write(const aBuffer; aCount: Longint): Longint;
  40.   begin
  41.     FFileStream.Write(aBuffer, aCount);
  42.   end;
  43.  
  44.   Function TEvsFile.Seek(const aOffset: Int64; aOrigin: TSeekOrigin): Int64;
  45.   begin
  46.     FFileStream.Seek(aOffset, aOrigin);
  47.   end;
  48.  
  49.   function Open(const aFilename:TFilename):TEvsFile;
  50.   begin
  51.      Result.Open(aFilename);
  52.   end;
  53.  
  54.   procedure domytheng;
  55.   begin
  56.     with open("MyDataFile.Dat") do
  57.       read(Data, size);
  58.   end;
  59.  
you have your init right there and when it fells off scope you have the destructor called automatically and it is as clean as your example
Keep in mind that I have not worked with object for a long long time so my facts might be upside down but the idea is there and I'm pretty sure can be made to work.
I do like the variable ability. In any case I'm all up for a new compiler but I'm warning you I'm not giving up my compatibility for any reason.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

mse

  • Sr. Member
  • ****
  • Posts: 286
Re: The future of Free Pascal
« Reply #358 on: July 10, 2017, 07:01:36 am »
MSElang has [ini] and [fini] attributes for object methods:
https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_objects
Maybe there will be [incref] and [decref] too in order to implement universal reference counting (not yet decided).


taazz

  • Hero Member
  • *****
  • Posts: 5368
Re: The future of Free Pascal
« Reply #359 on: July 10, 2017, 08:31:44 am »
you have your init right there and when it fells off scope you have the destructor called automatically and it is as clean as your example
Keep in mind that I have not worked with object for a long long time so my facts might be upside down but the idea is there and I'm pretty sure can be made to work.
I do like the variable ability. In any case I'm all up for a new compiler but I'm warning you I'm not giving up my compatibility for any reason.

The programmer is responsible for calling the constructor and the destructor explicitly when using objects.

But it does not relate to what I meant. I took simple semantics in Python as an example and demonstrated how it could possibly be implemented in Object Pascal or some static typed lang.
OK. I don't see it then. Keep in mind that the main force that keeps pascal alive this days is compatibility if I'm to forgo compatibility and rewrite my libraries I'll target a more popular toolchain like c++ I have no reason to stay cornered.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

 

TinyPortal © 2005-2018