Parser

[Hans-Peter Diettrich]

In examples/parser/no_cpu you find a new project, that can be used as a
Pascal parser, or as a compiler template for a new CPU.

This project is kind of a plug-in for the FPC compiler, i.e. it uses the
original FPC parser (fpcsrc/compiler/p*). More projects will follow,
making the FPC parser usable inside other applications.

As the name "no_cpu" indicates, this project does not implement a
specific CPU, because code generation is not required for an universal
parser. The project name "ppcFromM68K" indicates that it is based on the
M68K compiler, and it (currently) requires a $DEFINE M86K, because all
acceptable CPUs are hard-coded in the FPC compiler code. Effectively
every CPU resides in its own subdirectory, that is added to the path
when the compiler is built, and that contains several units of
predefined names and contents; see the no_cpu/readme.txt for these details.

Until now these problems make the parser unusable in other projects:

1) The compiler requires that all used units can be found, and are
translated as well.

2) All units implicitly use System. Until now I could not make this unit
found, so the test project was named system.pas, to bypass the search
for the system unit in the compiler. A compiler switch (-s?) may have
the same result.

3) The compiler builds an parse tree for every procedure, but I found no
way yet to make this tree accessible. There should exist a
method/procedure in the CPU specific code, that is called to create the
binary code for a procedure, but I could not yet locate it.

4) It's not yet known how the rest of a unit (declarations...) is
represented internally. Some tokens (comments...) simply are skipped,
what can be cured by modifications to the scanner.

5) Conditional compilation only processes one branch, and macros are
expanded. While macro expansion may be suppressed, somehow, the
compilation of multiple conditional branches really doesn't make sense.
We'll have to find an way to submit the exactly defined symbols to the
compiler, so that the intended branches become part of the parse tree.
For the use of the parser in an syntax-highlighter a different approach
must be choosen, that allows to classify all tokens for the syntax
highlighter itself, and that also allows to identify sections,
procedures and blocks for folding and the determination of e.g.
begin-end pairs.


In detail the last item [5] suggests an more flexible parser, that can
do with the scanned tokens whatever is appropriate in the scope of a
specific application. The general solution is a separation of the
syntactical and semantical procedures in the parser. For fastest
processing the semantical code can be made selectable just as for the
CPU, by placing this code into a dedicated directory. I hope that this
solution is acceptable to the FPC maintainers, and I'm willing to
refactor all the parser units accordingly.

Another solution would use a Semantics class, with the benefit that
different trees can be built from the source code in one or more runs;
one such class could provide the classified tokens to an syntax
highlighter, another one could provide the block structure of the unit.
This solution can be derived from the procedural solution, when the
semantical procedures delegate all work to a supplied Semantics object,
or to multiple objects in parallel - nothing that would affect the
remaining compiler code at all.

One big advantage of the separation into syntactical and semantical
parts is the chance for adding further languages to the compiler, as
selectable front-ends, which use the already existing classes and
procedures for code generation. Adding e.g. Oberon syntax should not
require many changes to the existing code, while other languages (C/C++)
would require to add and handle new node types during optimization and
code generation. But such extensions are beyond the scope of the current
parser examples.


Any comments and suggestions are welcome. If somebody wants to
contribute to this or related projects, I'll add it or apply according
patches to the examples/parser tree. Any assistance is welcome, in
finding out the places where the existing compiler code can be modified,
in order to overcome the beforementioned problems. FPDoc documentation
of the compiler also will be welcome...

DoDi



--

[Mattias Gaertner]

On Wed, 30 Jun 2010 12:04:38 +0200

Post by Hans-Peter Diettrich
In examples/parser/no_cpu you find a new project, that can be used as a
Pascal parser, or as a compiler template for a new CPU.

Nice work.

Why is this in the lazarus examples? Why not put it to the fpc sources?

Mattias

--

[dmitry boyarintsev]

On Wed, Jun 30, 2010 at 2:44 PM, Mattias Gaertner

Post by Mattias Gaertner
Why is this in the lazarus examples? Why not put it to the fpc sources?

+1, as FPC sources branch or even trunk.

thanks,
dmitry

--

[Hans-Peter Diettrich]

Post by Mattias Gaertner
Why is this in the lazarus examples? Why not put it to the fpc sources?

Because I can commit only to the Lazarus examples :-(

Now I have to adopt the sample to the FPC trunk version, which is
somewhat incompatible with 2.4.

DoDi


--

[Mattias Gaertner]

On Wed, 30 Jun 2010 21:53:47 +0200

Post by Hans-Peter Diettrich

Post by Mattias Gaertner
Why is this in the lazarus examples? Why not put it to the fpc sources?

Because I can commit only to the Lazarus examples :-(

Sorry, but that sounds somewhat childish.
You could have asked the fpc team or put it into one of the many free
repositories. If you put something into lazarus examples then lazarus
users expect a reason for downloading 650KB extra.
If the above is the only reason, then you should remove it.

Post by Hans-Peter Diettrich
Now I have to adopt the sample to the FPC trunk version, which is
somewhat incompatible with 2.4.

Mattias

--

[Reimar Grabowski]

On Thu, 1 Jul 2010 00:19:34 +0200

Post by Mattias Gaertner
You could have asked the fpc team or put it into one of the many free
repositories. If you put something into lazarus examples then lazarus
users expect a reason for downloading 650KB extra.
If the above is the only reason, then you should remove it.

+1

And the whole thread has nothing to do with lazarus at all. Is it possible to continue the discussion somewhere else, please?

R.

[Adem]

Post by Reimar Grabowski
On Thu, 1 Jul 2010 00:19:34 +0200

You could have asked the fpc team or put it into one of the many free repositories. If you put something into lazarus examples then lazarus users expect a reason for downloading 650KB extra. If the above is the only reason, then you should remove it.

+1
And the whole thread has nothing to do with lazarus at all.

Actually, it does --quite a bit.

It all started off with how we could come up with a code formatter (plus
refactoring tools etc.) that uses a parser codebase that did not have to
be written/maintained separately.

It turned out that, in its current shape, FPC wasn't suitable for such
use due to its monolithic nature, so we discussed --briefly-- what could
be done about that (i.e. ways to refactor FPC code in such a way that
downstream projects could re-use its modules).

Now, the discussion has moved on to whether --while doing all that-- it
would be a good idea to provide infrastructure for other expansion (such
as other lang back-ends).

Even though these can come across as nothing to do with Lazarus, they
actually are --if you consider the fact that here in Lazarus list people
are focused on writing applications, i.e. not compiler develeopment,
anything that can expand/help with that purpose belongs to this list's
very domain.

Post by Reimar Grabowski
Is it possible to continue the discussion somewhere else, please?

Personally, I'd think it'd be mistake to do that.

I would, OTOH, very much appreciate if you could spare some time and
contribute towards future direction.

Cheers,

Adem


--

[Reimar Grabowski]

On Thu, 01 Jul 2010 20:12:52 +0300

Post by Adem
Even though these can come across as nothing to do with Lazarus, they
actually are --if you consider the fact that here in Lazarus list people
are focused on writing applications, i.e. not compiler develeopment,
anything that can expand/help with that purpose belongs to this list's
very domain.

Loading Image...

Post by Adem

Post by Reimar Grabowski
Is it possible to continue the discussion somewhere else, please?

Personally, I'd think it'd be mistake to do that.

The FPC lists are the correct place to discuss FPC topics. Enough of them there, user/devel/other choose one.

Post by Adem
I would, OTOH, very much appreciate if you could spare some time and
contribute towards future direction.

No problem. Keep the compiler/parser as it is (this means fast and working). Enhance the parser fpdoc uses => win
Enhace h2pas for better automatic header translation => double win

R.

[Adem]

Post by Reimar Grabowski
On Thu, 01 Jul 2010 20:12:52 +0300

Post by Adem
Even though these can come across as nothing to do with Lazarus, they
actually are --if you consider the fact that here in Lazarus list people
are focused on writing applications, i.e. not compiler develeopment,
anything that can expand/help with that purpose belongs to this list's
very domain.

http://techbuddha.files.wordpress.com/2009/12/double-facepalm.jpg

I am sorry, I didn't think that paragraph would be that unparseable
--can I have a copy of the error log. :)

Post by Reimar Grabowski

Post by Adem

Post by Reimar Grabowski
Is it possible to continue the discussion somewhere else, please?

Personally, I'd think it'd be mistake to do that.

The FPC lists are the correct place to discuss FPC topics. Enough of them there, user/devel/other choose one.

Thank you for displaying just the the kind of community spirit I like
whereby each and every member thinks the whole belongs to him/her as
his/her personal lawn.

By that token, you --just as anybody else-- can tell me off your
personal lawn; can't you?

Of course, you can. After all, you own this place. ;)

Post by Reimar Grabowski

Post by Adem
I would, OTOH, very much appreciate if you could spare some time and
contribute towards future direction.

No problem. Keep the compiler/parser as it is (this means fast and working).

Order <> Contribution.

Post by Reimar Grabowski
Enhance the parser fpdoc uses => win
Enhace h2pas for better automatic header translation => double win

And, do those all over every time some little thing changes --for ever
and ever.

I see.

How about this as a more sensible approach:

Refactor the FPC code so that its relevant modules are usable in the
above applications (and more).

Further: While doing that, refactor it so that ordinary mortals too
could comprehend it better to off-load some of the immense burdens on
the shoulders of the Core team.

Add to that: In the process, rearrange a few things so that future
expansion --such as multilanguage compilation etc.-- becomes a tangible
possibility.

Such an awful idea, isn't it?

What I find interesting and yet dismaying is this: You choose not to
have any input (like "how about doing XXX also, while you're at it?)
other than "get off my lawn!"..

Cheers,

Adem


--

[Reimar Grabowski]

On Fri, 02 Jul 2010 00:55:27 +0300
Adem <***@letterboxes.org> wrote:

First of all I apologize for hurting your feelings.
Second, please calm down. This is only a technical mailing list and in my opinion the wrong one for this discussion.

Post by Adem
Further: While doing that, refactor it so that ordinary mortals too
could comprehend it better to off-load some of the immense burdens on
the shoulders of the Core team.

Did you actually read Michaels and Florians mails?
Does not look like.

Post by Adem
Add to that: In the process, rearrange a few things so that future
expansion --such as multilanguage compilation etc.-- becomes a tangible
possibility.

See above.

Post by Adem
Such an awful idea, isn't it?

Yes, it is an awful idea.

Kind regards
R.

[Adem]

Post by Reimar Grabowski
On Fri, 02 Jul 2010 00:55:27 +0300
First of all I apologize for hurting your feelings.

No problem. Except for mild disappointment, no harm done.

Post by Reimar Grabowski
Second, please calm down. This is only a technical mailing list and in my opinion the wrong one for this discussion.

Thank you for kindly consoling me. I am feeling a lot better now. :)

Post by Reimar Grabowski

Post by Adem
Further: While doing that, refactor it so that ordinary mortals too
could comprehend it better to off-load some of the immense burdens on
the shoulders of the Core team.

Did you actually read Michaels and Florians mails?
Does not look like.

I did.

As far as I can tell, they both think it will be a tough one (due to
complex and intertwined code) to pull off --especially from POV of speed.

Other than that, I haven't seen anyone putting forward why it would be
wrong.

Have you?

Have I missed something?

Post by Reimar Grabowski

Post by Adem
Such an awful idea, isn't it?

Yes, it is an awful idea.

In what way do you think it may harm you or your beloved ones? :)

Would it help you feel safer if we all stopped talking about these awful
ideas? ;)

Cheers,

Adem


--

[Reimar Grabowski]

On Fri, 02 Jul 2010 03:22:34 +0300

Post by Adem
As far as I can tell, they both think it will be a tough one (due to
complex and intertwined code) to pull off --especially from POV of speed.

Exactly and it sounds like they think the time and manpower is better spent on other things.
much work + little gain = bad idea
My point was that I wanted to read this thread on an FPC list. Other than that I am not really interested as long as the compiler stays fast (one of the main reasons to use it).

Post by Adem
Would it help you feel safer if we all stopped talking about these awful
ideas? ;)

No, but less smileys would help alot.

This is my last mail in this thread. Enough spam here (my own mails included).

I apologize in advance but I just could not resist. Yes, I know, I am an evil person.
Loading Image...

R.

Post by Adem
--
_______________________________________________
Lazarus mailing list
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Marco van de Voort]

Post by Adem

Post by Reimar Grabowski

You could have asked the fpc team or put it into one of the many free repositories. If you put something into lazarus examples then lazarus users expect a reason for downloading 650KB extra. If the above is the only reason, then you should remove it.

+1
And the whole thread has nothing to do with lazarus at all.

Actually, it does --quite a bit.
It all started off with how we could come up with a code formatter (plus
refactoring tools etc.) that uses a parser codebase that did not have to
be written/maintained separately.
It turned out that, in its current shape, FPC wasn't suitable for such
use due to its monolithic nature, so we discussed --briefly-- what could
be done about that (i.e. ways to refactor FPC code in such a way that
downstream projects could re-use its modules).

Besides that, many people (including several that worked on the FPC parser)
have warned you that such a beast, while more elegant on paper, might
actually be harder to maintain than two parsers.

You chose to ignore that.


--

[Adem]

Besides that, many people (including several that worked on the FPC parser) have warned you that such a beast, while more elegant on paper, might actually be harder to maintain than two parsers.
You chose to ignore that.

No.

I did not ignore that.

In fact, I did make a very bold note of it.

But, it's not as if this is a 'suicide mission' --no one is going to
commit suicide or intend to harm anyone in the process.

Far from it.

If indeed it turns out to be an impossible task, it's not as if we have
staked our lives on it, we can abort the 'mission' <g> anytime we run
out of steam.

And, about having to maintain 2 parsers.

Well.. the whole point is to *not* maintain any more than *one* parser
--and, that includes current n parsers (I am not sure what the value of
'n' is).

That is the target.

If we get there?

Great. Something good will have come out of it.

If not?

Well..

We'll have at least tried.

So, could I now ask for some constructive --instead of discouraging--
criticism.

Cheers,

Adem

[Mattias Gaertner]

On Fri, 02 Jul 2010 07:49:25 +0300

Post by Adem
[...]
Well.. the whole point is to *not* maintain any more than *one* parser
--and, that includes current n parsers (I am not sure what the value of
'n' is).
That is the target.

Means?
I still don't understand what do you really want to achieve.
There are currently several different pascal parsers with different
abilities for different purposes. For example the fpc one for
compiling, synedit for highlighting, codetools has several for
directives, declarations, indentations, fcl has one basic and extendable
parser and so forth.
Each one has abilities that the others do not have.

What do you want to use the fpc parser for?

Post by Adem
[...]
So, could I now ask for some constructive --instead of discouraging--
criticism.

The fear of slowing down the compiler and its development
without seeing the gain is discouraging.


Mattias


--

[Florian Klämpfl]

Post by Hans-Peter Diettrich
3) The compiler builds an parse tree for every procedure, but I found no
way yet to make this tree accessible.

It is no parse tree but some intermediate represensation.

Post by Hans-Peter Diettrich
There should exist a
method/procedure in the CPU specific code, that is called to create the
binary code for a procedure, but I could not yet locate it.

psub.pas: tcgprocinfo.generate_code, it is generic.

Post by Hans-Peter Diettrich
4) It's not yet known how the rest of a unit (declarations...) is
represented internally.

It is processed directly.

Post by Hans-Peter Diettrich
In detail the last item [5] suggests an more flexible parser, that can
do with the scanned tokens whatever is appropriate in the scope of a
specific application. The general solution is a separation of the
syntactical and semantical procedures in the parser. For fastest
processing the semantical code can be made selectable just as for the
CPU, by placing this code into a dedicated directory. I hope that this
solution is acceptable to the FPC maintainers, and I'm willing to
refactor all the parser units accordingly.

I see two problems:
- speed
- reduced readability of the parser code because the code for handling
something will be spread over different locations resulting also in
reduced maintainability: just look at the code generator code, to
support different architectures fpc the code generator is split at
several levels making it very hard to get an overview on it and even
more get into it.

Post by Hans-Peter Diettrich
One big advantage of the separation into syntactical and semantical
parts is the chance for adding further languages to the compiler,

Is this really desired? The advantages of fpc are that it is written in
its native language but its code generator is not sophisticated enough
so it's imo not worth to add another front end.

--

[Hans-Peter Diettrich]

Post by Florian Klämpfl

Post by Hans-Peter Diettrich
3) The compiler builds an parse tree for every procedure, but I found no
way yet to make this tree accessible.

It is no parse tree but some intermediate represensation.

Yes, it's an AST, but I didn't want to put too much into the
advertisement ;-)

Post by Florian Klämpfl

Post by Hans-Peter Diettrich
There should exist a
method/procedure in the CPU specific code, that is called to create the
binary code for a procedure, but I could not yet locate it.

psub.pas: tcgprocinfo.generate_code, it is generic.

I couldn't find out how the code generator is involved. Most methods are
non-virtual...

Post by Florian Klämpfl

Post by Hans-Peter Diettrich
4) It's not yet known how the rest of a unit (declarations...) is
represented internally.

It is processed directly.

This means that the parser must be patched.

Post by Florian Klämpfl

Post by Hans-Peter Diettrich
In detail the last item [5] suggests an more flexible parser, that can
do with the scanned tokens whatever is appropriate in the scope of a
specific application. The general solution is a separation of the
syntactical and semantical procedures in the parser. For fastest
processing the semantical code can be made selectable just as for the
CPU, by placing this code into a dedicated directory. I hope that this
solution is acceptable to the FPC maintainers, and I'm willing to
refactor all the parser units accordingly.

- speed

Not really. The semantic actions are so complex, that another call (to
them) should not matter.

Post by Florian Klämpfl
- reduced readability of the parser code because the code for handling
something will be spread over different locations resulting also in
reduced maintainability: just look at the code generator code, to
support different architectures fpc the code generator is split at
several levels making it very hard to get an overview on it and even
more get into it.

Yes and no. A good separation will help to clarify much.

Post by Florian Klämpfl

Post by Hans-Peter Diettrich
One big advantage of the separation into syntactical and semantical
parts is the chance for adding further languages to the compiler,

Is this really desired? The advantages of fpc are that it is written in
its native language but its code generator is not sophisticated enough
so it's imo not worth to add another front end.

We'll see ;-)

DoDi


--

[Florian Klämpfl]

Post by Hans-Peter Diettrich

Post by Florian Klämpfl

Post by Hans-Peter Diettrich
There should exist a
method/procedure in the CPU specific code, that is called to create the
binary code for a procedure, but I could not yet locate it.

psub.pas: tcgprocinfo.generate_code, it is generic.

I couldn't find out how the code generator is involved. Most methods are
non-virtual...

In the typical case the node tree codegenerator( ncg*.pas/n<cpu>*.pas)
calls the methods in cgcpu.pas.

Post by Hans-Peter Diettrich

Post by Florian Klämpfl
- reduced readability of the parser code because the code for handling
something will be spread over different locations resulting also in
reduced maintainability: just look at the code generator code, to
support different architectures fpc the code generator is split at
several levels making it very hard to get an overview on it and even
more get into it.

Yes and no. A good separation will help to clarify much.

See above, the whole back end stuff is separated very well but diving
into it is hell :)

--

[Hans-Peter Diettrich]

Post by Florian Klämpfl

Post by Hans-Peter Diettrich

Post by Florian Klämpfl

Post by Hans-Peter Diettrich
There should exist a
method/procedure in the CPU specific code, that is called to create the
binary code for a procedure, but I could not yet locate it.

psub.pas: tcgprocinfo.generate_code, it is generic.

I couldn't find out how the code generator is involved. Most methods are
non-virtual...

In the typical case the node tree codegenerator( ncg*.pas/n<cpu>*.pas)
calls the methods in cgcpu.pas.

Since a mere parser is not a code generator, the
tcgprocinfo.generate_code simply could become a virtual method, so that
it could be overridden to e.g. export the tree. This change were almost
not noticeable to ncg* and the other code generators, whose invocation
by the base class implementation doesn't change at all.

Post by Florian Klämpfl
See above, the whole back end stuff is separated very well but diving
into it is hell :)

The current Parser project will not affect the back-ends at all, only
the parser procedures will be split into an syntactic and an semantic
part. Once the semantic part can be exchanged, like currently a CPU can
be exchanged, the parser-only implementation can create its own tree and
other data structures, eliminating any need for special handling in the
code generators. Similarly the currently broken preprocessor could
output the preprocessed source code in its own semantic routines,
independent from all code generation. Perhaps I can make the
preprocessor work again, since its requirements (hooks, switches...) are
almost the same as those of an mere parser.


BTW, it's not a good idea to have CPU specific code in the general
compiler/parser units. E.g. PDecSub calls methods in the specialized
TxxxParaManager classes, which are not found in the base class. I'll
come back to this and other issues in a discussion in the FPC list. For
now it's sufficient to discuss the possibilities from the user VP,
that's why I started this thread in the Lazarus list.

DoDi


--

[Reimar Grabowski]

On Thu, 01 Jul 2010 00:54:21 +0200

For now it's sufficient to discuss the possibilities from the user VP,
that's why I started this thread in the Lazarus list.

Epic fail.
This is the Lazarus users list and not the FPC users list. Why not discuss it in the correct place?
Yes, some Lazarus users might be interested in this topic, but that does not change the fact that this is the wrong list to discuss this, as the thread clearly shows. Nearly no mention of Lazarus at all. And only because it is vaguely related does not mean it is the correct list.

Thx, for not listening.

A not amused
R.

[Graeme Geldenhuys]

Post by Reimar Grabowski
Yes, some Lazarus users might be interested in this topic, but that does
not change the fact that this is the wrong list to discuss this, as the
thread clearly shows. Nearly no mention of Lazarus at all.

Lazarus users use FPC! Lazarus doesn't support another compiler -
period. Some of you guys should really lighten up a bit and stop being
so anal about what is discussed in what mailing list. I already think
there is way to many mailing lists between FPC and Lazarus.
Information just gets fragmented!

Regarding you not liking this message thread... Like I told somebody
else.... learn to use your software. eg: If you are not interested in
the message thread... First don't read it! Secondly, if you are using
Mozilla Thunderbird, simply press the R key and it marks the whole
thread as READ (I'm pretty sure other email clients can do the same,
if not your loss).
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--

[Reimar Grabowski]

I love you Graeme. Ever have, ever will. Life would be so empty without you.

Kisses
R.

p.s.: Real men don't use Thunderbird

[Graeme Geldenhuys]

Post by Reimar Grabowski
I love you Graeme. Ever have, ever will. Life would be so empty without you.
Kisses
R.
p.s.: Real men don't use Thunderbird

PS: Real men (or any men for that matter) shouldn't send me emails
like the above. My wife doesn't like competition. :-)
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--

[Reimar Grabowski]

On Thu, 1 Jul 2010 23:27:43 +0200

Post by Graeme Geldenhuys
PS: Real men (or any men for that matter) shouldn't send me emails
like the above. My wife doesn't like competition. :-)

Africa is so far away, I have no fear.

Regarding the thread: No bad feelings, just different opinions.

Have a nice day
R.

[Sven Barth]

Hi!

Wouldn't it be better to also include the fpc-devel list in this
discussion (with CC)? Although (most of) the FPC-Devs might be reading
the Lazarus list as well, you might find a better and perhaps more
experienced audience there (it's nothing against the Lazarus developers,
but not everyone likes to mess around in the compiler ^^).

Regards,
Sven

--

[Hans-Peter Diettrich]

Post by Sven Barth
Wouldn't it be better to also include the fpc-devel list in this
discussion (with CC)?

Not yet. I want to collect more information about the compiler, so that
I can make well based suggestions for the next steps.

DoDi


--

[Marcos Douglas]

Hi Diettrich,
I see a complex work... very intelligent!
I have only one comment below:

On Wed, Jun 30, 2010 at 7:04 AM, Hans-Peter Diettrich

Post by Hans-Peter Diettrich
One big advantage of the separation into syntactical and semantical
parts is the chance for adding further languages to the compiler...

No sense for me.
IMHO, we chose the FPC much more by language than by the great
compiler. If we have more languages, Pascal loses your glamour!


Marcos Douglas

--

[Adem]

Post by Marcos Douglas
On Wed, Jun 30, 2010 at 7:04 AM, Hans-Peter Diettrich

One big advantage of the separation into syntactical and semantical parts is the chance for adding further languages to the compiler...

No sense for me.
IMHO, we chose the FPC much more by language than by the great compiler. If we have more languages, Pascal loses your glamour!

Why do you think Pascal would lose its glamor when (or if) FPC can
compile other languages?

I would have thought it would be just the opposite:

If you could compile, say, Modula (or C/C++) with FPC, you would have
direct access to a huge & time-tested resource of libraries etc which
you could directly incorporate into your applications, or even do
automatic source code translation (provided someone writes this
capability); all these and more could add plenty more glamor to FPC
--that is, if it needs that.

I know these things are mostly pie-in-the-sky at the moment, but I don't
understand why it would be undesirable to lay the groundwork for future
expansion.

Is this a new form of racism? ;)

[I couldn't help ending it with a troll <g>]

Cheers,

Adem


--

[Florian Klämpfl]

Post by Adem

Post by Marcos Douglas
On Wed, Jun 30, 2010 at 7:04 AM, Hans-Peter Diettrich

Post by Hans-Peter Diettrich
One big advantage of the separation into syntactical and semantical
parts is the chance for adding further languages to the compiler...

No sense for me.
IMHO, we chose the FPC much more by language than by the great
compiler. If we have more languages, Pascal loses your glamour!

Why do you think Pascal would lose its glamor when (or if) FPC can
compile other languages?

... because it increases the maintainance work on fpc. Even with one
front end only we are almost unable to keep the issue count under
control. I'am pretty sure that more front ends will be rejected without
more people working on bug fixing in fpc.

Post by Adem
If you could compile, say, Modula (or C/C++) with FPC, you would have
direct access to a huge & time-tested resource of libraries etc which
you could directly incorporate into your applications,

This can be done already using compilers supporting these languages

Post by Adem
or even do
automatic source code translation

--

[Michael Van Canneyt]

Post by Florian Klämpfl

Post by Adem

Post by Marcos Douglas
On Wed, Jun 30, 2010 at 7:04 AM, Hans-Peter Diettrich

Post by Hans-Peter Diettrich
One big advantage of the separation into syntactical and semantical
parts is the chance for adding further languages to the compiler...

No sense for me.
IMHO, we chose the FPC much more by language than by the great
compiler. If we have more languages, Pascal loses your glamour!

Why do you think Pascal would lose its glamor when (or if) FPC can
compile other languages?

... because it increases the maintainance work on fpc. Even with one
front end only we are almost unable to keep the issue count under
control. I'am pretty sure that more front ends will be rejected without
more people working on bug fixing in fpc.

Exactly. We can barely cope as it is. If we compiled C as well, we'd get
bug reports about glibc or whatever C library fails to compile. no thanks.

And, frankly, the project is called "Free Pascal" for a simple reason:
it is a *Pascal* compiler and a *Pascal* project.


Michael.

[Adem]

Post by Michael Van Canneyt
Exactly. We can barely cope as it is. If we compiled C as well, we'd
get bug reports about glibc or whatever C library fails to compile. no
thanks.
it is a *Pascal* compiler and a *Pascal* project.

The reason that I get myself on the verge of being given the tar&feather
treatment must be due to me being a non-native speaker of English :)

Otherwise I could have expressed myself better to make it obvious that I
am NOT assigning you guys new job descriptions <g>.

Far from it --who am I, anyway.

All I have been trying to say is this:

As far as I can tell, you don't reject incorporating code for compiling
for a new CPU architecture point blank, nor do you yourselves guarantee
that you will provide for every CPU out there (including life-time
support). If someone comes along and adds the necessary code, fine; if
not, well, life goes on without it.

Same here: What's wrong with considering, say, a new language back-end
(or front-end) much like a new CPU-support?

Cheers,

Adem


--

[Florian Klämpfl]

Post by Adem
Same here: What's wrong with considering, say, a new language back-end
(or front-end) much like a new CPU-support?

As Michael said, it is called "Pascal". Supporting a new CPU does not
change this. Adding a C/Oberon/Modula whatever front end simply does not
fit into this scope besides the fact that there is not the slightest
advantage in doing so.

--

[Adem]

Same here: What's wrong with considering, say, a new language back-end (or front-end) much like a new CPU-support?

As Michael said, it is called "Pascal". Supporting a new CPU does not change this. Adding a C/Oberon/Modula whatever front end simply does not fit into this scope besides the fact that there is not the slightest advantage in doing so.

I am not sure about the 'slightest advantage' aspect: I thought MS sold
the .Net thing mostly on the premise of 'write in the language you're
most comfortable yet share with others you/they find useful'; and it
seems --if it was properly licensed-- it could catch on on other
platforms too.

Having said this, please don't take me as if I am out to
undermine/undervalue your years/decades of work/experience. Nor should I
come accross as if I see an imminent crowd of people dying to take FPC
where no one dared to before --and that you're standing before the onset
of Brave New Word. No, of course, nothing of that sort.

But, I think it would be fair to say this: Rejecting even
ideas/proposals in such a fashion (maybe it's not how you mean it, but
that's how someone like me perceives it) becomes discouraging for the
more tentative.

Cheers,

Adem


--

[Florian Klaempfl]

Post by Adem

Post by Florian Klämpfl

Post by Adem
Same here: What's wrong with considering, say, a new language
back-end (or front-end) much like a new CPU-support?

As Michael said, it is called "Pascal". Supporting a new CPU does not
change this. Adding a C/Oberon/Modula whatever front end simply does
not fit into this scope besides the fact that there is not the
slightest advantage in doing so.

I am not sure about the 'slightest advantage' aspect: I thought MS sold
the .Net thing mostly on the premise of 'write in the language you're
most comfortable yet share with others you/they find useful';

Exactly, "sold". It's marketing speech. You could use any language but
only to a degree of maybe 95%. So everybody decided to use C#.


--

[Hans-Peter Diettrich]

Post by Florian Klaempfl

Post by Adem
I am not sure about the 'slightest advantage' aspect: I thought MS sold
the .Net thing mostly on the premise of 'write in the language you're
most comfortable yet share with others you/they find useful';

Exactly, "sold". It's marketing speech. You could use any language but
only to a degree of maybe 95%. So everybody decided to use C#.

Diabolic hint: why should Free Pascal users be bound to the Delphi OPL
syntax, even with "mode FPC" extensions? When the use of another
language or dialect could eliminate a couple of problems, like the never
ending discussion about the proper formatting of the source code, or the
export of any number of basically unit-specific declarations, required
by the "uses" and interface/implementation model. The occurence of
circular unit references IMO can be reduced a lot, when only the really
exported declarations can be reduced by more fine-grained syntactical
means (Oberon "*" attribute).

What were so bad when the users, coming from e.g. Delphi, will find out
that the Modula or Oberon language will fit their expectations much
better than the crappy Delphi or derived FPC syntax?

And what about an Objective-C front-end, that will perfectly match the
Sun requirements for iPad etc. applications?

DoDi


--

[Marco van de Voort]

Post by Hans-Peter Diettrich

Post by Florian Klaempfl

Post by Adem
the .Net thing mostly on the premise of 'write in the language you're
most comfortable yet share with others you/they find useful';

Exactly, "sold". It's marketing speech. You could use any language but
only to a degree of maybe 95%. So everybody decided to use C#.

Diabolic hint: why should Free Pascal users be bound to the Delphi OPL
syntax, even with "mode FPC" extensions? When the use of another
language or dialect could eliminate a couple of problems, like the never
ending discussion about the proper formatting of the source code, or the
export of any number of basically unit-specific declarations, required
by the "uses" and interface/implementation model. The occurence of
circular unit references IMO can be reduced a lot, when only the really
exported declarations can be reduced by more fine-grained syntactical
means (Oberon "*" attribute).
What were so bad when the users, coming from e.g. Delphi, will find out
that the Modula or Oberon language will fit their expectations much
better than the crappy Delphi or derived FPC syntax?

Because it will never happen. Just like the grand plans for the FPC dialect
extensions. People coming from Delphi mostly care for Delphi, not language
expermentalism.

And, I mean this in the nicest possible way, and I don't like it myself
either.

Pascal shouldn't exist anymore and should have succeeded by one of Wirths
later languages. But it hasn't happened, and it won't happen.

Being basically a M2er, I learned this hard lesson already long
ago, and it was one of the reasons why I switched to Pascal.

Post by Hans-Peter Diettrich
And what about an Objective-C front-end, that will perfectly match the
Sun requirements for iPad etc. applications?

Till Apple changes the rules again, and changes it from language to "our
tools".

--

[Alexsander Rosa]

"It's a trap!" - Admiral Ackbar

What MS really wants is that you write code in
whatever-language-you-please as long as you run it at THEIR operating
system. Forget Mono and other silly attempts to clone .NET Framework --
they are doomed to always lag behind MS implementation. That's the
opposite of interpreted Java or compiled Free Pascal, where the goal is
to "write once, run anywhere".

Post by Adem
I am not sure about the 'slightest advantage' aspect: I thought MS
sold the .Net thing mostly on the premise of 'write in the language
you're most comfortable yet share with others you/they find useful';
and it seems --if it was properly licensed-- it could catch on on
other platforms too.

[Adem]

Post by Alexsander Rosa
"It's a trap!" - Admiral Ackbar
What MS really wants is that you write code in
whatever-language-you-please as long as you run it at THEIR operating
system. Forget Mono and other silly attempts to clone .NET Framework
-- they are doomed to always lag behind MS implementation. That's the
opposite of interpreted Java or compiled Free Pascal, where the goal
is to "write once, run anywhere".

We all know MS's intentions --and they made it obvious by the way went
about licensing that stuff.
Apart from that, it --IMO-- wasn't a bad idea at all. Shame it was
doomed to failure due to licensing.

Post by Alexsander Rosa

Post by Adem
I am not sure about the 'slightest advantage' aspect: I thought MS
sold the .Net thing mostly on the premise of 'write in the language
you're most comfortable yet share with others you/they find useful';
and it seems --if it was properly licensed-- it could catch on on
other platforms too.

Cheers,

Adem


--

[Marco van de Voort]

Post by Michael Van Canneyt

Post by Florian Klämpfl
... because it increases the maintainance work on fpc. Even with one
front end only we are almost unable to keep the issue count under
control. I'am pretty sure that more front ends will be rejected without
more people working on bug fixing in fpc.

Exactly. We can barely cope as it is. If we compiled C as well, we'd get
bug reports about glibc or whatever C library fails to compile. no thanks.
it is a *Pascal* compiler and a *Pascal* project.

I'm sorry. Can't agree with that.

I'm still dreaming of a FreeWirth (though admitted, M2 is so close (both
parsing, modulesystem and language type) that one could regard it as a
dialect.

--

[Florian Klaempfl]

Post by Marco van de Voort

Post by Michael Van Canneyt

Post by Florian Klämpfl
... because it increases the maintainance work on fpc. Even with one
front end only we are almost unable to keep the issue count under
control. I'am pretty sure that more front ends will be rejected without
more people working on bug fixing in fpc.

Exactly. We can barely cope as it is. If we compiled C as well, we'd get
bug reports about glibc or whatever C library fails to compile. no thanks.
it is a *Pascal* compiler and a *Pascal* project.

I'm sorry. Can't agree with that.
I'm still dreaming of a FreeWirth (though admitted, M2 is so close (both
parsing, modulesystem and language type) that one could regard it as a
dialect.

Aren't you against a e.g. .Net backend because it requires a completely
different runtime :)? I think the same applies to M2 etc. as well?

--

[Marco van de Voort]

Post by Florian Klaempfl

Post by Marco van de Voort

Post by Michael Van Canneyt
it is a *Pascal* compiler and a *Pascal* project.

I'm sorry. Can't agree with that.
I'm still dreaming of a FreeWirth (though admitted, M2 is so close (both
parsing, modulesystem and language type) that one could regard it as a
dialect.

Aren't you against a e.g. .Net backend because it requires a completely
different runtime :)? I think the same applies to M2 etc. as well?

No, I don't think so. Since they map semantically so much pretty much the
same, you can just have a sysm2 unit for some needed M2 extensions, and use
the System unit as is. The only standard unit which already exists is
"process" iirc. (for tprocess), but I have to be careful here, having used
a not entirely compliant M2 compiler.

The compiler is a bigger problem I think, scanner (case sensitive) and
parser must be separate. But they probably can share quite some helper
routines.

Topspeed Pascal and Modula2 could use eachothers modules without headers. It
is probably easier to do this than not. A FPC specific change would be to
stuff the .DEF into a ppu etc, and not read them on import, as is tradition.

The Pascal was more ISO like though, but it had TP compat too.

But it also depends on how strict you want to be. I don't necessarily opt
for 100% conformance and thus don't have to care about e.g. only export exactly the
standarized identifiers from SYSTEM. (though in theory, that could be
handled by a preproc symbol that hides it from M2 imports)

But there is a reason why I come up with fork-for-a-while schemes. I
actually have thought a long time about how I would organize this:-)

First show something, then talk about merging. But with M2 I hoped it was
sooner because less intrusive. (but my schedule would still be like 2 year
after a decent proof of concept for FPC to asorb it. And then even longer
to release it as stable.)

p.s. I must not forget a lottery ticket this month.

--

[Hans-Peter Diettrich]

Post by Florian Klaempfl

Post by Marco van de Voort
I'm still dreaming of a FreeWirth (though admitted, M2 is so close (both
parsing, modulesystem and language type) that one could regard it as a
dialect.

Aren't you against a e.g. .Net backend because it requires a completely
different runtime :)? I think the same applies to M2 etc. as well?

IMO we could separate the language itself (syntax) from the RTL (semantics).

At least I can imagine the use of a different syntax at the procedure
body (block, statement...) level, like already implemented for assembly
language blocks. The requirement of *full* M2, Oberon or P# <g>
compatibility IMO is very low, due to the few existing
(public/commercial) projects in these languages.

We also could make FPC an playground for language designers, which could
implement their own languages in dedicated front-ends, as long as they
use the existing FPC system library, tree nodes and other data
structures, as far as these are hard-coded in the compiler, optimizer
and code generators.

In contrast the implementation of parallel RTLs may be a bad idea, we
already have enough problems with platforms and widgetsets...

DoDi


--

[Marco van de Voort]

Post by Hans-Peter Diettrich

Post by Florian Klaempfl
Aren't you against a e.g. .Net backend because it requires a completely
different runtime :)? I think the same applies to M2 etc. as well?

IMO we could separate the language itself (syntax) from the RTL (semantics).

Hmm, what do you think RTL is in FPC context ? :-)

Note that the M2 port is so small is because it can use Pascal compiled
libraries. This means that dialect extensions etc to Pascal do not
necessarily have to be implemented for M2, making it mostly a parser thing.

.NET leaves the parser but requires a codegenerator change. So far so good.

With regards to libraries I have some doubts though. Will e.g. most code in
RTL/INC work for .NET without modification? (assuming we add a OS and arch
dir for .NET)

Moreover, if compromises are made, will they set well with the future .NET
port users, and won't this turn into a debate for more "native" .NET
functionality later ? ( Think Delphi.NET here)

Post by Hans-Peter Diettrich
At least I can imagine the use of a different syntax at the procedure
body (block, statement...) level, like already implemented for assembly
language blocks. The requirement of *full* M2, Oberon or P# <g>
compatibility IMO is very low, due to the few existing
(public/commercial) projects in these languages.

It's the libraries that I fear. Now that Delphi.NET is gone, even Indy is
happy to remove all the TidBytes workarounds and allow pointers again.

For exactly the same reason, I don't think .NET and native in one project
will be a happy marriage.

Post by Hans-Peter Diettrich
We also could make FPC an playground for language designers, which could
implement their own languages in dedicated front-ends, as long as they
use the existing FPC system library, tree nodes and other data
structures, as far as these are hard-coded in the compiler, optimizer
and code generators.

If it is just a playground, fork a playground. I don't want to see FPC as it
is carved up by continuous rewrites as a playground.


--

[Hans-Peter Diettrich]

Post by Michael Van Canneyt

Post by Florian Klämpfl
... because it increases the maintainance work on fpc. Even with one
front end only we are almost unable to keep the issue count under
control. I'am pretty sure that more front ends will be rejected without
more people working on bug fixing in fpc.

Exactly. We can barely cope as it is. If we compiled C as well, we'd get
bug reports about glibc or whatever C library fails to compile.

I've already translated a couple of available C libraries into Pascal,
using ToPas. There exist only a few constructs that do not translate
into Pascal directly (bitfields...), but their addition to the compiler
(code generators) should not be a problem - in the easiest case they can
be emulated in pure OPL, not affecting the code generators at all. At
statement and procedure level most languages don't differ much, and FPC
even has the C operators already implemented. Since the ToPas C parser
is written in OPL, its adaptation should be easy. This may become my
next project, after the parser...

Post by Michael Van Canneyt
it is a *Pascal* compiler and a *Pascal* project.

Microsoft started with a couple of compilers, until they implemented a
common back-end for all "Visual" languages, and later they invented the
CLR. gcc also allows to add FEs for a certain class of languages, so why
should FPC not become another Free Portable Compiler?

I wonder how somebody can say "it's hard to do", without having even
tried ;-)

DoDi


--

[Marco van de Voort]

Post by Hans-Peter Diettrich
I've already translated a couple of available C libraries into Pascal,
using ToPas. There exist only a few constructs that do not translate
into Pascal directly (bitfields...), but their addition to the compiler
(code generators) should not be a problem - in the easiest case they can
be emulated in pure OPL, not affecting the code generators at all. At
statement and procedure level most languages don't differ much, and FPC
even has the C operators already implemented. Since the ToPas C parser
is written in OPL, its adaptation should be easy. This may become my
next project, after the parser...

Since accessing header files is repeated as possible advantage files again
and again, how much progress have you made in the opposite direction?

Automated header translation

--

[Michael Schnell]

Post by Marco van de Voort
Since accessing header files is repeated as possible advantage files again
and again,

In fact I already missed sadly a fully working preprocessor (to be
activated optionally). This does help with Pascal sources from time to
time (in fact I do like macros better than generics :) ).

I don't see why simply calling the gcc preprocessor is not a viable
option (at least with Lazarus on Linux). Supposedly for a better
integration a Pascal based workalike preprocessor might be better.

-Michael

--

[Florian Klaempfl]

Post by Michael Schnell

Post by Marco van de Voort
Since accessing header files is repeated as possible advantage files again
and again,

In fact I already missed sadly a fully working preprocessor (to be
activated optionally).

Even if FPC supported such a mess, this won't solve the fundamental
problem with C headers: they work only properly if every used header is
compiled for each source file again so the whole unit concept of object
pascal has to be thrown away. So using a fully automated always working
approach you've go back to {$I ...}-style imports. Even ignoring the
fact that the real value of a half automated translated header is that
someone spent some brain into the translation and how it can be done in
a pascal styled way.

--

[Michael Schnell]

Post by Florian Klaempfl
Even if FPC supported such a mess, this won't solve the fundamental
problem with C headers: they work only properly if every used header is
compiled for each source file again

Yep. Thats a fundamental philosophy of C. In fact there is a compiler
flag with gcc to compile all files of a project as if there were a
single source: simulated includes instead of linking.In fact there are C
compilers that don't support linking at all and just compile a source
file (with includes) directly to an executable.

Using headers is strictly optional (and of course the .h extension is
not forced), but the _convention_ is to move commonly usable "external"
"typedef" etc stuff into header files. There is no dedicated syntax for
this.

(Free )Pascal, OTOH, provides syntax for doing units with an "interface"
and provide using the "precompiled" interface definitions. Less flexible
but more structured and faster than the C way.

Post by Florian Klaempfl
so the whole unit concept of object
pascal has to be thrown away.

That its why a "per unit base" could be more suitable and easier to do.
The C units would use C header files and a GNU compatible preprocessor.
A FP-propriety interface part would be added to the C units to make them
create an FP compatible compiled unit, usable in the normal way by
Pascal units and by the linker.

Post by Florian Klaempfl
So using a fully automated always working
approach you've go back to {$I ...}-style imports. Even ignoring the
fact that the real value of a half automated translated header is that
someone spent some brain into the translation and how it can be done in
a pascal styled way.

Yep.

(Still considering that on top of enabling FP to compile C sources
enabling the IDE including the debugger is an additional challenge.)
-Michael

--

[Marco van de Voort]

Post by Michael Schnell

Post by Florian Klaempfl
Even if FPC supported such a mess, this won't solve the fundamental
problem with C headers: they work only properly if every used header is
compiled for each source file again

Yep. Thats a fundamental philosophy of C.

You make it sound like it is some deep philosophical decision, while in fact
they did this because their PDP-8 was short on memory, and they separated
the compilation stages as much as possible to maximize the program that
could be compiled.

However I haven't really seen a compilation unit that exhausts my 4GB memory
(and then I'm not even speaking about 64-bit)

Post by Michael Schnell
In fact there is a compiler flag with gcc to compile all files of a
project as if there were a single source: simulated includes instead of
linking.In fact there are C compilers that don't support linking at all
and just compile a source file (with includes) directly to an executable.

Yes, and this is why gcc and most other C compilers have a totally manual
build systems, where you have to manually specify depedancies, so the
compiler can figure out what to recompile.

It would be an enormous step back.

Post by Michael Schnell
(Free )Pascal, OTOH, provides syntax for doing units with an "interface"
and provide using the "precompiled" interface definitions. Less flexible
but more structured and faster than the C way.

FPC also provides $I which is exactly the same as #include in C.

Post by Michael Schnell

Post by Florian Klaempfl
so the whole unit concept of object
pascal has to be thrown away.

That its why a "per unit base" could be more suitable and easier to do.
The C units would use C header files and a GNU compatible preprocessor.
A FP-propriety interface part would be added to the C units to make them
create an FP compatible compiled unit, usable in the normal way by
Pascal units and by the linker.

And no other C compiler would be compatible with it, voiding the only
positive aspect of C. Useless.

Post by Michael Schnell
(Still considering that on top of enabling FP to compile C sources
enabling the IDE including the debugger is an additional challenge.)

The IDE already includes a debugger. Lazarus just chose to not go that
route. It has nothing to do with C compilers.


--

[Michael Schnell]

Post by Marco van de Voort
And no other C compiler would be compatible with it, voiding the only
positive aspect of C.

As this is a pure addition to make the code integrate with FP, only
necessary if other FP units are supposed to use this interface (the
linker can do without it) the code can be included in C-style comments (
/* ... */ ) and only be interpreted by the FP parser. No harm done.

Post by Marco van de Voort
The IDE already includes a debugger. Lazarus just chose to not go that
route. It has nothing to do with C compilers.

Exactly.
Thus, IMHO, If Lazarus does not follow, it does not make much sense to
enhance the compiler to be able to decently cope with C code.

-Michael

--

[Henry Vermaak]

Post by Marco van de Voort
Yes, and this is why gcc and most other C compilers have a totally manual
build systems, where you have to manually specify depedancies, so the
compiler can figure out what to recompile.

I just use gcc -MMD in my Makefiles, which generates the dependencies
for me.

Henry

--

[Florian Klaempfl]

Post by Henry Vermaak

Post by Marco van de Voort
Yes, and this is why gcc and most other C compilers have a totally manual
build systems, where you have to manually specify depedancies, so the
compiler can figure out what to recompile.

I just use gcc -MMD in my Makefiles, which generates the dependencies
for me.

This works for your headers if you take care of them and it already
breaks if you mess with conditional #includes (which must be covered by
a fully automated solution).

--

[Henry Vermaak]

Post by Florian Klaempfl

Post by Henry Vermaak

Post by Marco van de Voort
Yes, and this is why gcc and most other C compilers have a totally manual
build systems, where you have to manually specify depedancies, so the
compiler can figure out what to recompile.

I just use gcc -MMD in my Makefiles, which generates the dependencies
for me.

This works for your headers if you take care of them and it already
breaks if you mess with conditional #includes (which must be covered by
a fully automated solution).

Sure, Makefiles start to look horrible after a very short time, it's a
problem, and autotools scare me.

Which reminds me, how is fpmake coming along? Can fpc be built with it,
yet?

Henry

--

[Florian Klaempfl]

Post by Michael Schnell

Post by Florian Klaempfl
Even if FPC supported such a mess, this won't solve the fundamental
problem with C headers: they work only properly if every used header is
compiled for each source file again

Yep. Thats a fundamental philosophy of C. In fact there is a compiler
flag with gcc to compile all files of a project as if there were a
single source: simulated includes instead of linking.In fact there are C
compilers that don't support linking at all and just compile a source
file (with includes) directly to an executable.
Using headers is strictly optional (and of course the .h extension is
not forced), but the _convention_ is to move commonly usable "external"
"typedef" etc stuff into header files. There is no dedicated syntax for
this.
(Free )Pascal, OTOH, provides syntax for doing units with an "interface"
and provide using the "precompiled" interface definitions. Less flexible
but more structured and faster than the C way.

Post by Florian Klaempfl
so the whole unit concept of object
pascal has to be thrown away.

That its why a "per unit base" could be more suitable and easier to do.
The C units would use C header files and a GNU compatible preprocessor.
A FP-propriety interface part would be added to the C units to make them
create an FP compatible compiled unit, usable in the normal way by
Pascal units and by the linker.

... and not fully automatable, so not better than current solutions.
Even worse, it does not cover the cases which are really a problem like

#define CONFIGURE_THE_HEADER_IN_A_CERTAIN_WAY // simple example are the
UNICODE define in windows headers
#include <myheader.h>

Things like this are the really nasty corner cases which make h2pas only
semi automatic.

Show me a tool which translates C headers fully automatic in *usable*
pascal units (test case e.g. glibc and mysql), then we can continue this
discussion.

--

[Hans-Peter Diettrich]

Post by Florian Klaempfl

Post by Michael Schnell
A FP-propriety interface part would be added to the C units to make them
create an FP compatible compiled unit, usable in the normal way by
Pascal units and by the linker.

... and not fully automatable, so not better than current solutions.
Even worse, it does not cover the cases which are really a problem like
#define CONFIGURE_THE_HEADER_IN_A_CERTAIN_WAY // simple example are the
UNICODE define in windows headers
#include <myheader.h>
Things like this are the really nasty corner cases which make h2pas only
semi automatic.

This is correct, and also is the most important reason for a tighter
integration of C source code into FPC projects.

Post by Florian Klaempfl
Show me a tool which translates C headers fully automatic in *usable*
pascal units (test case e.g. glibc and mysql), then we can continue this
discussion.

Just an idea:

The compiler can create the required (ppu?) files, when compiling a C
module. That file then perfectly reflects all the settings, that
affected the code generation of that module. Only this "header" version
is important for the use of that module, not any other
(mis-configurable) header files.

Likewise the compiler can use the information in the ppu file, instead
of those found in any #include file. There may exist some technical
problems with this solution, because C enforces no correspondence
between header and implementation files, neither by name nor content,
but I think that solutions can be found on a package base.

When a package contains a couple of C files, then a common package
header/ppu file could contain the descriptions of *all* items in that
package, and a list of related header files. Then the compiler can skip
over the listed #include files, and use the precise information in the
ppu file instead. This model only requires the construction of packages
for all used C files, and a one-time compilation of these packages, for
the construction of their ppu files. The compiler or a related tool can
create an dummy Pascal library unit for every such package, for easy
(human readable) use of the C packages in Pascal code.

DoDi


--

[Florian Klämpfl]

Post by Hans-Peter Diettrich
This is correct, and also is the most important reason for a tighter
integration of C source code into FPC projects.

I cannot see how a tighter integration would solve this.

Post by Hans-Peter Diettrich
The compiler can create the required (ppu?) files, when compiling a C
module. That file then perfectly reflects all the settings, that
affected the code generation of that module. Only this "header" version
is important for the use of that module, not any other
(mis-configurable) header files.

But this solution is not universal. It simply cannot cope with all
situations which might appear in C headers so it's not better than any
other tool available currently.

--

[Adem]

Post by Florian Klämpfl

The compiler can create the required (ppu?) files, when compiling a C module. That file then perfectly reflects all the settings, that affected the code generation of that module. Only this "header" version is important for the use of that module, not any other (mis-configurable) header files.

But this solution is not universal.

Personally, I too would like solutions that cover every nook and cranny;
but, life rarely grants such luxuries.. When confronted with nothing at
all, I have been known to settle for much less than 50 percent.

If that solution is not universal, what percentile do you think it would
cover?

Post by Florian Klämpfl
It simply cannot cope with all situations which might appear in C headers so it's not better than any other tool available currently.

What other tools are there that can create (ppu?) files directly usable
with FPC?

Cheers,

Adem


--

[Hans-Peter Diettrich]

Post by Florian Klaempfl

Post by Michael Schnell
In fact I already missed sadly a fully working preprocessor (to be
activated optionally).

Even if FPC supported such a mess, this won't solve the fundamental
problem with C headers: they work only properly if every used header is
compiled for each source file again so the whole unit concept of object
pascal has to be thrown away.

This is only partly true. gcc already supports (non-standard)
extensions, like #include_next and #include_once - don't beat me for the
exact wording ;-)

Other compilers use other mechanisms (heuristics, pragmas...), in order
to reduce the number of passes over the same header files. Only the
standard-conforming guards require to scan and preprocess all #included
files on every occurence, because the terminating #endif could reside
anywhere in the file, not only at its end.

And finally, a Pascal compiler works different from a C compiler, with
regards to the interfaces of other source modules (see below)

Post by Florian Klaempfl
So using a fully automated always working
approach you've go back to {$I ...}-style imports. Even ignoring the
fact that the real value of a half automated translated header is that
someone spent some brain into the translation and how it can be done in
a pascal styled way.

The Pascal style suffers from essentially the same problems, when {$I
...} is found in the source code - I just came across the {$I
fpcdefs.inc} in the FPC compiler. The major advantage of the OPL unit
and project concept (or .NET assemblies...) is the combination of
interface and implementation in an single file, that must be parsed only
once in order to extract its exports.

This means that #/$include in a Pascal source file has a different
meaning to the compilation, because that file *must* become part of the
source. If C/C++ had an equivalent to the OPL "uses", the *compiler*
could determine whether those files have to be included literally, or
whether they could be parsed once for exported symbols and macro
definitions (precompiled headers...).

Also a Pascal compiler can compile multiple units in one go, whereas a
C/C++ compiler has no idea of related files, and must compile every
single source file independently, #including all the used header files
literally.

In so far $I and #include are fully equivalent, it's only the *usage* of
$I, that is not required for used units. The (currently) only difference
between C and FPC preprocessors is the macro definition and expansion,
that allows for much trickier constructs in an C preprocessor (macro
arguments, recursive expansion, # and ## substitution...).

DoDi


--

[Marco van de Voort]

Post by Michael Schnell

Post by Marco van de Voort
Since accessing header files is repeated as possible advantage files again
and again,

In fact I already missed sadly a fully working preprocessor (to be
activated optionally). This does help with Pascal sources from time to
time (in fact I do like macros better than generics :) ).

Preprocessor is very attractive, because it fits the "edit and change"
metaphore. Technically they are disaster though.

Post by Michael Schnell
I don't see why simply calling the gcc preprocessor is not a viable
option (at least with Lazarus on Linux). Supposedly for a better
integration a Pascal based workalike preprocessor might be better.

Ask yourself why GCC doesn't have preprocessed headers, and you'll find the
answer. YOu would need to ensure that the preprocessed state is entirely the
same before using a precompiled unit.


--

[Michael Schnell]

Post by Marco van de Voort
Ask yourself why GCC doesn't have preprocessed headers,

I supposed you mean "precompiled headers" and not "headers that are
passed through the preprocessor.

This is according to what I called the "C philosophy" in the other mail.
Even if this philosophy is simplistic and introduced by need rather than
by science, it _is_ consistent and workable.

-Michael

--

[Florian Klaempfl]

Post by Michael Schnell

Post by Marco van de Voort
Ask yourself why GCC doesn't have preprocessed headers,

I supposed you mean "precompiled headers" and not "headers that are
passed through the preprocessor.
This is according to what I called the "C philosophy" in the other mail.
Even if this philosophy is simplistic and introduced by need rather than
by science, it _is_ consistent and workable.

... which does not mean that it fits into the Pascal philosophy.

--

[Michael Schnell]

Post by Florian Klaempfl
... which does not mean that it fits into the Pascal philosophy.

Of course it does not. That exactly was my point.

-Michael

--

[Florian Klaempfl]

Post by Michael Schnell

Post by Florian Klaempfl
... which does not mean that it fits into the Pascal philosophy.

Of course it does not. That exactly was my point.

So it's pretty clear that a C front end does not change much.

--

[Marco van de Voort]

Post by Michael Schnell

Post by Marco van de Voort
Ask yourself why GCC doesn't have preprocessed headers,

I supposed you mean "precompiled headers" and not "headers that are
passed through the preprocessor.
This is according to what I called the "C philosophy" in the other mail.
Even if this philosophy is simplistic and introduced by need rather than
by science, it _is_ consistent and workable.

I don't hate C. I use it daily. But I still think it shows that it was never
meant for applications programming(*). For that I think "workable" doesn't
apply. Survivable maybe, but IMHO not something one would choose if you
could avoid it.

For systems usage, I think it is still not ideal, but it matters less.

(*) not entirely true historically. C was also meant for making the unix
utils, but in their time they were much, much smaller than they are
nowadays. I think "ls" nowadays is bigger than the C compiler (the biggest
*nix app) in the old days

--

[Michael Schnell]

Post by Marco van de Voort
I don't hate C. I use it daily. But I still think it shows that it was never
meant for applications programming(*). For that I think "workable" doesn't
apply. Survivable maybe, but IMHO not something one would choose if you
could avoid it.

Yep. This is why we (company) use C for deeply embedded stuff, while for
application programming and not-so-deeply-embedded (PC-based right now,
ARM-based to come) projects, we use Pascal. (Never touching C++ :) )

But exactly this sometimes asks for using C code in Pascal projects to
avoid duplicating of code snippets.

-Michael

--

[Hans-Peter Diettrich]

Post by Michael Schnell

Post by Marco van de Voort
Ask yourself why GCC doesn't have preprocessed headers,

I supposed you mean "precompiled headers" and not "headers that are
passed through the preprocessor.
This is according to what I called the "C philosophy" in the other mail.
Even if this philosophy is simplistic and introduced by need rather than
by science, it _is_ consistent and workable.

There is one problem with the independent header files: what if modules
are compiled with #defines or an #include stack, that differ from those
used to compile another (used) module itself?

FPC overcomes this problem with the .ppu files (I assume), C++ with
mangled names, reflecting the precise attributes of every compiled item.

This problem also should make clear that (standard) header files *must*
be compiled with the same settings, or better must be insensitive to all
external #defines or previously #included files, so that a project uses
the same compilation parameters for all referenced modules. In so far
it's perfectly acceptable to use precompiled header files, that match
the compiled version of every module in a project or library. The
compiler only should place and search for such precompiled headers in
the object directory, into which a module (to be linked) has been
compiled. But this in turn would require to pass the path to every
single library folder to the compiler...

DoDi


--

[Marco van de Voort]

Post by Hans-Peter Diettrich
FPC overcomes this problem with the .ppu files (I assume)

No. That is an optimalization. The core feature is defining the unit
concept, and clearing (reinitializing from cmdline params) preprocessor
state

Post by Hans-Peter Diettrich
C++ with
mangled names, reflecting the precise attributes of every compiled item.

.... which is why to my best knowledge, C++ doesn't solve this at all.

Mangled names solve name clashes between same named symbols in different
modules. They say nothing about this.

But you are right that the preprocessor state _IS_ the problem.

--

[Hans-Peter Diettrich]

Post by Michael Schnell
In fact I already missed sadly a fully working preprocessor (to be
activated optionally). This does help with Pascal sources from time to
time (in fact I do like macros better than generics :) ).

You could use the scanner/preprocessor part of ToPas, if you want an
fully conforming C preprocessor. I think that I dropped this project
from ToPas, but it could be added again without problems. IIRC Skalogryz
currently is porting all that stuff from Delphi to Lazarus...

Post by Michael Schnell
I don't see why simply calling the gcc preprocessor is not a viable
option (at least with Lazarus on Linux). Supposedly for a better
integration a Pascal based workalike preprocessor might be better.

The C preprocessor most probably depends on C syntax (strings and other
literals...), so its use may be restricted to such source code. AFAIR
the C90 standard (C98 for sure) already required that the preprocessor
is an integral part of the compiler, so that up-to-date stand-alone
preprocessors may be rare. And not all of them comply to the standard,
with regards to proper macro expansion. I know about two extreme cases,
where the Sinix(?) preprocessor insisted in expanding #defined symbols
even in string literals, and the Microsoft preprocessor has other
incompatible ideas about macro expansion and comments; you'll find more
details in the ToPas documentation...

DoDi


--

[Hans-Peter Diettrich]

Post by Marco van de Voort

Post by Hans-Peter Diettrich
I've already translated a couple of available C libraries into Pascal,
using ToPas. There exist only a few constructs that do not translate
into Pascal directly (bitfields...), but their addition to the compiler
(code generators) should not be a problem - in the easiest case they can
be emulated in pure OPL, not affecting the code generators at all. At
statement and procedure level most languages don't differ much, and FPC
even has the C operators already implemented. Since the ToPas C parser
is written in OPL, its adaptation should be easy. This may become my
next project, after the parser...

Since accessing header files is repeated as possible advantage files again
and again, how much progress have you made in the opposite direction?
Automated header translation

Sorry, I don't understand your point :-(

I found it inevitable to process existing C code at the source level, so
that every update can be reflected immediately and automatically by the
compiler. Any source code transformation, from C to Pascal, has to be
repeated after every such update, leading to much manual intervention,
and all modifications in the previously translated Pascal code are lost.
A maintenance nightmare :-(

About the opposite direction, Detlef Meyer-Eltz has made big progress in
providing translators from Delphi/OPL and Java into C++, see e.g.
<http://www.texttransformer.com/Delphi2Cpp_en.html>. While these tools
are not perfect, what IMO is impossible to achieve, they have been used
in the conversion of a couple of big commercial projects into C++.

This one-time transformation is *not* what I want to achieve, for the
beforementioned (maintenance) reasons. It may be a goodie for making
people move from C/C++ background to Pascal, when they can transform all
their legacy projects to the new language, but this can be achieved
independently from any concrete Pascal compiler.

As long as we live in a C dominated world (Linux...), every compiler
should be able to process C code, so that at least the existing C
libraries can be used immediately. Sometimes it's sufficient to only
have a header conversion tool, for external libraries, but sometimes
it's more desireable to incorporate such libraries more directly into an
application, like Delphi and Lazarus allow with their package system.
Such packages could be made usable more easily, when e.g. a more
"pascally" interface can be added to the original source code, by e.g.
patches, so that the use of such libraries is no more restricted to
their original C interface.

DoDi


--

[Florian Klämpfl]

Post by Hans-Peter Diettrich

Post by Marco van de Voort
Since accessing header files is repeated as possible advantage files again
and again, how much progress have you made in the opposite direction?
Automated header translation

Sorry, I don't understand your point :-(

The point is: if an additional C front end for fpc could do fully
automatically the job, it must be also possible to do this with an
external tool which translates C to pascal.

--

[Michael Van Canneyt]

Post by Michael Van Canneyt

Post by Florian Klämpfl
... because it increases the maintainance work on fpc. Even with one
front end only we are almost unable to keep the issue count under
control. I'am pretty sure that more front ends will be rejected without
more people working on bug fixing in fpc.

Exactly. We can barely cope as it is. If we compiled C as well, we'd get
bug reports about glibc or whatever C library fails to compile.

I've already translated a couple of available C libraries into Pascal, using
ToPas. There exist only a few constructs that do not translate into Pascal
directly (bitfields...), but their addition to the compiler (code generators)
should not be a problem - in the easiest case they can be emulated in pure
OPL, not affecting the code generators at all. At statement and procedure
level most languages don't differ much, and FPC even has the C operators
already implemented. Since the ToPas C parser is written in OPL, its
adaptation should be easy. This may become my next project, after the
parser...

You are missing the point. The point is not DOING it. the point is the
support afterwards. After 15 years of FPC support, I have some experience.
Even now, bugs creep up that are seemingly SO basic:
W : word;
begin
w:=0;
for i:=0 to pred(w) do // What to do ?
end;

The compiler's behaviour is different from Delphi. This is a bug, we must
deal with it. After 15 years. So, if the compiler produces different code
in some C library, then we'll have to deal with it. People will report it.
So no, thank you.

And frankly, I would not use topas as a reference. I tried it on some - to
my taste - simple C code and it failed horribly. I was unable to solve it,
also because it lacks all documentation. This is not the kind of standard
I would like to see in FPC.

So I'd say that you already failed on something more simple than FPC
compiling all languages. First get topas to convert all C code out
there without a glitch, then we'll talk again.

Do not get me wrong: I think topas is a technically nice product. I admire
that you can write the code to do it, to make it work (more or less). That is
not the point; The point is that writing the code is actually the least of
the problems. It's what comes afterwards.

Post by Michael Van Canneyt
And, frankly, the project is called "Free Pascal" for a simple reason: it
is a *Pascal* compiler and a *Pascal* project.

Microsoft started with a couple of compilers, until they implemented a common
back-end for all "Visual" languages, and later they invented the CLR. gcc
also allows to add FEs for a certain class of languages, so why should FPC
not become another Free Portable Compiler?

Because Microsoft has 1500 people, GCC has several companies behind it.
FPC has 4 people technically savvy in compiler matters.

I wonder how somebody can say "it's hard to do", without having even tried
;-)

I didn't say it is hard. I say that the support for it would kill us and the
project.

This is the problem of most open source out there: Enthousiasts write
it. And then the good is separated from the bad: supporting it for many
years. Patiently fixing all bugs. And there will be lots.

FPC existed before the term 'Open Source' existed. That means something.

Michael.

--

[Hans-Peter Diettrich]

Post by Michael Van Canneyt
You are missing the point. The point is not DOING it. the point is the
support afterwards. After 15 years of FPC support, I have some experience.
W : word;
begin
w:=0;
for i:=0 to pred(w) do // What to do ?
end;
The compiler's behaviour is different from Delphi. This is a bug, we must
deal with it. After 15 years. So, if the compiler produces different code
in some C library, then we'll have to deal with it. People will report it.
So no, thank you.

Thanks for the concrete example. I also remember a discussion about
Inc/Dec, where every improvment (taking into account the signedness of
the operand) was rejected, in favor of the "translate into a single
machine instruction" - where not every CPU supports such an instruction.

With regards to subtle OPL/C differences I don't expect that these are
handled by the FPC team. Additional front-ends are not a concrete
subject right now, they only came up as another chance to extend the
compiler. Furthermore the C language specification is quite vague in
many details, while an OPL specification does not exist at all, so that
code like the above most probably will behave differently, depending on
the used compiler (both as C and Pascal code).

Post by Michael Van Canneyt
And frankly, I would not use topas as a reference. I tried it on some - to
my taste - simple C code and it failed horribly. I was unable to solve
it, also because it lacks all documentation. This is not the kind of
standard I would like to see in FPC.

Do you seriously expect that things will change, without any feedback? :-(

Perhaps you missed the ToPas documentation, available in a separate
download? I know that this project is very hard to use, due to the
dependency on external resources (header files, compiler
specifications), so that I can understand when people have problems to
use it as-is. That's why I abandoned further work on this project, many
years ago, after I could make it work with the header files and
libraries of several compilers. And there was no reason to put my hands
on it at any later time, due to zero feedback. In detail I missed
feedback with ideas to make it easier usable.

Post by Michael Van Canneyt
So I'd say that you already failed on something more simple than FPC
compiling all languages. First get topas to convert all C code out there
without a glitch, then we'll talk again.

The base of the ToPas project was the C preprocessor and parser,
previously implemented as the CScan project. ToPas effectively is a test
application for that project, and there I found no way to make it an
*easily* usable tool. In so far an FPC front-end would be just another
test case for CScan, where it could be made usable much easier, and
possibly with more helpful feedback.

Post by Michael Van Canneyt
Do not get me wrong: I think topas is a technically nice product. I admire
that you can write the code to do it, to make it work (more or less). That is
not the point; The point is that writing the code is actually the least of
the problems. It's what comes afterwards.

I'm still waiting for such problems, and I'm willing to fix all known
bugs myself :-)

Post by Michael Van Canneyt
Because Microsoft has 1500 people, GCC has several companies behind it.
FPC has 4 people technically savvy in compiler matters.

So the addition of only one person (me) would add 25% percent to the
staff - which other compiler manufacturer can afford such an increase? ;-)

Post by Michael Van Canneyt

Post by Hans-Peter Diettrich
I wonder how somebody can say "it's hard to do", without having even
tried ;-)

I didn't say it is hard. I say that the support for it would kill us and the
project.

That's why I intend to make the (eventual) C front-end a non-breaking
add-on to FPC, that relies on nothing but the existing compiler
infrastructure and back-ends. Then we can find out more about the hidden
capabilities of the compiler, and the chance and problems of integrating
(very) different languages. In case that project fails to work
sufficiently, due to unforeseen language incompatibilities, I've spent
some time at least with learning more about concrete compilers :-)

Post by Michael Van Canneyt
This is the problem of most open source out there: Enthousiasts write
it. And then the good is separated from the bad: supporting it for many
years. Patiently fixing all bugs. And there will be lots.

I've already been spending much time in the Lazarus docking managers, so
that now the IDE offers docking support, after years of preparations.
But since this project is almost finished now, I'm looking for further
projects, that may be useful to others. I can spend all my time in such
projects, the only limitation is increasing age and consequential health
problems.

Post by Michael Van Canneyt
FPC existed before the term 'Open Source' existed. That means something.

My discompilers (borrow'd from "disassemblers") also worked a long time
before the term "decompiler" was even born ;-)

I only didn't publish them, except for the VB3 decompiler, because I
wanted to control their use myself. Many hundred pleased customers made
me continue the evolution of this project, over a couple of years. Even
in the last year I've supported two new customers, but now VB3 seems to
be really dead, with all VB3 applications either being decompiled or
upgraded to newer VB versions.

DoDi


--

[Michael Van Canneyt]

Post by Hans-Peter Diettrich
Do you seriously expect that things will change, without any feedback? :-(
Perhaps you missed the ToPas documentation, available in a separate download?
I know that this project is very hard to use, due to the dependency on
external resources (header files, compiler specifications), so that I can
understand when people have problems to use it as-is. That's why I abandoned
further work on this project, many years ago, after I could make it work with
the header files and libraries of several compilers. And there was no reason
to put my hands on it at any later time, due to zero feedback. In detail I
missed feedback with ideas to make it easier usable.

First idea: make it a lazarus project. I rarely have windows available.

After a trivial test, I wanted to translate libsee. It's heavily unix based,
so of course the whole windows side of the - now discovered, thank you -
docu is useless.

BTW. The reference to Templates.htm in index.html is wrong.

Post by Hans-Peter Diettrich
I've already been spending much time in the Lazarus docking managers, so that
now the IDE offers docking support, after years of preparations. But since
this project is almost finished now, I'm looking for further projects, that
may be useful to others. I can spend all my time in such projects, the only
limitation is increasing age and consequential health problems.

Well, if you need things to do:
- Make fcl-passrc complete. (*NOT* extract parser from compiler).
- use it to create a pascal to javascript translator.
- Create a .net backend code generator.
- Create a java bytecode backend code generator.

The latter 2 are much asked for by users, and while none of the core
maintainers has any desire to work on them, patches implementing them will
definitely be accepted (within certain limits the team will set) if you
also accept maintenance.
Since you seem well versed in pascal, parsing and whatnot, I think you
should be up to the task.

And contrary to a new front-end, I think there will be little to no
discussion about their acceptance, as long as the pascal language is
respected.

Michael.

--

[Reimar Grabowski]

On Thu, 1 Jul 2010 19:14:40 +0200 (CEST)

Post by Michael Van Canneyt
- Make fcl-passrc complete. (*NOT* extract parser from compiler).

+1

R.

[Doug Chamberlin]

Post by Michael Van Canneyt
- Make fcl-passrc complete. (*NOT* extract parser from compiler).

+1


--

[dmitry boyarintsev]

On Thu, Jul 1, 2010 at 5:14 PM, Michael Van Canneyt

Post by Michael Van Canneyt
- Make fcl-passrc complete. (*NOT* extract parser from compiler).
- use it to create a pascal to javascript translator.

something like this? :)

thanks,
dmitry

[Adem]

Post by Michael Van Canneyt
- Make fcl-passrc complete. (*NOT* extract parser from compiler).

I just cannot understand this: What is so holy about the 'parser from
compiler'?

Post by Michael Van Canneyt
- use it to create a pascal to javascript translator.
- Create a .net backend code generator.
- Create a java bytecode backend code generator.

Aren't all these some form of 'escape route's --from always Pascal to
somewhere else?

I mean, people --of course-- should be given opportunities to escape;
but, what does it say about their concerns about Pascal in the first
place :)

Cheers,

Adem


--

[Adem]

Post by Adem
Why do you think Pascal would lose its glamor when (or if) FPC can
compile other languages?

... because it increases the maintainance work on fpc. Even with one front end only we are almost unable to keep the issue count under control. I'am pretty sure that more front ends will be rejected without more people working on bug fixing in fpc.

My assumption was this: Anyone who's going to add such capabilities
would do it in a way that he/she/they would make sure there's enough of
momentum/community to undertake not only the maintenance of their own
(different lang compilation or whatever) contribution, but also help
with relevant issue count in FPC.

IOW, this sort of thing should be a precondition to such contributions.
Keeping the door ajar (or, at least, not closed) for this sort of thing
would be --IMHO-- a good thing as it is likely to bring on (more)
commercial (and, hence/hopefully more stable) interest to the FPC flora
and fauna.

Frankly, I am not terribly fixated on getting 'commercial interest', but
I am old enough to know that 'love' alone isn't always enough to
guarantee continuity.

Post by Adem
If you could compile, say, Modula (or C/C++) with FPC, you would have direct access to a huge& time-tested resource of libraries etc which you could directly incorporate into your applications,

This can be done already using compilers supporting these languages

True. But, wouln't it be nice if people could use, say, libc (as
recently mentioned in FPC list) in FPC too?

Cheers,

Adem


--

[Florian Klämpfl]

Post by Adem

Post by Florian Klämpfl

Post by Adem
If you could compile, say, Modula (or C/C++) with FPC, you would have
direct access to a huge& time-tested resource of libraries etc which
you could directly incorporate into your applications,

This can be done already using compilers supporting these languages

True. But, wouln't it be nice if people could use, say, libc (as
recently mentioned in FPC list) in FPC too?

I don't see the point? This is already possible?

--

[Marco van de Voort]

Post by Adem

Post by Adem
Why do you think Pascal would lose its glamor when (or if) FPC can
compile other languages?

... because it increases the maintainance work on fpc. Even with one front end only we are almost unable to keep the issue count under control. I'am pretty sure that more front ends will be rejected without more people working on bug fixing in fpc.

My assumption was this: Anyone who's going to add such capabilities
would do it in a way that he/she/they would make sure there's enough of
momentum/community to undertake not only the maintenance of their own
(different lang compilation or whatever) contribution, but also help
with relevant issue count in FPC.
IOW, this sort of thing should be a precondition to such contributions.
Keeping the door ajar (or, at least, not closed) for this sort of thing
would be --IMHO-- a good thing as it is likely to bring on (more)
commercial (and, hence/hopefully more stable) interest to the FPC flora
and fauna.

It is a devilish dillemma.

Being lax, and you become dumping ground for failed experiments of people
that lose interest, and the main project will suffer. We already have a
packages/ dir to prove this for the other libraries.

The only workable solution, require a stable group to form is several years
minimum might seem overly crude.

On the other hand, the compiler is much more stable nowadays, and even a
branch of a major version doesn't initiate a lot of rewrites of code (like
it used to).

A fork for a while might be doable, and it wouldn't brake the new team with
constant stability and compatibility requirements etc.

Post by Adem
Frankly, I am not terribly fixated on getting 'commercial interest', but
I am old enough to know that 'love' alone isn't always enough to
guarantee continuity.

Not wanting to plunge the project into a chaotic rewrite has nothing to do
with commercial interests. If there are reasonable doubts about the success
of this attempt, it is only logical that Core doesn't want to upset the
project for a long time. And then there is the issue of possible speed degradation.

Post by Adem

Post by Adem
If you could compile, say, Modula (or C/C++) with FPC, you would have direct access to a huge& time-tested resource of libraries etc which you could directly incorporate into your applications,

This can be done already using compilers supporting these languages

True. But, wouln't it be nice if people could use, say, libc (as
recently mentioned in FPC list) in FPC too?

I think these "pie in the sky" kind of scenarios are several years if not
longer beyond the initial C compiler. It will be a plant that needs a lot
of nurturing and care for a very long term, before it becomes an
alternative, and faces stiff competition. And there is another problem that
the "pie in the sky" scenarios seem to be the main reasons for the compiler,
so it will require quite a pigheaded team.

If these rosy C helps Pascal interoperability scenarios are possible at all.
Kylix uses Pascal bindings to libc, despite Borland having a (compatible!)
C/C++ compiler. And C++ compatible Delphi code is stuffed top till bottom
with {$externalsym xx} and similar helper commands.


--

[Adem]

Post by Marco van de Voort
It is a devilish dillemma.

It defintely is.

But, the whole process of evolution is just that [and, no, for this
once, I am not out to start a 'creationism' vs 'evolution' war here ;) ]

Post by Marco van de Voort
Being lax, and you become dumping ground for failed experiments of people that lose interest, and the main project will suffer. We already have a packages/ dir to prove this for the other libraries.

I think I fully understand Core's concerns: It simply does not make
sense to destabilize the whole project after some adventure.

And, any code that gets into the main distribution should be such that
it proves it is an essential part of it --i.e. it is worth having and
worth maintaining.

Post by Marco van de Voort
A fork for a while might be doable, and it wouldn't brake the new team with constant stability and compatibility requirements etc.

This is, IMHO, the best response one can expect. Implicit in this
temporary fork should be the understanding that as long as the fork is
considered better (I know, a subjective thing) and that it is backward
compatible (or, with the absolute minimum --and/or understandable--
incompatibilities), the fork will be given due consideration for
inclusion/acceptance in part or in full. IOW, forks should not end up
being wild goose chases.

Post by Marco van de Voort
Not wanting to plunge the project into a chaotic rewrite has nothing to do with commercial interests. If there are reasonable doubts about the success of this attempt, it is only logical that Core doesn't want to upset the project for a long time. And then there is the issue of possible speed degradation.

Asking for a rewrite of a running project would be insane --not that
such insanity has never been in SW world (Netscape comes to mind)--, and
we need to avoid that. A better solution would be a fork (or a parallel
project).

Post by Marco van de Voort
I think these "pie in the sky" kind of scenarios are several years if not longer beyond the initial C compiler. It will be a plant that needs a lot of nurturing and care for a very long term, before it becomes an alternative, and faces stiff competition. And there is another problem that the "pie in the sky" scenarios seem to be the main reasons for the compiler, so it will require quite a pigheaded team.

Of course, such stretched scenarios will take time --if they ever
materialize. But, we can never know; perhaps there's already someone
brilliant enough in the crowd here who's looking for some such feat pull
and later use it as part of his/her CV.

Post by Marco van de Voort
If these rosy C helps Pascal interoperability scenarios are possible at all. Kylix uses Pascal bindings to libc, despite Borland having a (compatible!) C/C++ compiler. And C++ compatible Delphi code is stuffed top till bottom
with {$externalsym xx} and similar helper commands

I am curious: Since compilers are your domain, allow me to ask: Do you
think Borland did that (peppering code with '$externalsym xx ' stuff)
because there was not other/better way? And, if you had a truly
compatible C/C++ compiler, would you end up doing that too?

Cheers,

Adem


--

[Marco van de Voort]

Post by Adem

Post by Marco van de Voort
I think these "pie in the sky" kind of scenarios are several years if
not longer beyond the initial C compiler. It will be a plant that needs
a lot of nurturing and care for a very long term, before it becomes an
alternative, and faces stiff competition. And there is another problem
that the "pie in the sky" scenarios seem to be the main reasons for the
compiler, so it will require quite a pigheaded team.

Of course, such stretched scenarios will take time --if they ever
materialize. But, we can never know; perhaps there's already someone
brilliant enough in the crowd here who's looking for some such feat pull
and later use it as part of his/her CV.

There is a difference between hope and dreaming. Be careful that you don't
get hung up in some scenario where you "wait" for people to come, or wait
till the hordes come and help out in the purest open source spirit.

Somehow that never happens.

Post by Adem

Post by Marco van de Voort
If these rosy C helps Pascal interoperability scenarios are possible at all. Kylix uses Pascal bindings to libc, despite Borland having a (compatible!) C/C++ compiler. And C++ compatible Delphi code is stuffed top till bottom
with {$externalsym xx} and similar helper commands

I am curious: Since compilers are your domain, allow me to ask: Do you
think Borland did that (peppering code with '$externalsym xx ' stuff)
because there was not other/better way? And, if you had a truly
compatible C/C++ compiler, would you end up doing that too?

I fear so. The trouble is that I think that joining two so different
languages (I mean as far as interfacing goes, e.g. C's big reliance on
preprocessing that is very freeform and has no automated equivalent) totally
transparently is very, very difficult. Maybe even not possible.

Personally, I would invest more time in this before I went on a wild goose
chase, and question why there are no quality automated translators already,
after these languages have been side by side for 4 decades.

The pie in the sky scenarios might turn out to be attractive on paper only
e.g. when only a very small subset of headers might be readily usable
without heavily adding finely grained directives.

Borland had a commercial C++ compiler, commercial Pascal compilers,
knowledge in the company, and they didn't. I think they suspected that
something fully automated would never be possible, and keeping it lowtech
and transparents makes it doable for more users.

--

[Adem]

There is a difference between hope and dreaming. Be careful that you don't get hung up in some scenario where you "wait" for people to come, or wait till the hordes come and help out in the purest open source spirit.
Somehow that never happens.

We're both saying pretty much the same thing, I think: Don't count your
chickens before they hatch. And, I am not.

It's just that unpredictabilty works both ways --cue in a quote by E. E.
Cummings: "You shake and shake and shake the bottle, first nothing comes
and then the lottle".

It took us a few million years to the first prototype of telephone, and
more than a century till it became portable/mobile; and then, less than
20 years to be ubiquitous enough that world regions can now simply
bypass POTS altogether in favor of GSM. Things like these make me an
optimist.

Now, will someone please hurry up about that flying car I've been
waiting for all this time ;)

Borland had a commercial C++ compiler, commercial Pascal compilers, knowledge in the company, and they didn't. I think they suspected that something fully automated would never be possible, and keeping it lowtech and transparents makes it doable for more users.

I don't know.

Borland, somehow, managed to lose direction, leadership and most of the
talent along with it a long time ago.

It turned into a bureaucratic geriatric wardful of clockers.

With all the knowledge about compilers --supposedly in the company--
they are yet to come up with a 64 compiler, let alone a cross-platform
RAD after all these years.

Heck, they have managed to misplace the help system so badly that no one
has been able to locate any sign of it for years.

Having seen all these and more, I am not at all sure they went for
anything more than the absolute minimum they could do about
multi-(dual-)language compiler.

Cheers,

Adem


--

[Hans-Peter Diettrich]

Post by Marco van de Voort

Post by Adem
I am curious: Since compilers are your domain, allow me to ask: Do you
think Borland did that (peppering code with '$externalsym xx ' stuff)
because there was not other/better way? And, if you had a truly
compatible C/C++ compiler, would you end up doing that too?

I fear so. The trouble is that I think that joining two so different
languages (I mean as far as interfacing goes, e.g. C's big reliance on
preprocessing that is very freeform and has no automated equivalent) totally
transparently is very, very difficult. Maybe even not possible.
Personally, I would invest more time in this before I went on a wild goose
chase, and question why there are no quality automated translators already,
after these languages have been side by side for 4 decades.

IMO we should separate C from C++ in this debate. C++ has a very
different object model form the Delphi one, as have other languages as
well (Java, Oberon et al. - which also use GC allover). That's why a
restriction to only C will result in much simpler solutions, as I
demonstrated in my ToPas converter. An only-C front-end for an Pascal
compiler would be sufficient to me, allowing to use existing C library
code immediately in Pascal programs.

The problem, that lead to the stall of the ToPas project, is the
separation of the C #defines into true constants, functions and macros.
When the user has to classify each of the #defines in e.g. Windows.h
(about 900) himself, this makes the entire project unusable. But when
instead the C code is preprocessed automatically, and fed directly into
the tree generation of the compiler, such user decisions are no more
required.

Post by Marco van de Voort
The pie in the sky scenarios might turn out to be attractive on paper only
e.g. when only a very small subset of headers might be readily usable
without heavily adding finely grained directives.
Borland had a commercial C++ compiler, commercial Pascal compilers,
knowledge in the company, and they didn't. I think they suspected that
something fully automated would never be possible, and keeping it lowtech
and transparents makes it doable for more users.

The BCB was a nice try, aimed at the C++ coder community, but Borland
only could establish it as a serious MSC competitor, that forced
Microsoft to upgrade their crappy MSC (and other) tool suites into the
up-to-date MSVC development system. Since that time the development of
the VCL and IDE was the only thing Borland could do, and its low market
acceptance lead to the sale of that division, that ended up in Embarcadero.

DoDi


--

[Graeme Geldenhuys]

Post by Adem
IOW, this sort of thing should be a precondition to such contributions.
Keeping the door ajar (or, at least, not closed) for this sort of thing
would be --IMHO-- a good thing as it is likely to bring on (more) commercial
(and, hence/hopefully more stable) interest to the FPC flora and fauna.

Like Michael said, the project is called "Free Pascal" for a reason.
But you are always welcome to fork the project and frequently merge
"pascal" related changes from the FPC project into your forked
project. This way you can choose a more appropriate project name as
well. :)
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--

[Adem]

IOW, this sort of thing should be a precondition to such contributions. Keeping the door ajar (or, at least, not closed) for this sort of thing would be --IMHO-- a good thing as it is likely to bring on (more) commercial (and, hence/hopefully more stable) interest to the FPC flora and fauna.

Like Michael said, the project is called "Free Pascal" for a reason. But you are always welcome to fork the project and frequently merge "pascal" related changes from the FPC project into your forked project. This way you can choose a more appropriate project name as well. :)

It's not as if I am about to start such a project, let alone dump
megabytes of owen-fresh code; we're simply talking about some
possible/probable future direction and whether it would be a good idea
to make provision for that sort of thing.
IOW, nothing concrete; nothing of imminence.

At this point, I think I remember the time when you announced fpGUI
--Lazarus was around then.
But, I can't quite recall whether you were met with such a resistence
--that there already existed a project for precisely the same purpose
and you should pool in your resources into that.
Were you?

Cheers,
Adem


--

[Graeme Geldenhuys]

of owen-fresh code; we're simply talking about some possible/probable future
direction and whether it would be a good idea to make provision for that

Fair enough. Civilised discussions would be nice to see for a change. :-)

But, I can't quite recall whether you were met with such a resistence --that
there already existed a project for precisely the same purpose and you
should pool in your resources into that. Were you?

fpGUI and LCL have very different goals, even though, from a distance,
they look like the same thing. And yes, I have received many mails
(more than I care to remember) saying that I should pool my efforts
with LCL. LCL doesn't allow for what we [our company] need, that is
why I limit my efforts to the Lazarus IDE only.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--

[Adem]

fpGUI and LCL have very different goals, even though, from a distance, they look like the same thing.

And, I am sure people get to appreciate their differences once they
spend a little time to understand what they are.

Your fpGUI as well as Michael's (Schnell) MSEide+MSEgui and other
similar projects are a richness for the whole community --not resource
consumers-- serving different needs.

And yes, I have received many mails (more than I care to remember) saying that I should pool my efforts with LCL.

I could ask whether these emails came from the core of LCL team, but
that wouldn't contribute to our discussion here.

I will, however, ask whether you thought they were *fair*.

LCL doesn't allow for what we [our company] need, that is why I limit my efforts to the Lazarus IDE only.

IOW, your work on/with fpGUI has all but helped LCL too.

Cheers,

Adem


--

[theo]

Post by Adem
Your fpGUI as well as Michael's (Schnell) MSEide+MSEgui and other

Cui honorem, honorem ;-)
His name is Martin Schreiber (MSEide+MSEgui)



--

[Adem]

Post by theo

Post by Adem
Your fpGUI as well as Michael's (Schnell) MSEide+MSEgui and other

Cui honorem, honorem ;-)
His name is Martin Schreiber (MSEide+MSEgui)

Thank you for the correction.

I apologize for the typo.

Cheers,

Adem


--

[Graeme Geldenhuys]

Post by Adem
I will, however, ask whether you thought they were *fair*.

Those suggesting it, did not understand our companies needs. I think I
have explained myself already to a few of the core LCL developers (and
a few others too) so they might have a better understanding of why our
company don't use LCL.

Post by Adem

LCL doesn't allow for what we [our company] need, that is why I limit my
efforts to the Lazarus IDE only.

IOW, your work on/with fpGUI has all but helped LCL too.

Unfortunately not everybody sees it that clearly. "Contributions" come
in all shapes and sizes. I contribute features driven by need, or fix
minor issues I could easily find a solution for. But most of my
contributions come from bug reports and helping to pinpoint the
location of the issue. Unfortunately many here in the Lazarus mailing
list consider the last point as "nagging" or always trying to talk
Lazarus down. I stopped caring about those misguided few that don't
understand my point of view - I have much more important things to
worry about these days. :-)
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--

[Hans-Peter Diettrich]

Post by Florian Klämpfl

Post by Adem
Why do you think Pascal would lose its glamor when (or if) FPC can
compile other languages?

... because it increases the maintainance work on fpc. Even with one
front end only we are almost unable to keep the issue count under
control. I'am pretty sure that more front ends will be rejected without
more people working on bug fixing in fpc.

I don't think that the workload is increasing so much. Of course every
FE deserves its own maintenance, but once the syntax (parser) is
implemented, there remains nothing to do on it.

Post by Florian Klämpfl

Post by Adem
If you could compile, say, Modula (or C/C++) with FPC, you would have
direct access to a huge & time-tested resource of libraries etc which
you could directly incorporate into your applications,

This can be done already using compilers supporting these languages

These compilers are not available for all FPC-supported platforms, and
linking their binaries to an FPC application may not work, due to
different object formats, RTL etc.

A common compiler also could eliminate the need for writing interfaces
for such libraries - to some degree.

DoDi


--

[Michael Schnell]

Post by Florian Klämpfl
This can be done already using compilers supporting these languages

As discussed multiple times it's not possible to share classes between
FP-Pascal and GNU-C++. I don't know it it's possible at all to share
classes between Pascal and C++, even if FP would be enhanced to compile
C++ code.

-Michael

--

[Florian Klaempfl]

Post by Michael Schnell

Post by Florian Klämpfl
This can be done already using compilers supporting these languages

As discussed multiple times it's not possible to share classes between
FP-Pascal and GNU-C++. I don't know it it's possible at all to share
classes between Pascal and C++, even if FP would be enhanced to compile
C++ code.

Only as a cppclass because the Object Pascal class modell is very
different from that one of C++. But don't underestimate the work to do
so: there is nothing to reuse so far. It needs a C++ front end and a C++
back end. Everybody dreaming of something like this might start with the
"cppclass" support in FPC and create the back end part first.

--

[t***@mikro.ee.tu-berlin.de]

Hello,

perhaps I'm missing the point but I think it would be a good idea to
enhance "swig" to create fpc-bindings to C++-Classes. Personally I
think there is no problem with having another C-Compiler.

Regards,
Stephan


--

[Marco van de Voort]

Post by Florian Klaempfl

Post by Michael Schnell
FP-Pascal and GNU-C++. I don't know it it's possible at all to share
classes between Pascal and C++, even if FP would be enhanced to compile
C++ code.

Only as a cppclass because the Object Pascal class modell is very
different from that one of C++. But don't underestimate the work to do
so: there is nothing to reuse so far. It needs a C++ front end and a C++
back end. Everybody dreaming of something like this might start with the
"cppclass" support in FPC and create the back end part first.

And then finds out that half of the libs you want to use are stuffed with
C++ templates and other lanugage features.

I think stuff like cppclass will never work on a large-scale for C++ code
that was not specially crafted (kept clean) for it.

--

[Michael Schnell]

Post by Adem
If you could compile, say, Modula (or C/C++) with FPC, you would have
direct access to a huge & time-tested resource of libraries

In fact being able to tightly integrate C code (I can't speak for C++,
as I can't speak it) would be really nice to have. To be useful the
languages should be mixable at least on a per-unit base (better
per-procedure) and the debugger would be necessary to be working
properly on that.

I don't think this is easy to do, though.

-Michael

--

[Marco van de Voort]

Post by Michael Schnell

Post by Adem
If you could compile, say, Modula (or C/C++) with FPC, you would have
direct access to a huge & time-tested resource of libraries

In fact being able to tightly integrate C code (I can't speak for C++,
as I can't speak it) would be really nice to have. To be useful the
languages should be mixable at least on a per-unit base (better
per-procedure) and the debugger would be necessary to be working
properly on that.
I don't think this is easy to do, though.

I'm less afraid of difficulty and work, but more afraid that the results,
and the inevitable compromises would render it useless.

People think now "it would be nice" and think of a solution that operates as
a button "compile all this pascal and C source from various origins
magically together", and don't see the real picture.

The real picture will probably that both the pascal and the C/C++ side need
to be specially crafted. Think of Delphi's $externalsym, pureclass etc
hacks.

--

[Hans-Peter Diettrich]

Post by Michael Schnell

Post by Adem
If you could compile, say, Modula (or C/C++) with FPC, you would have
direct access to a huge & time-tested resource of libraries

In fact being able to tightly integrate C code (I can't speak for C++,
as I can't speak it) would be really nice to have. To be useful the
languages should be mixable at least on a per-unit base (better
per-procedure) and the debugger would be necessary to be working
properly on that.
I don't think this is easy to do, though.

IMO we should not go into such details right now, like the debugger.
Instead we should find out about useful applications of the parser and
additional front-ends, to give motivation to the FPC developers to
implement some basic (non-breaking) prerequisites. Then we can find out
more about further chances and problems, in concrete projects that use
the FPC compiler and related code as-is.

DoDi


--

[Rigel Rig]

Windows has DLL-s. DLL, written in C, C ++... can be used in Delphi, and I guess in Lazarus. Why not use them? It is much easier. And you can write them in whatever language you want.

In Linux do you have something similar? Why not use it instead to mix Pascal with C, C++, Java... philosophy?
I can not understand one thing: is there a Lazarus project manager like in other open source projects? Why not he/she say will  Lazarus support other languages except FP or not and stop this discussion?

-------- ОрОгОМалМП пОсЌП --------
От: Florian Klaempfl
ОтМПсМП: Re: [Lazarus] Parser
ДП: Lazarus mailing list
ИзпратеМП Ма: Четвъртък, 2010, ЮлО 1 16:20:50 EEST

Post by Michael Schnell

Post by Florian Klaempfl
... which does not mean that it fits into the Pascal philosophy.

Of course it does not. That exactly was my point.

So it's pretty clear that a C front end does not change much.
--
_______________________________________________
Lazarus mailing list
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
 

-----------------------------------------------------------------
ЗрелОщМО сМОЌкО Пт ЮАР 2010. ВОжте Май-ОМтересМОте ЌПЌеМтО!
http://sportni.bg/worldcup2010/?tid=20&oid=1002