[fpc-devel] Announcement: Free Pascal CompilerDelphi XEPortProject (type override idea)

[Skybuck Flying]

----- Original Message ----- 
From: "Hans-Peter Diettrich" <DrDiettrich1 at aol.com>
To: "FPC developers' list" <fpc-devel at lists.freepascal.org>
Sent: Thursday, 14 April, 2011 15:12 PM
Subject: Re: [fpc-devel] Announcement: Free Pascal CompilerDelphi 
XEPortProject


> Skybuck Flying schrieb:
>
>> Anyway if somebody could take a look at all of this and make some sense 
>> of it that would be great/nice, saves me some time and could clear some 
>> confusion (?) ;)
>
> Before looking at your code, I'd know the role that your project plays at 
> all. Is it only about making the FPC code compilable by Delphi, as the 
> first stage in the FPC bootstrap?

Yes.

Plan is as follows:

1. Compile free pascal compiler sources without free pascal rtl and instead 
use a "bootstrapping rtl".

The bootstrapping rtl is a mix of Delphi's own RTL (which is implicitly 
present and doesn't require any additional files/sources) and any RTL 
inconsistencies/extensions placed in my own "mini extension RTL" which is 
currently simply called unit_skybuck_types.pas LOL.

2. Once free pascal compiler is compiled towards an executable by Delphi it 
should then be possible to compile Free Pascal's own RTL with Free Pascal.

An alternative idea could be to start working on compiling the Free Pascal 
RTL with Delphi as well.

This would be possible by renaming all conflicting files, so at least no 
unit name conflicts like system.pas.

However if this would work is doubtfull because of potential "type 
conflicts" but perhaps Delphi allows types to be "overriden" or "redeclared" 
or "overloaded".

That in itself could actually be an interesting language feature/extension. 
(I shall post this idea later on on usenet as well)

Such a language feature would be nice to solve unit type conflicts, for 
example some unit defined TSomething and now another unit wants to define 
TSomething as well, however because the unit scope is in affect this is not 
an issue...

For other units it's also not an issue because they could simply write: 
unit1.TSomething and unit2.TSomething however that does require putting the 
unit name in front of it.

Perhaps a type override could specify which TSomething to prevail for 
example:

uses
    unit1;
    unit2;

type
    TSomething = unit2.TSomething; override;

Then in the rest of the unit TSomething from unit2 would be used without 
having to write Unit2.TSomething all the time.

It could also have written the following:
    TSomething = SomethingElse; override;

This will override the type from unit1 and unit2 so that unit3 can use that 
namespace/type for itself.

3. Once the RTL is compiled use the original RTL sources and/or RTL binaries 
to recompile the free pascal compiler so it's fully self-hosting and 
self-compiling.

(Etc)

(I am a little bit exciting about this potential new language feature so I 
am cutting this short, but this is basically the plan ;) =D).


> In this case it would be easier to use an older Delphi commandline 
> compiler, from the time before the Ansi-To-Unicode move, or simply an

I don't do command line compiling, I hate it, working with the command line 
is freaking slow.

I don't think ansi will be much of a problem, it's kinda cool to have a 
unicode compiler...

Perhaps it will be the first in the world, or perhaps not... who knows (for 
real lol) ?

> legacy FPC. You also could try to make the FPC sources compile by gcc -

The whole idea is to not require FPC to do any development, all development 
done on/in Delphi IDE and then final stage compile with FPC for 
non-supported-delphi-platforms.

GNU Compilers are slow, furthermore they are not object-oriented as far as I 
know/last time I checked so they totally out-of-the-question.

The least I would want is record with properties support, not yet sure if 
Free Pascal has that record-language-feature but if not then Tobject could 
be used for that.

And thus oo needed.

Furthermore class support is nice.

> but I'd delay any such attempts to the time, when there doesn't exist any 
> immediately applicable compiler any more.

Let me know if there is a "pascal to c" converter or "object pascal to c 
converter" or "object/pascal to cuda/opencl/glsl/cg converter" because as 
far as I know it don't exist or it's really shitty (delphi to c converter).

In other words the time for me has already come to attempt it ;) =D and thus 
this project came to be ! ;) =D and ofcourse it will be most handy for the 
future.

And now I go post that language/type override idea ;)

Bye,
  Skybuck.