[fpc-devel] RE $MODE Delphi

Jonas Maebe jonas.maebe at elis.ugent.be
Tue Nov 29 16:36:19 CET 2011


On 29 Nov 2011, at 16:14, Thaddy wrote:

> On 29-11-2011 15:46, Jonas Maebe wrote:
>> Possibly, but it would also require RTL changes (the FPC system  
>> unit contains many types, constants, variables and functions that  
>> do not exist in Delphi -- and for programmers the difference  
>> between the language and the system unit is often not very clear)  
>> and possibly also blocking certain packages (which can't be  
>> compiled with Delphi). It would be a lot of work even if you would  
>> limit it to only the compiler (the use of which would be  
>> questionable), and additionally only few people are interested in  
>> such functionality.
>>
>> For backwards compatibility reasons, such changes would have to go  
>> into a separate mode switch. Patches for that could be accepted,  
>> but again, without also changing the RTL and packages I'm not sure  
>> how much it would help you in reaching your goal.
>>
> I was merely indicating syntactical elements, not the use of  
> specific units, variables and constants, not even the RTL as such.

The point is that even if you disable all those syntactical elements,  
then your code may still not be compilable by Delphi in any way (which  
I believe was your goal).

> So, much like $mode objfpc extends the syntax let $mode delphi  
> restrict the syntax.
> There is a case to make that f.e. the C style operators and the  
> macro facilities belong to $mode objfpc anyway.
> Or am I wrong here?

They are not part of either {$mode objfpc} or {$mode delphi}. You have  
to explicitly enable them in addition to the syntax mode, via e.g. the  
{$coperators on} resp. {$macro on} directives.

> Or is there value in it?

Some people prefer the general Delphi syntax (e.g. because they are  
used to it), but still don't mind writing code that only runs under  
FPC for whatever reason. I'm mainly talking about differences related  
to procvar syntax, how the name of a function is interpreted in its  
body (as a recursive call or as an alias for the function result) etc.


Jonas



More information about the fpc-devel mailing list