The future of Free Pascal

[Thaddy]

You are ignorant

nowi will get some.gin/tonic and wait for thaddy's reaponse and i will enjoy your slow convultions   

In this case ... I'd stick to the gin-tonic 

[AlexK]

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.

[marcov]

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 )

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.

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]

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]

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]

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]

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.

[AlexK]

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.

[marcov]

I tried to split the Bounded WITH subthread, but it is my first split, so be patient

[SymbolicFrank]

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.

[AlexK]

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]

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]

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

[mse]

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]

so for example unity is only cross platform on desktops and uses another tools on android and ios?