[fpc-pascal]FPC vs. GPC (was:FPC 1.0.6 and open arrays)

[Marco van de Voort]

> On Mon, Jan 27, 2003 at 10:42:37PM +0100, Marco van de Voort wrote:
> > > Will there also be sopport for conformant Arrays as they are defined 
> > > in standard Pascal (ISO-7185)?
> > 
> > Not that I'm aware of (unless you plan to implement it ? ).
> 
> No, I can't do it.
> 
> The point is just, that I'm still disappointed that FPC isn't
> compatible to any of the official Pascal standards and that it's not
> even trying to become compatible.

True. There is pretty much no point in that, since the Pascal standards are
effectively dead. (Borland 99.9% marketshare) Maybe we would do it if we had
significantly more manpower, but we don't, and there isn't much hope on
improvement.
 
> I'm very much drawn back and forth between FreePascal and GNU Pascal.
> Both have their advantages, but also their disadvantages. FreePascal
> has more commands, but GNU Pascal knows a much more elaborated syntax.

Then I'd advise you to look more into the Delphi modes of FPC.

> FreePascal supports just one dialect,

FPC supports both BP as Delphi syntax.

> GNU Pascal knows different dialects including the standards. 

But it doesn't implement them very well. To avoid this with FPC also, it was
decided to not fragment until the manpower is there.

> FreePascal has lots of systemspecific extentions, but programs written with
> them aren't portable, even not between the different variants of
> FreePascal itself.  GNU Pascal tries to leave systemspecific things away,
> that means that programs are nearly always portable, but also that things
> are missing. 

This is nonsense. Either one uses systemspecific extensions or not. This works
for both FPC and GPC.

> GNU Pascal (the compiler itself) is very portable, while FreePascal is
> mainly targeted to PCs and porting to other platforms seems to take a lot
> of time.

True, that is a fundamental problem. But note that this is also a reason for GPC being
so unpredictable. Again it is FPC's philosophy of doing one thing right, before
moving on.

Luckily, we are slowly moving away from that, and FPC runs decently on m68k already, and Sparc
and PPC are in advanced stages of development.

> On the other hand GNU Pascal is hard to install, especially on non-Unix
> systems. 

And more importantly, harder to work on. The overal build process + system + patching is 
a lot more complex.

> GNU Pascal is the better Pascal, when you look at the source code
> of your programming,

This is a matter of taste. I don't agree.

> What I really want would be a mixture of both!

Then there is only one option. Work on either of them. Both projects have manpower shortage,
the difference is how they handle that.
 
> At the moment I try to use only what both have in common. But
> unfortunately that's not much. I have to avoid commands because of
> GPC and I have to use a simpler syntax because of FPC.

I wouldn't do that anyway. GPC hardly knows any Delphi dialect features, and those are
the strong point of FPC (most of the development in language after 1997 deals with Delphi
extensions).
 
> That's why I try to suggest that FPC should become more standard
> compatible, to be able to write more portable code. 

That wouldn't help either, since there is no true standard for the object orientated extensions anyway,
only a draft that is interpreted differently by various people/companies.
 
> Okay, I see that it's difficult to implement.
> But what about things that look similar? 
> 
> For example initialized variables...
> 
> FPC has this syntax:
> const i: integer = 0;

And 

var i : integer = 0;

in Delphi mode.

> But it's so very unlogical to use a "const" as variable. :-(
> (GPC accepts this syntax, but gives a warning)

> Extended Pascal (ISO-10206) declares this syntax:
> var i: integer value 0;
> Much nicer, isn't it?

No. Why add a keyword "value" when an "=" is more logical? Bloat!
 
> That at least looks very similar so I hope, at least that will be
> simpler for you to implement...
 
> BTW. you might wonder why Extended Pascal uses "value" and not the
> equal-sign. That is because it also defines initialized types:
> type myint = integer value 0;

Ugly feature. I'm against it. A type doesn't have a value. I don't like
pre-initalisation anyway, don't use it much in any variant.

This kind of baroque syntax is what makes some languages so tiresome.

> Or what about String definitions:
> FPC: 
> var s: string[255];
> ISO-10206:
> var s: string(255);  {btw. not limited to 255}
> Would it be so difficult to accept parantheses instead of brackets?
> GPC accepts both.

Stringtypes (short, long and schemata based) are all fundamentally
different. This is not just syntax, but a lot more.

Delphi's (ansi-) string type doesn't have a size, and is fully automatic.