[fpc-pascal] Re: Support for C++ library format?

[Juha Manninen]

Thanks for your answer.

Now I admit the C++ library support was a bad idea. Even the different C++ 
compilers are not binary compatible. It is a big mess.

I liked the design of .NET, yes. However, I think compiling CIL to machine 
code is not the same thing as with real compiled languages. I don't know the 
details though.
At least my experience is that any program run under .NET or Mono starts 
slowly and hogs memory. In that respect it is comparable to Java.

So, my "scientific" classification of all object oriented multi-platform 
programming languages is here:

  ----------------           ----------------
 | Compiled:      |         | Interpreted:   |
 | C++            |  <--->  | All others     |
 | Object Pascal  |         | (a long list)  |
  ----------------           ----------------

Note that C is not mentioned because it is not OO.
The "All others" list could be still divided into Dynamic and Non-Dynamic but 
it is irrelevant here. Dynamic language features have still more overhead but 
when used cleverly they can make the program simpler and smaller.

The main strength of Object Pascal (and FPC) is that it is compiled. I see it 
as the only justification for the whole language. Otherwise we could just dump 
it and start using C# or Java or something which have cleaner syntax without 
carrying historical (pointer) syntax.

This language is not as popular as some others. How to improve it to meet 
today's demands?
The syntax could still be improved. I understood generics are coming to FPC, 
too, which is good.

Then, backwards compatibility could be broken. Yes. The old pointer syntax 
could be forbidden by default and allowed only in some "Error prone mode" or 
"Ugly code mode".
That would allow more aggressive optimizations in the compiler, too.
And yes, I have made big complicated programs with Delphi without using 
pointer syntax, so it is possible.

Other features could be borrowed shamelessly from other designs and languages. 
That's how the open source stuff happens anyway. It is not a bad thing.

The main strengths would remain:
Compiled fast and small binary, easy to deploy.
Fast compilation.


Juha Manninen


------------

> This is the goal of the Microsoft CLI (Common Language
> Infrastructure). The library format in this case is an intermediate
> one rather than a native one (CIL, Common Intermediate Language), but
> it can be statically compiled into machine code afterwards. It also
> supports both dynamic languages (there are e.g. IronPython and
> IronRuby) and non-dynamic languages (C#, F#, C++, C, ...). It's also
> supposed to have explicit support for mixing different object models
> in a single program.
> 
> Borland/CodeGear tried to take advantage of this with Delphi .NET, but
> apparently weren't very successful with it (although that's probably
> in the eye of the beholder). I never looked into the details, so I
> don't know why.
> 
> Having a common API without an intermediate format would however be
> virtually impossible to design, especially if you want to guarantee
> backwards binary compatibility for all of the languages that you want
> to interoperate. You really need some kind of intermediate level with
> meta-information (higher level than the pure machine code) which
> describes what is a class, a method, inheritance trees, etc if you
> want to enable transparently mixing code coming from different
> languages/compilers.
> 
> Well, you could try to write something like http://sourceware.org/libffi/
>   geared at different object models rather than at simply different
> ABIs, but I think it would be more fragile and it would offer less
> integration possibilities.
> 
> 
> Jonas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20091006/0afd376f/attachment.html>