* * *

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

Thaddy

  • Hero Member
  • *****
  • Posts: 4023
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: 52
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: 5533
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: 52
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: 5533
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: 4023
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: 52
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: 5533
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

  • Full Member
  • ***
  • Posts: 247
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 Unity...


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.

 

Recent

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