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 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

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

Mattias Gaertner wrote

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

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.

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.

4) It's not yet known how the rest of a unit (declarations...) is represented internally.

It is processed directly.

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.

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.

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

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

Hans-Peter Diettrich wrote

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

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

> 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 ;-)

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

> 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.

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

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

We'll see ;-)

DoDi

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

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

... 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.

This can be done already using compilers supporting these languages

or even do automatic source code translation

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.

Florian Kl?mpfl wrote

Adem schrieb: > 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.

> 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, 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

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

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

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

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

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.

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.

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.

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 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'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 Kl?mpfl wrote

> 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

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.

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

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
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...

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?

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

DoDi

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.

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

Mattias

Marco van de Voort wrote

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 ;) ]

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.

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.

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).

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.

If these rosy C helps Pascal interoperability scenarios are 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

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.

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

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.

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.

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

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#.

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?

2010/6/30 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. :)

Adem wrote

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 wrote

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

Florian Kl?mpfl wrote

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

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.

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.

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.

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.

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 wrote

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

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.

Graeme Geldenhuys wrote

2010/6/30 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

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.

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.

Adem wrote

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.

Florian Klaempfl wrote

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.

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.

Yep.

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

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

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.

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)

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.

(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.

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

(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.

Marco van de Voort wrote

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.

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

Marco van de Voort wrote

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

Marco van de Voort wrote

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

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 it possible to continue the discussion somewhere else, please?

R.

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).

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

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

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

... 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.

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.

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

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

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

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

Florian Klaempfl wrote

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

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

-Michael

Marco van de Voort wrote

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

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

On 07/01/2010 11:15 AM, Florian Klaempfl wrote: > ... 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.

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).

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.

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.

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

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? ;-)

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 :-)

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.

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

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...

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

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)

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

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 only because it is vaguely related does not mean it is the correct list.

Thx, for not listening.

A not amused
R.

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.

"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".

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

Graeme Geldenhuys wrote

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

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

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

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.

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

theo wrote

> 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

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.

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.

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

> 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.

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.

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 it was
doomed to failure due to licensing.

Cheers,

Adem

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

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

Well, if you need things to do: - Make fcl-passrc complete. (*NOT* extract parser from compiler).

+1

R.

Michael Van Canneyt wrote

- Make fcl-passrc complete. (*NOT* extract parser from compiler).

+1

Reimar Grabowski wrote

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 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).

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

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.

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 wrote

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.

> 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. :-)

Florian Kl?mpfl wrote

Hans-Peter Diettrich schrieb: > 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?

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

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

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

>> 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. ;)

> 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.

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

Michael Van Canneyt wrote

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.

something like this? :)

thanks,
dmitry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ExpVal.zip
Type: application/zip
Size: 6216 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100701/2515aeda/attachment-0001.zip>

Michael Van Canneyt wrote

Well, if you need things to do: - Make fcl-passrc complete. (*NOT* extract parser from compiler).

I just cannot understand this: What is so holy about the '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.

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

On Fri, 02 Jul 2010 00:55:27 +0300
Adem 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.

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.

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.

Such an awful idea, isn't it?

Yes, it is an awful idea.

Kind regards
R.

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.

Reimar Grabowski wrote

On Fri, 02 Jul 2010 00:55:27 +0300 Adem wrote: First of all I apologize for hurting your feelings.

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

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. :)

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?

> 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

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).

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. http://images.cheezburger.com/completestore/2010/1/29/129092786498235257.jpg

R.

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.

Hans-Peter Diettrich wrote

> 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)

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.

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.

Marco van de Voort wrote

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100702/82d9c596/attachment-0001.html>

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.

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".

Hans-Peter Diettrich wrote

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

C++ with mangled names, reflecting the precise attributes of every compiled item.

.... which is why to my best knowledge, C++ doesn't solve 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.

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?

----------------------------------------------------------------- ???????? ?????? ?? ??? 2010. ????? ???-??????????? ???????! http://sportni.bg/worldcup2010/?tid=20&oid=1002
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100702/6f9a835e/attachment.html>

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?

[...] 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

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.

I'm curious, can Java be used to write a dll?

In Linux do you have something similar? Why not use it instead to mix Pascal with C, C++, Java...?philosophy?

I don't know why not, because lazarus does since the beginning.

http://wiki.lazarus.freepascal.org/Overview_of_Free_Pascal_and_Lazarus http://wiki.lazarus.freepascal.org/Lazarus/FPC_Libraries

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?

The tail of the discussion was about extending FPC to do the job of the existing C compilers.
The main thread is - as far as I understand it - about extending the fpc parser. I think it should be moved to fpc-devel or fpc-other. It is not about lazarus.

Mattias

Call it some form of perfectionism, if you like. Or 'unionism', for a slightly better term. (reasons below)

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.

That's just it: There are simply too many of them neither one is as complete or up-to-date as the original.

And, the reason there are too many simply boils down to the fact that the real/genuine/true one wasn't/isn't available.

I mean, it's not as if you need a completely different parser for IDE purposes; the fact that you have to write and maintain one is because you have to do it.

And, as expected, each one of those baby-parsers are merely partial emulators of the actual one.

I am surprised you (plural) don't see this as waste of resources, but instead tell *me* it would be a waste of time to refactor the fpc-code so that its parser can be used (or extended, as the case may be) as a blackbox module downstream in all those projects which shouldn't have had to write parsers.

What do you want to use the fpc parser for?

It's not 'fpc parser' in the sense that it cannot be used anywhere else; it is a parser that is currently used solely within free-pascal compiler. I would like it to be available to other people too.

Isn't this a good enough reason?

Do I have to have an ulterior motive? Shall I invent one :)

> [...] > 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.

I do sympathize with those fears; but, as you'll agree, worries about speed degradation can only be meaningfully addressed (put to rest) when the actual code is available --no amount of talk or assurances can help/change that.

Now, about 'gain':

I think you're overlooking medium/long term benefits.

When you turn the parser into a module (for the purposes of usage downstream, in IDE etc.), what you will have actually done is to make that 'parser module' replaceable too.

That alone can be worth its weight in gold, in the sense that from then on, you can use other 'parser module's --such as, you name it, 'C module', 'Modula module', 'Java module' etc. etc.

And, that expands horizons, brings in more talent.

Which cannot be bad for FPC, can it?

Cheers,

Adem

And I believe you are overlooking all problems coming with maintenance of such solution. I agree that having one parser for all different kind of usage is solution which would be great to have, but my opinion is that it should be based on fcl parser, not compiler's one.

And later, IF (whoever does the job) succeeds in making such a good parser (which gets integrated into, for example, Lazarus and proves to be well implemented), only then it is time to think how to connect that parser with compiler's one. At least, that's how I see this situation.

It all sounds really nice, doesn't it :-)

Hi!

It's not about escaping Pascal, but to grant the language new possibilities.

On Android phones you can only use Java to access all subsystems of the device (e.g. GUI). You can access the framebuffer from native code though, but directly drawing to a memory field is not the same as using the available GUI classes. It has yet to be found out whether you can access the JVM from a native application (not a native library which is loaded by JVM).

Also the new Windows Phone 7 series relies completly on .Net, so our WinCE cross compiler is completly useless here (the usage of .Net is enforced by the kernel itself). And Microsoft might also try to prepare the way for full .Net desktop operating systems. Now that they've discovered virtualization (Windows 7 XP Mode) the compatibility problems might stop them no more. We might not see this in Windows 8 and maybe not in Windows 9 either. But perhaps Windows 10 might be the big breaker of Win32?

Free Pascal should be able to compile for these plattforms. But I don't mind to use a completly different RTL and object model that suits the targeted plattform, I only want to use the language which I believe is superior to C# and Java.

Regards,
Sven

No.
It's about speed and memory structures.
Just think about a general parser. It must handle macros, directives, include files, spaces, encodings, comments, line endings, syntax errors. It must work for code snippets and needs a bunch of flags what to ignore while parsing.
It creates an output with a lot of different nodes and every code that accesses this output must handle this vast amount of information and must be updated whenever the parser is changed.

No.
As I said: Every parser has features that the others don't have. For example the synedit parser can parse code snippets very fast, because it can save/restore its whole state very fast. The fpc parser can not do that.

It is available, it is open source.
You want to change it, so it can be used for other things than compiling. So the question remains: For what other things?

Isn't this a good enough reason?

It is, but please don't ignore the good reason against it. Speed, memory, zoo of flags, how to .

Please take a look at projects that have replaceable parsers, like swig, highlighter systems, ctags. Swig was rewritten three times from scratch. Highlighters and ctags use only very small subsets of the languages and often not correct ones, just to fit into a general parser api.

And, that expands horizons, brings in more talent. Which cannot be bad for FPC, can it?

There is not one solution for everything.

Mattias

I'm curious, can Java be used to write a dll?

I did not know that Java can not create dll! I am very happy that many years ago when Java must had a special computer to run, unlike Delphi, gave up Java.? I think some programmers in C, Java ... can not survive the thought that FPC is so quick and Lazarus is so easy to use! I made a simple test: I opened Lazarus, compile and run an empty project. It took 15". Just launch the Delphi 7 took 18"! For Delphi .Net will be longer. For Eclipse there is nothing to talk about. :) Thanks for the links!

----------------------------------------------------------------- ???????? ?????? ?? ??? 2010. ????? ???-??????????? ???????! http://sportni.bg/worldcup2010/?tid=20&oid=1002
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100702/77262a55/attachment.html>

Aleksa Todorovic wrote

And I believe you are overlooking all problems coming with maintenance of such solution. I agree that having one parser for all different kind of usage is solution which would be great to have, but my opinion is that it should be based on fcl parser, not compiler's one. And later, IF (whoever does the job) succeeds in making such a good parser (which gets integrated into, for example, Lazarus and proves to be well implemented), only then it is time to think how to connect that parser with compiler's one. At least, that's how I see this situation.

Why not this: Modularize FPC's parser and test in extensively in a forked FPC.
If it passes, then propose it to FPC.
Afterwards, FCL --as well as anyone else-- can use it to their hearts content.

> And, that expands horizons, brings in more talent. > > Which cannot be bad for FPC, can it? It all sounds really nice, doesn't it :-)

Just wait till I tell you my plans for peace in Middle East, hunger in Ethiopia, law and order in Afghanistan etc. :)

Cheers,

Adem

In fact the Lazarus developers could decide to make the Lazarus IDE C aware and use gcc to compile the stuff. (Not that I would vote for ding so....)

-Michael

All good and valid points. I respectfully retract my earlier comments in these very cases.

But, the unfortunate thing is, unless someone has already done it, no amount of valid reasons alone can assure that you'll get those capabilities added.

Why don't you consider organizing/initating something yourself?

Cheers,

Adem

Hi!

Adem wrote

But, the unfortunate thing is, unless someone has already done it, no amount of valid reasons alone can assure that you'll get those capabilities added.

Yes, that is the problem... :(

Why don't you consider organizing/initating something yourself?

Don't think that I haven't thought of that already. :P But I have many dreams and a very huge todo-List (alone for FPC: cppclass, Native NT port, Minix port, maybe usage of SEH for Win32) and I'm also studying and have a job (the latter two are the reason I'm currently not much working on said FPC pet projects -.-)... In some time perhaps, but not now (and that might be too late... *sigh*).

Regards,
Sven

Curious: What will cppclass do in FPC?

Is it something like this

http://packages.python.org/PyBindGen/cppclass.html

It says "A CppClass object takes care of generating the code for wrapping a C++ class"

Cheers,

Adem

Hi!

It's an old feature of Free Pascal that was never fully implemented and should allow to link with C++ code/libaries without flattening the interface (like done with QT). It establishes a completly new object hierarchy that is unrelated to TObject like Jonas has done with objcclass to interface with Objective-C.
You can search for "cppclass site:freepascal.org" to find some bug reports and mailing list entries regarding this. It's not yet documented, because I've not yet found the time to do this.

Regards,
Sven

Any progress?

Mattias

Just mail me a login and password to get your own branch in the fpc svn.

Just mail me a login and password to get your own branch in the fpc svn.

I got no response on my last mail - any problems?

DoDi