* * *

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

Thaddy

  • Hero Member
  • *****
  • Posts: 4633
Re: The future of Free Pascal
« Reply #375 on: July 14, 2017, 08:57:36 pm »
Quote
You are ignorant
nowi will get some.gin/tonic and wait for thaddy's reaponse and i will enjoy your slow convultions   :D
In this case ... I'd stick to the gin-tonic  8-)
"Logically, no number of positive outcomes at the level of experimental testing can confirm a scientific theory, but a single counterexample is logically decisive."

AlexK

  • Jr. Member
  • **
  • Posts: 55
Re: The future of Free Pascal
« Reply #376 on: July 14, 2017, 09:20:22 pm »
Parenthesis don't make a function call a function call. Pascal is a typed language, the fact that identifier is a function makes it a function call.

That's why in Delphi you have to do @SomeFuncName to get a pointer.

Code: Pascal  [Select]
  1. type
  2.   TFuncNoArgsString = function(): String; // is it a pointer type?
  3.  
  4. function Hello: String;
  5. begin
  6.   Result := 'Hello There';
  7. end;
  8.  
  9. procedure Take(f: TFuncNoArgsString);
  10. begin
  11.   WriteLn( f() );
  12. end;
  13.  
  14. Take(@Hello); // that is a pointer type! but you have to use operator @ on a name
  15.  

When you think about a function name, it can't be anything else than a POINTER to its code.
But if you want to treat a function's name as a pointer, you have to distinguish between a name as a pointer and a function invocation.
So parenthesis for invocation must be mandatory. In this case you wouldn't need to use @ on a function's name.
« Last Edit: July 14, 2017, 09:30:23 pm by AlexK »

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5815
Re: The future of Free Pascal
« Reply #377 on: July 14, 2017, 09:33:58 pm »
That's why in Delphi you have to do @SomeFuncName to get a pointer.

Your code compiles fine without the @. @ and @@ are only used to disambiguate cases (mostly when a function returns  a function type )

Quote
When you think about a function name, it can't be anything else than a POINTER to its code.

Functions are semantically not pointers, even if  they translate to a pointer on asm level. Talking about function pointers is a Cism.

Actually, @ can (in the case of nested functions and functions of objects), even have an implementation of two pointers.

Quote
But if you want to treat a function's name as a pointer, you have to distinguish between a name as a pointer and a function invocation.
So parenthesis for invocation must be mandatory. In this case you wouldn't need to use @ on a function's name.

I think you are confused with a different language. There is no @ requirement in Delphi (or TP for that matter)

AlexK

  • Jr. Member
  • **
  • Posts: 55
Re: The future of Free Pascal
« Reply #378 on: July 14, 2017, 10:03:03 pm »
That's why in Delphi you have to do @SomeFuncName to get a pointer.
Your code compiles fine without the @.

No, compiler calls the function "Hello" and passes to "Take" a string returned by "Hello".
Code: Pascal  [Select]
  1. Take(Hello);

Error: Incompatible type for arg no. 1: Got "AnsiString", expected "<procedure variable type of function:AnsiString;Register>"

It expects "procedure variable type", but in syntax you have to use @, which means a pointer.
A function's name is treated as an invocation, not as a pointer.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5815
Re: The future of Free Pascal
« Reply #379 on: July 14, 2017, 10:38:41 pm »
That's why in Delphi you have to do @SomeFuncName to get a pointer.
Your code compiles fine without the @.

No, compiler calls the function "Hello" and passes to "Take" a string returned by "Hello".
Code: Pascal  [Select]
  1. Take(Hello);

Error: Incompatible type for arg no. 1: Got "AnsiString", expected "<procedure variable type of function:AnsiString;Register>"

That sounds like a /fpc/ error. Delphi (XE4) compiles it fine, WITHOUT @.


chain_reaction

  • New member
  • *
  • Posts: 19
Re: The future of Free Pascal
« Reply #380 on: July 15, 2017, 03:11:47 am »
I've worked a little on implementing syntax highlighting for an FPC mode in Emacs.
It turns out that Delphi's idiosyncrasies spoiled the language in some parts.
For example, calling a proc/func without parenthesis: http://s5.postimg.org/oszmu72vb/fpc_mode_emacs.jpg

OBJFPC style guidelines fix that, but are not enforced.
It seams to me that such a language may replace C in open source.

Alex, FPC-mode in Emacs? This is really a good one. Have you already upload the FPC-mode package to the melpa repo? I would really like to try it  :).

Thaddy

  • Hero Member
  • *****
  • Posts: 4633
Re: The future of Free Pascal
« Reply #381 on: July 15, 2017, 09:57:37 am »
Code: Pascal  [Select]
  1. type
  2.   TFuncNoArgsString = function(): String; // is it a pointer type?
  3.  
  4. function Hello: String;
  5. begin
  6.   Result := 'Hello There';
  7. end;
  8.  
  9. procedure Take(f: TFuncNoArgsString);
  10. begin
  11.   WriteLn( f() );
  12. end;
  13.  

Silly idiots, this compiles in all Delphi's and in FPC:
Code: Pascal  [Select]
  1. program untitled;
  2. {$ifdef fpc}{$mode delphi}{$apptype console}{$endif}
  3. type
  4.   TFuncNoArgsString = function(): String; // is it a pointer type?
  5.  
  6. function Hello: String;
  7. begin
  8.   Result := 'Hello There';
  9. end;
  10.  
  11. procedure Take(f: TFuncNoArgsString);
  12. begin
  13.   WriteLn( f() );
  14. end;
  15. begin
  16. Take(Hello); // that is a pointer type! but you have to use operator @ on a name (NO silly!)
  17. end.

Versus this does not compile in Delphi at all but will compile in objfpc mode:
Code: Pascal  [Select]
  1. program untitled;
  2. {$mode objfpc}{$ifdef mswindows}{$apptype console}{$endif}
  3. type
  4.   TFuncNoArgsString = function(): String; // is it a pointer type?
  5.  
  6. function Hello: String;
  7. begin
  8.   Result := 'Hello There';
  9. end;
  10.  
  11. procedure Take(f: TFuncNoArgsString);
  12. begin
  13.   WriteLn( f() );
  14. end;
  15. begin
  16. Take(@Hello); // that is a pointer type! but you have to use operator @ on a name (YES, that is required by objfpc mode)
  17. end.
  18.  


Mixing up modes. No bug in fpc.
« Last Edit: July 15, 2017, 10:00:30 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."

AlexK

  • Jr. Member
  • **
  • Posts: 55
Re: The future of Free Pascal
« Reply #382 on: July 15, 2017, 04:47:51 pm »
Alex, FPC-mode in Emacs? This is really a good one. Have you already upload the FPC-mode package to the melpa repo? I would really like to try it  :).

Just an experiment.
I still have to make auto-indentation, better Imenu support with Helm. Some main shortcuts for compilation.
All other modes in the past where done for Delphi, then abandoned for understandable reasons.
Not sure yet if I'll be implementing it.
« Last Edit: July 15, 2017, 06:30:37 pm by AlexK »

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5815
Re: The future of Free Pascal
« Reply #383 on: July 18, 2017, 10:34:52 am »
I tried to split the Bounded WITH subthread, but it is my first split, so be patient

SymbolicFrank

  • Sr. Member
  • ****
  • Posts: 299
Re: The future of Free Pascal
« Reply #384 on: July 20, 2017, 10:03:03 pm »
Well, in favor of Delphi (and because marcov really doesn't like it when I say bad things about it), next to all the bugs, warts and uncertainty, it does have FireMonkey. Which is exactly what every decent IDE nowadays should have.

Because that's the main reason why projects get cancelled in my experience, and that is / would be the main reason to use Lazarus.

If doing a project today, it needs to be multi-platform. And either a web-app, or C# or Java if that's not possible, because that's what the people graduating know. And that's who companies want to hire: young, cheap and like virgin clay.

Then again, if you make a list what IDE scores best on that Time To Market scale, Lazarus is in the top three. And it would solidly be on the first place if it had something like FireMonkey.

Now the only development platform that is truly multi-platform is Unity3D...


So, when I have explained all the pros and cons, management tends to like Unity best, except that it is called a "game engine". If not for that, I wouldn't be able to use Lazarus at all.

The saving grace for Lazarus is (in my experience) that you can turn out tools and Linux servers (mostly http, the MicroService idea) at a fast clip. That they are easy to distribute (no installing). And that they keep on working.


If we want Lazarus to become the major platform, we need our own multi-platform, OpenGL GUI.
« Last Edit: July 27, 2017, 12:54:56 pm by SymbolicFrank »

AlexK

  • Jr. Member
  • **
  • Posts: 55
Re: The future of Free Pascal
« Reply #385 on: July 27, 2017, 06:38:59 am »
If we want Lazarus to become the major platform, we need our own multi-platform, OpenGL GUI.

OpenGL ES 2 is an ubiquitous standard these days. https://kivy.org in Python uses it for user interfaces, multi touch, different input devices.
But some prefer native look and feel.

mse

  • Full Member
  • ***
  • Posts: 233
Re: The future of Free Pascal
« Reply #386 on: July 27, 2017, 08:08:01 am »
If we want Lazarus to become the major platform, we need our own multi-platform, OpenGL GUI.
Free Pascal has at least two owner drawn cross platform toolkits since more than 10 years: fpGUI and MSEgui. For MSEgui there is also MSEide, a handy and very productive design environment.


Blestan

  • Sr. Member
  • ****
  • Posts: 456
Re: The future of Free Pascal
« Reply #387 on: July 27, 2017, 08:19:00 am »
great then!  so mse gui has his own  coherent look and feel across android and ios? what are the minimal verions supported? if the both platform are 10+ years then atleast ios 6 and android kitkat?  pls send some screenshots on different screen sizes :)
Speak postscript or die!
Translate to pdf and live!

mse

  • Full Member
  • ***
  • Posts: 233
Re: The future of Free Pascal
« Reply #388 on: July 27, 2017, 08:28:35 am »
Personally I think on phones one should use the tools of the platform.
Porting fpGUI and MSEgui to phone-OS could be done if there is enough interest and maybe sponsors, the software architecture is designed for such a task.

Blestan

  • Sr. Member
  • ****
  • Posts: 456
Re: The future of Free Pascal
« Reply #389 on: July 27, 2017, 08:33:55 am »
so for example unity is only cross platform on desktops and uses another tools on android and ios?
Speak postscript or die!
Translate to pdf and live!

 

Recent

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