Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 01:36:56AM +0300, Adem wrote:
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.
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.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 12:17:47AM +0200, Hans-Peter Diettrich wrote: 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Adem schrieb: On 2010-07-01 00:20, 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'; 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#. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Marco van de Voort schrieb: On Wed, Jun 30, 2010 at 10:53:39PM +0200, Michael Van Canneyt wrote: ... 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. 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? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
2010/6/30 Adem listmem...@letterboxes.org: 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/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 06/30/2010 10:23 PM, 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 09:23, 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 06/30/2010 10:31 PM, 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, 1 Jul 2010, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: ... 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. 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: On 06/30/2010 10:31 PM, 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. 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 08:48:00AM +0200, Florian Klaempfl wrote: And, frankly, the project is called Free Pascal for a simple reason: 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 10:17, Graeme Geldenhuys wrote: 2010/6/30 Ademlistmem...@letterboxes.org: 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 09:18:06AM +0200, Michael Schnell wrote: On 06/30/2010 10:23 PM, 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. 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb:
On 07/01/2010 08:26 AM, 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).
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.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 1 July 2010 09:37, Adem listmem...@letterboxes.org 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. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 07/01/2010 10:00 AM, 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.
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
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 09:34:12AM +0200, Michael Schnell wrote: On 07/01/2010 08:26 AM, 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 :) ). 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 10:21:30AM +0200, Michael Schnell wrote: On 07/01/2010 10:00 AM, 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. 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. 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. (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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 07/01/2010 10:57 AM, 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 01/07/10 09:57, 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 07/01/2010 10:51 AM, 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, 1 Jul 2010 00:19:34 +0200 Mattias Gaertner nc-gaert...@netcologne.de wrote: 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. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Henry Vermaak schrieb: On 01/07/10 09:57, 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. 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). -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: On 07/01/2010 10:51 AM, 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. ... which does not mean that it fits into the Pascal philosophy. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 11:08:49AM +0200, Michael Schnell 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. 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: On 07/01/2010 10:00 AM, 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. ... 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 07/01/2010 11:22 AM, 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
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. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Marco van de Voort schrieb: 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. 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Marco van de Voort schrieb: On Thu, Jul 01, 2010 at 12:17:47AM +0200, Hans-Peter Diettrich wrote: 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Florian Klaempfl schrieb: 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Florian Klaempfl schrieb: 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Van Canneyt schrieb: 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. 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. 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 :-) 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? ;-) 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 :-) 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
Re: [Lazarus] Parser
Florian Klaempfl schrieb:
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)
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
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: On 06/30/2010 10:23 PM, 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. 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, 01 Jul 2010 00:54:21 +0200 Hans-Peter Diettrich drdiettri...@aol.com wrote: 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. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] 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 :-( 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
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. Adem escreveu: 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. -- Alexsander da Rosa Twitter: @alexrosa -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 11:19, 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Your fpGUI as well as Michael's (Schnell) MSEide+MSEgui and other Cui honorem, honorem ;-) His name is Martin Schreiber (MSEide+MSEgui) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 12:10, Reimar Grabowski wrote: On Thu, 1 Jul 2010 00:19:34 +0200 Mattias Gaertnernc-gaert...@netcologne.de wrote 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. 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, 1 Jul 2010, Hans-Peter Diettrich wrote: 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. 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 20:10, 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, 01 Jul 2010 20:12:52 +0300 Adem listmem...@letterboxes.org wrote: 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 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. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 19:51, Alexsander Rosa wrote: 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. Adem escreveu: 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, 1 Jul 2010 19:14:40 +0200 (CEST) Michael Van Canneyt mich...@freepascal.org wrote: Well, if you need things to do: - Make fcl-passrc complete. (*NOT* extract parser from compiler). +1 R. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 7/1/2010 1:14 PM, Michael Van Canneyt wrote: - Make fcl-passrc complete. (*NOT* extract parser from compiler). +1 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Florian Klaempfl schrieb: 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. 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 1 July 2010 18:18, 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 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/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser [OT]
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 -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Possible bug
Hi, I can't log-in to Mantis to report this. Please, if anyone can access create a report for this. The bug is this: When you press CTRL+SPACE after typing an object name in the editor, it shows its methods and properties (autocompletion, code insight, you_name_it), that's ok, but, when the user selects a property or method, the cursor disappears from the editor, instead of letting the user continue writing as it should. This bug is here since at least two weeks. Tested on Revision 26392 - Linux x86_64 - GTK2. -- Leonardo M. Ramé Griensu S.A. - Medical IT Córdoba Tel.: 0351-4247979 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Hans-Peter Diettrich schrieb: 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. 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 1 July 2010 18:58, 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. :-) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 23:22, 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser [OT]
On 1 July 2010 22:06, Reimar Grabowski wrote: 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/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 20:26, Reimar Grabowski wrote: On Thu, 01 Jul 2010 20:12:52 +0300 Ademlistmem...@letterboxes.org wrote: 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. :) 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Possible bug
On Thu, 01 Jul 2010 17:09:29 -0300 Leonardo M. Ramé l.r...@griensu.com wrote: Hi, I can't log-in to Mantis to report this. Please, if anyone can access create a report for this. The bug is this: When you press CTRL+SPACE after typing an object name in the editor, it shows its methods and properties (autocompletion, code insight, you_name_it), that's ok, but, when the user selects a property or method, the cursor disappears from the editor, instead of letting the user continue writing as it should. This bug is here since at least two weeks. Tested on Revision 26392 - Linux x86_64 - GTK2. What gtk version do you use? Can you try to find the svn revision that broke it? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 20:14, 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser [OT]
On Fri, 02 Jul 2010 00:55:27 +0300 Adem listmem...@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. 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. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser [OT]
On Thu, 1 Jul 2010 23:27:43 +0200 Graeme Geldenhuys graemeg.li...@gmail.com wrote: 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. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser [OT]
On 2010-07-02 02:10, Reimar Grabowski wrote: On Fri, 02 Jul 2010 00:55:27 +0300 Ademlistmem...@letterboxes.org 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. :) 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? 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser [OT]
On Fri, 02 Jul 2010 03:22:34 +0300 Adem listmem...@letterboxes.org wrote: 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Possible bug
El vie, 02-07-2010 a las 00:25 +0200, Mattias Gaertner escribió: On Thu, 01 Jul 2010 17:09:29 -0300 Leonardo M. Ramé l.r...@griensu.com wrote: What gtk version do you use? Can you try to find the svn revision that broke it? Mattias My libgtk2.0-0 is 2.20.1-0ubuntu2. Is that what do you need?. About trying to find which revision broke it, it's a difficult task, I think it could be easier to try to find and fix the bug, I don't have any problem in doing this. Could someone point me to the sources that implement this feature?. I don't even know how do you call it, is it AutoCompletion?. -- Leonardo M. Ramé Griensu S.A. - Medical IT Córdoba Tel.: 0351-4247979 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 08:12:52PM +0300, Adem wrote: 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 02:27:22PM +0200, 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) 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. 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-02 07:33, 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 01:55:43PM +0200, Hans-Peter Diettrich wrote: 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. 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 06:56:26PM +0200, 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 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
