As some of you may already know, I teach programming in Far Eastern National University
and encourage students to participate in open source projects for their course works.
Among opensource projects I recommend are Free Pascal and Lazarus.

Last year one of my students already participated in FPC development with moderate success (see http://bugs.freepascal.org/view.php?id=13700).

This year, I expect 1-3 more students to choose Lazarus/FPC for their projects. So I request community for a suitable ideas -- projects should be reasonably self-contained, not too hard, require actual coding and be interesting enough to motivate students.
Students will work on projects they select from October 2009 to April 2010.

Alexander Klenin wrote

As some of you may already know, I teach programming in Far Eastern National University and encourage students to participate in open source projects for their course works.

Here are some relevant pages *IN RUSSIAN*:

Previous student works:
http://imcs.dvgu.ru/works/home?name=Pascal;year=

Requirements for students:
http://imcs.dvgu.ru/works/course_view?id=1766

Alexander Klenin wrote

So I request community for a suitable ideas -- projects should be reasonably self-contained, not too hard, require actual coding and be interesting enough to motivate students.

During the Embarcadero CodeRage sessions this week I took a look at the IOUtils unit introduced in Delphi 2010. I expect developers to start using it as they tart to use Delphi 2010 more and more. It would be a big advantage to have an FPC version of this unit.

I have no idea how other Delphi-compatible functionality was developed but I expect the right thing to do is obtain the interface for this unit and have the students re-implement the functionality using FPC.

This year, I expect 1-3 more students to choose Lazarus/FPC for their projects. So I request community for a suitable ideas -- projects should be reasonably self-contained, not too hard, require actual coding and be interesting enough to motivate students.

As a first step for FPC, have a look at:
http://wiki.freepascal.org/Open_tasks

Alexander Klenin wrote

Last year one of my students already participated in FPC development with moderate success (see http://bugs.freepascal.org/view.php?id=13700).

This is a very good feature and it is so nice that it was done by a student with some directions by Florian and Jonas. I did not expect a positive result when you started.

I would ask to implement modern delphi language features like:
- anonymous methods
- for-in loop
- class constructors and destructors
- support for strict private and strict protected sections
- abstract and sealed classes
- class const, class var, class type, class property

Anyway, sooner or later delphi developers will use them more and more and there will be a need to port that code to fpc.

Best regards,
Paul Ishenin.

That unit might require functionality that is not yet there, because Codegear does all new units in a static class style. (class var/const etc)

I second this.
- Class helpers come to mind.
- Attributes (the extended RTTI In D2010)
- Delayed keyword for lazy binding

Michael.

There is an article at the embarcadero website:
http://edn.embarcadero.com/article/34324 but it covers only d2007 features.

Best regards,
Paul Ishenin.

Yes, I saw that during one of their D2010 launch-sessions. Any idea why they do this? Is it just a .Net-me-too?

Joost.

Yes I think so. Pretty much with everything, same with the new RTTI modifier stuff in front of a declaration, instead after it. When I asked a question about that, they were even surprised I doubted it at all. (worse, it was Bob Swart!)

However due to the reaction of the audience (I went to a D2010 introduction by Barnsten yesterday), specially from the younger crowd, the public opinion seems to be this is absolutely great functionality.

The Wings Of Wind website has a good overview too.

Michael.

I still haven't seen any practical use for the new RTTI modifier stuff. I made some comments on some websites, but everybody keeps nagging about the persistent storage uses. Which is a basically flawed use of the feature. No-one has provided an alternative use yet :(

Michael.

I sugest you Pascal soure code analizer and build a pascal class builder.

2009/9/12 Alexander Klenin :

Another thing which is not that difficult to implement but can be very useful is a resource compiler (a tool which make res files from rc).

Best regards,
Paul Ishenin.

I sugest you Pascal soure code analizer and build a pascal class builder.

What do you mean with "a pascal class builder"?

Mattias

a GUI program for generate an modify Pascal Class codes. can generate property,methods and event handling functions. like ClassBuilder for C++(http://sourceforge.net/projects/classbuilder) for Delphi there is a program called "OPEdit",but there is no newer version on the net,and it's a shareware.

2009/9/12 Mattias Gaertner :

Michael Van Canneyt wrote

I still haven't seen any practical use for the new RTTI modifier stuff.

Tag fields for endian correction in the header, and use a generic record endianess correction routine?

Also a definite possibility, but again very minor in it's application...

Michael.

Another thing possible is to implement the package mechanism.

Most of the basic stuff is already in the compiler (dynamic libraries, RTTI, etc), but there is a need to bring that together in something easily usable (maybe add a XML-based manifest in the package, add some code to check compiler compatibilities, etc). Demos can be provided and I can provide support to one or several students on how to achieve. Of course, the FPC and Lazarus team needs to tell us how they want to integrate the feature. We can also breakdown the work so that it is achieved over a couple of years..

Best regards,
Thierry

These are obvious candidates for me too, but although they are good projects, they are rather hard -- for advanced students only. I certainly hope to get at least one such student.

But I am also interested in a simpler ideas,
perhaps for Lazarus instead of FPC.

Generally form the replies I get the impression that the need for FPC is much more acute than for Lazarus ones ;-)

This is good idea, but unfortunately, there is not a chance to start before the release for Delphi 2010. Also, I can not expect students to obey strict clean room procedures required for such reimplementation.

I agree that syntax is awkward, but I am afraid compatibility is more important than better syntax.
OTOH, attribute-first syntax gives a way to implement grouping by attribute, something like:

type T = class
public
   ...
   procedure A;
   procedure B;
   begin [deprecated]
     procedure A_old;
     procedure B_old;
   end;
end;

What is flawed with it? I think this is indeed great for building persistence frameworks.

No-one has provided an alternative use yet :(

Oh, there are many use cases, here are just a few:
- web frameworks (attributes like "handler", "ajax_handler" etc.) -- see any Ruby or Perl framework for detailed usage.
- scripting (attribute "scriptable" for methods callcble from scripts)
- VCL/IDE itself (e.g. attribute "hide_from_OI" for published properties you do not want to display in Object Inspector)
- basically, anything requiring class registration now, including the need to register
components to stream forms.

The latter point will require some kind of built-in global classes registry, which I am not sure will be in D2010, but this is a good feature anyway.

One thing to implement which is needed and easy at the same time is support for turning paticular warnings and hints on/off in the code:

{$WARN identifier ON} / {$WARN identifier OFF} where identifier can be: SYMBOL_PLATFORM, SYMBOL_DEPRECATED, UNIT_DEPRECATED, UNIT_PLATFORM, UNSAFE_CODE OFF, UNSAFE_TYPE OFF, UNSAFE_CAST OFF, IMPLICIT_STRING_CAST, ...

I suggest to allow also ON/OFF by warning message ID. For example {$WARN 5033 OFF} will turn off message "Function result does not seem to be set".

Same to do with hints {$HINT message_id ON}/{$HINT message_id OFF} although delphi does not support this.

Why it is easy:
1. fpc understand {$WARN} syntax while it currently do nothing
2. fpc allow to turn off warnings and messages by ID

Therefore your student will just need to complete already existed code.

Best regards,
Paul Ishenin.

Alexander Klenin wrote

This is good idea, but unfortunately, there is not a chance to start before the release for Delphi 2010. Also, I can not expect students to obey strict clean room procedures required for such reimplementation.

FYI, Delphi 2010 is already released.

Best regards,
Paul Ishenin.

ACK, all these tasks required deep insight into the existing compiler code and data structures :-(

Perhaps a somewhat simpler goal: add the new Attributes syntax to the parser, and check for possible implementations. I don't understand the hype and problems with these new attributes - is it really more than adding an Attributes:TStrings property to TObject?

And another one: an Oberon front-end for FPC! {$mode OBERON} The language should be close enough to Pascal, so that the implementation of the parser should not be a big deal. More difficult: the interface to the existing compiler.
There is much room for sub-projects, like garbage collection.

The same for other languages (Java, C...). Wouldn't it be nice to have a C front-end or {$MODE C} for opening the world of existing C code (at least: header files) to FPC? See my ToPas project on SourceForge, that implements an preprocessor and parser for C, written in Delphi OPL - it could be extended by an interface to the FPC compiler.

DoDi

Why not replace all the compiler directives, which are unknown to the Delphi compiler, by a common different format, like {#PRAGMA WARN...}, and implement a general Pragma subsystem, where the FPC people could add the functionality later, if this part is too time consuming for a student project?

DoDi

This is simularity not compatibility. And no, I don't agree. Orthogonality is an important concept.

Which is so different from

begin
   procedure A_Old;
  procedure B_OLD;
end[deprecated];

A syntax concept that has already been used btw (though for assembler procedures)

> persistent storage uses. Which is a basically flawed use of the feature. What is flawed with it? I think this is indeed great for building persistence frameworks.

Not the primary one.

> No-one has provided an alternative use yet :( Oh, there are many use cases, here are just a few: - web frameworks (attributes like "handler", "ajax_handler" etc.) -- see any Ruby or Perl framework for detailed usage.

I'm sorry. Could you explain this? I know what a handler is, and handlers are already RTTId.

- scripting (attribute "scriptable" for methods callcble from scripts)

To do exactly what? You could use it maybe to avoid heaps of registrating methods with the interpreter, but not more.

- VCL/IDE itself (e.g. attribute "hide_from_OI" for published properties you do not want to display in Object Inspector)

That's more the stuff I imagine. Make annotations so you can easily make exceptions, e.g. due to legacy or versioning concerns.

- basically, anything requiring class registration now, including the need to register components to stream forms.

You still need to register the components. It must know what to iterate for RTTI.

The latter point will require some kind o?f built-in global classes registry, which I am not sure will be in D2010, but this is a good feature anyway.

They did say something about being able to RTTI down from a global level. So it could be that yes.

However it is great for demoes and mails, but applying this succesfully in a major framework that stands the test of time might be hard.

I think it is great for the smaller persistance work (forms, config files etc), but would like to keep it away from the mission critical stuff for general databinding.

This idea about an Oberon front-end is <very> interesting. I second that idea!

Thierry

The same for other languages (Java, C...). Wouldn't it be nice to have a C front-end or {$MODE C} for opening the world of existing C code (at least: header files) to FPC?

The problem of header files are macros. No more, no less. Supporting them makes pascal as unreadable as C is.

Why it's not easy (else it would have been implemented):
- it requires a memory efficient tracking of the state of these switches for every location in the source. Due to the modularized and decoupled compilation process of FPC this is not as simple as it might look.

- for-in loop

This might be as easy as the case of string though it requires probably more code.

2009/9/13 Florian Klaempfl :

I would rather opt for Iterator support in all standard collection classes. Something like what Java does. I have written and wrote an article on this and designed iterators for most standard collection classes in Object Pascal, but it would be much nicer if they came standard with all those collection classes.

Regards,
- Graeme -

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

Yes, my speech. But this is probably harder for a student.

They are a definite no-no. They go against everything that Pascal stands for.

Michael.

Hans-Peter Diettrich wrote

And another one: an Oberon front-end for FPC! {$mode OBERON}

This would be an exceptionally cool thing, and I'm sure it would attract much attention in wider circles!

Well, fpc already track {$WARNINGS OFF}/{$WARNINGS ON}, {$HINTS OFF}/{$HINTS ON} switches for every location in the source. I suppose tracking paticular warning/hint can be done in a similar way.

Best regards,
Paul Ishenin.

2009/9/13 Florian Klaempfl :

Yes, my speech. But this is probably harder for a student.

In that case, I should merge my iterators with the collection classes and start submitting patches, so they can be included in FPC directly. I'll post one small patch for one class for review -- before I do them all.

Regards,
- Graeme -

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

2009/9/12 Alexander Klenin :

So I request community for a suitable ideas -- projects should be reasonably self-contained, not too hard, require actual coding and

Seeing that we are list our wishlists... :-)

* Full support for "implements" interface delegation in classes.

* Complete Semaphore support via a TSemaphore class -- like was done for TCriticalSection.

Regards,
- Graeme -

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

Hans-Peter Diettrich wrote: > And another one: an Oberon front-end for FPC! {$mode OBERON} This would be an exceptionally cool thing, and I'm sure it would attract much attention in wider circles!

Are you sure this would be possible?
Then all other languages coud be added too: ;-)

{$mode PERL}
{$mode ALGOL}
{$mode Cplusplus}
{$mode Csharp}
{$mode dotNET}
{$mode COBOL}
{$mode BASIC}
{$mode LISP}
{$mode EIFFEL}
{$mode HASKELL}
{$mode JAVA}
{$mode PYTHON}
{$mode LOGO}
{$mode BRAINFUCK}
{$mode C}
{$mode WHITESPACE}
{$mode ZONNON}
{$mode ...}

How does a C front-end affect the Pascal front-end?

DoDi

If it doesn't affect it, it has no use or what would you do with macros in headers? If they aren't supported in the pascal front end, it makes no sense to read them with a C frontend.

[ ] You understand what's a preprocessor

DoDi

An interesting idea, but probably too hard for a student project, would be the capability of using a C library without having to manually create the pas file that translates the c header. That is tedious, error prone and a mess when the .h changes and we continue to use the wrong .pas and strange error creep in.
Also there are a lot of C libraries that are not available to fpc because nobody had the time to create the bindings. I know that there is h2pas but it is a off line tool and needs a lot of help from the programmer.

A better way could be to hack a C compiler (GCC ?) and use only the parser and the first compilation stage to have the symbols related to the available functions and structures and create the pas header from that information. With such tool we could have almost automatic use of any c library...

Of course, hacking an existing C compiler is not a mostly welcome prospect for those who like fpc/Lazarus :)

Paulo Costa

An interesting idea, but probably too hard for a student project, would be the capability of using a C library without having to manually create the pas file that translates the c header.

This is what ToPas can already do. But...

That is tedious, error prone and a mess when the .h changes and we continue to use the wrong .pas and strange error creep in.

Right, the translator needs exactly the header files as used to create the library.

I'm aware of possible changes in C libraries and header files, and that's why now I suggest an Pascal compiler with the added ability to process C files. Then that compiler would both compile a changed library, and create an Pascal interface unit at the same time. This is exactly what the CBuilder does for Delphi.

A transformation of C files into Pascal units, as ToPas can do (to some degree), IMO is only a provisional solution. When manual intervention is required in this step, it will be required for every following bugfix or improvement to the C code.

This part of ToPas is already finished :-)

and create the pas header from that information. With such tool we could have almost automatic use of any c library...

The hardest problem I found in ToPas is an automated handling of the #defines. They should be classified into literal constants, functions, macros, and (incomplete) code snippets - where code snippets IMO are of no use in a Pascal unit. Such classification could be done easily by an LR parser, but an LL parser only can deal with complete source files.

DoDi

Yes. That's the main problem with an off-line tool :( Whatever the mechanism used it must work without manual intervention.

That's nice.

Yes, that is one of the nastiest problems.
I think that a compromise solution would be an extra file where the macros could be classified by an human. Then, the conversion mechanism would use that information when called. Usually, the macros don't change very often and a warning could be issued when a new macro appeared without classification.

Paulo Costa

J?rgen Hestermann wrote

Are you sure this would be possible? Then all other languages coud be added too: ;-)

Oberon is not just an arbitrary other language, it is Pascals younger brother and ALGOL is their mother and it is told that the same guy named Wirth was around at ETH Z?rich both times when they were created.

I'm not sure how flexible the compiler is and how easy or difficult implementing a new frontend would be, not all the languages in your list are statically typed so much of them wouldn't make sense at all for this compiler, but maybe ALGOL, Modula and Euler would be cool also, to make this family of languages more complete.

And maybe Ada should also be worth thinking about? Ada would be even cooler and has a lot more practical applications than Oberon or Modula, and maybe even the US DoD would start supporting the ompiler ;-)

Marco van de Voort het geskryf:

Yes I think so. Pretty much with everything, same with the new RTTI modifier stuff in front of a declaration, instead after it. When I asked a question about that, they were even surprised I doubted here... I asked in the non-technical newsgroup. I was brushed of as

yet another Free Pascal troll. They kept bringing up the point that it is C# compatible. I don't give a flying f*ck about C#, I use Object Pascal! Also CodeGear doesn't even do Delphi.NET anymore, so why still copy .NET & C# syntax.

Regards,
- Graeme -

Alexander Klenin het geskryf:

I agree that syntax is awkward, but I am afraid compatibility is more important than better syntax.

Like I told them in the non-technical newsgroup... Compatibility with what? C#??? But the language we are talking about is Object Pascal, NOT C#.

The pascal language generally has modifiers at the end of a declaration. Now Object Pascal parsers and compilers must all be modified to look for modifiers infront and after a declaration. At is purely C# syntax, not Object Pascal syntax! Hasn't CodeGear learnt there lesson with .NET yet??

Regards,
- Graeme -

If I want "eggs and Bacon" I use my oven, not the engine of my car...

Well, finally, I prefer a toaster that toast my bread perfectly, over laptop that also makes coffee.

IOW: I want a perfect pascal compiler, not some chameleon, that does 1000 things but none of them right.

regards
B.

Bernd Kreuss schrieb: Oberon is not just an arbitrary other language, it is Pascals younger brother and ALGOL is their mother and it is told that the same guy named Wirth was around at ETH Z?rich both times when they were created.

But there seems to be a reason that these guys didn't enhance Pascal but created completely new languages.

I don't think that it is wise to use a Pascal compiler to compile code from another language, even if it is very similar to Pascal in some respects (and if it's even possible). I believe that there are fundamental differences, otherwise it would not be a different language.

And the existing {$MODE..} modifications are already too much. They were added to avoid code modifications to older programs but they never help me to avoid them yet. In the end, the code had to be adapted anyway.

I would prefer not to do even more of these modifications so that noone can read any code snipped anymore because he does not know which language is meant.

Something that I'd like to see, because I use garbage collected languages mostly, is trying to get the Boehm memory manager working as the plugin memory manager.

I've tried to do it and failed because I don't know fpc that well, and although it seems to work on small tests i can't use the unix library without a segfault.

I don't think it's worthwhile to argue here the benefits of a garbage collector as it's well documented, but certainly, FPC offering such a feature, would help make certain categories of applications more robust , and imo, have the possibilty of attracting many more developers, particularly java developers, as you get the write once compile everywhere and gc which is really all java ever offered.

bd

Codegear goes where the public opinion goes, to sell. However the slavish following by a lot of the forummembers continues to surprise me.

So you are suggesting a preprocessor that reads C and outputs Pascal? :-)

Modula2 is the brother. Modula-3 is the OOP cousin. Oberon is Modula-3's ackward brother :)

I'm all for Modula2. It is one of the nicest languages from a didactic point of view IMHO.

Is not this the definition of the public opinion? :-)

Maybe you should write compilers for 15 years, then we continue, might be 2024 then.

The primary reason for new languages is to replace the old syntax by a better one. This was done in Modula, the ancestor of Oberon. Then objects were added, with various improvements. Finally garbage collection was added to Oberon. Only the garbage collection is really new to FPC Pascal, and it IMO is the only thing that may deserve modifications to the compiler. And GC is a nice playground for student compiler projects :-)

Right, there exist languages that are compatible with FPC, and others that are incompatible.

And the existing {$MODE..} modifications are already too much. They were added to avoid code modifications to older programs but they never help me to avoid them yet. In the end, the code had to be adapted anyway.

Most languages do not deserve new modes, because the source files have other than PAS extensions.

I would prefer not to do even more of these modifications so that noone can read any code snipped anymore because he does not know which language is meant.

ACK.

DoDi

No, this were what ToPas does. Instead I suggest to skip the intermediate Pascal code, and to compile the given source code immediately.

DoDi

Maybe you should write compilers for 15 years

I've written (in fact invented) decompilers for 25 years, and learned a lot about compilers this way :-)

DoDi

The pascal language generally has modifiers at the end of a declaration.

Right, and the syntax sucks :-(
(all the semicolons should be removed from the modifiers, with a single semicolon terminating a declaration)

Now Object Pascal parsers and compilers must all be modified to look for modifiers infront and after a declaration. At is purely C# syntax, not Object Pascal syntax! Hasn't CodeGear learnt there lesson with .NET yet??

IMO they have learned that copy&paste is an essential RAD method. In so far I understand that copying C# declarations into OPL source code simplifies interfacing with the rest of the world.

DoDi

IOW: I want a perfect pascal compiler, not some chameleon, that does 1000 things but none of them right.

gcc has been very successul, with its ability to compile many languages (including Pascal!). IMO it only differs from FPC in the OO model, so that FPC could play the role of gcc in the world of languages compatible with the OPL object model.

DoDi

GCC is also known for being a good optimizing compiler.

Is it feasible to use some of the optimizing tech from GCC in FPC?

Raymond.

Maybe port to fpc and enhance FlashPascal (
http://flashpascal.sourceforge.net/) is a good project for students.

2009/9/11 Alexander Klenin

So you want a hybrid pascal/C compiler? Or at which point do you want to do macro expansion and translation of the resulting C?

Hans-Peter Diettrich het geskryf:

IMO they have learned that copy&paste is an essential RAD method. In so far I understand that copying C# declarations into OPL source code simplifies interfacing with the rest of the world.

I can't say I have ever heard of a single case where C# developers moved to Delphi (Object Pascal) language. The opposite seems quite popular.

So that tell me, that there is NO point in copying the C# language syntax to a Object Pascal language - no developers move in that direction.

Regards,
- Graeme -

Marco van de Voort het geskryf:

Codegear goes where the public opinion goes, to sell. However the slavish following by a lot of the forummembers continues to surprise me.

Like I told Hans-Peter, I have not heard about a single case where C# developers move camp to Object Pascal (Delphi) language. The opposite seems much more popular. With saying that, I see no point in copying the C# syntax in the Object Pascal language.

Regards,
- Graeme -

I suspect the attraction of C# is because if you are developing for .NET it makes sense to use the language the evil empire uses or your employer requires you to use.
I rather doubt the reason anyone moves to a C dialect is due to the purity of the language syntax.

Lance

And that is why there are lots of sample code with C# declarations. It is argued that copying and pasting them is a fast way of getting the declarations in pascal. It is useful, if you don't have to re-arrange the declaration.

So that tell me, that there is NO point in copying the C# language syntax to a Object Pascal language - no developers move in that direction.

It is not about developers, it is about code.

Vincent

IMHO since some modifiers can have parameters, that is yet another kludge.

GPC uses [modifier1 arg1,modifier2] iirc, which is better.

I can't really imagine a realworld scenario here.

Lance Collins wrote

I suspect the attraction of C# is because if you are developing for .NET it makes sense to use the language the evil empire uses or your employer requires you to use.

Well that's certainly it. And going with the flow is certainly a factor there.

But I think adapting some shallow syntax here and there doesn't really bring you up to speed with that.

It's a bit like buying a pig instead of a horse, and then putting a saddle on top of it, and then claim handling the pig is so much easier because both have a saddle. Totally bypassing the fact that the pig is still no riding animal, and the saddle makes no sense on a pig.

However being different doesn't pay in corporate life, so people try to find the weirdest arguments to justify being similar, even if it doesn't have direct merit. It is just more easily marketable, but somehow people aren't willing to acknowledge that. (since that would mean admitting you are on the losing team)

I rather doubt the reason anyone moves to a C dialect is due to the purity of the language syntax.

I think if you are really sensitive to these kind of arguments, (or your boss is), it is time to stop kidding yourself, and go with the flow and adopt C#, VS and everything that goes with it (and also assume you are stuck to Windows, yes I know Mono. Nevertheless). It makes no sense trying to follow an alternate course and still try to blend in.

But adding some minor C# syntax to Delphi doesn't make it .NET or C#, and I don't buy the copy-paste argument either, since I can't see any regular practical case where this would be advantegeous. Specially since you still would have to fix up all other modifiers like calling convention.

It would mean integrating a full blown substitution based preprocessor.

But this is a sidetrack of the real problem: I don't see a real benefit in integrating a C compiler.

The main benefits of that one would only get when the C compiler becomes terribly advanced, something that I don't see happening anytime soon, and the position of 3rd party (non-system) C compilers on Unix is not terribly useful either.

Hmm, would updating and bugfixing h2pas not be an ideal project?

- there are several bugreports that could be a starting point.
- its relevant (parsing technology, C grammar)
- there is a severe need.

Marco van de Voort het geskryf:

It's a bit like buying a pig instead of a horse, and then putting a saddle on top of it, and then claim handling the pig is so much easier because both have a saddle. Totally bypassing the fact that the pig is still no riding animal, and the saddle makes no sense on a pig.

A very "visual" example! I still can't get the smile off my face. :-)

Regards,
- Graeme -

All that is done in the compiler front-end, AKA parser.

BTW, where do you see any C constructs that would require to extend the FPC compiler?

DoDi

Do you see points in inventing a different syntax, only for the sake of being different?

DoDi

As the one implemented in ToPas...

But this is a sidetrack of the real problem: I don't see a real benefit in integrating a C compiler.

Then you don't want to use any of the many C libraries, out there? Like lex, yacc, regexp, zip, SVN...

DoDi

Hans-Peter Diettrich het geskryf:

Do you see points in inventing a different syntax, only for the sake of being different?

No, only for being consistent with the reset of Object Pascal coding style.

Regards,
- Graeme -

The "only" is your emphasis, not mine.

But more importantly, if you really agree with this, we must really urgently put all modifiers and other information in front of the declaration. Since otherwise.... we could be different!

So the point is not the syntax, but the placing, and in similar cases we put it after. If it is put after you can at least say "It is like C# but everything is always after the declaration", while now it is "It is like C# if C# had it before Pascal added it and the date was 2009 or later, and after it otherwise".

So IMHO there is not even other syntax, just placing.

... and to answer the original question straight up: if something is added to Pascal, first it should fit with Pascal, and only then with other languages that sport totally different parsing models. Not the other way around.

Yes. And while I don't like that, if there is a real need, that can be escaped. I just don't see a real need.

We can already statically link to C code, so what exactly is the point? True, header converting is pain, but a blessing compared with the amount of work to maintain a fullblown C compiler.

Moreover it would be a feeble shade of a compiler to compile a handful of libs only, and you get tons of maintenance work in return. All the C parsing and implementation oddities, GCC compatibility issues, tools preparation ( autoconf etc), libraries etc.

It would probably always be 5 steps behind GCC anyway.

(preprocessing is never part of the parser, it's a separate compiler module or part of the, but this doesn't matter)

Just a simple example:

test.h:

#define POINTER(x) typedef T ## x* x
POINTER(float)

test.pas:

unit test;
interface
  {$I test.h}
  POINTER(longint)
implementation
end.

Does this compile? What is compiled into test.ppu? Can I do

unit test2;
  interface
    uses
      test;
    POINTER(string)
  implementation
end.
?

What extra work do you mean?

A compiler front-end translates the source code into an internal format, from which the back-end generates the executable code.

Moreover it would be a feeble shade of a compiler to compile a handful of libs only, and you get tons of maintenance work in return. All the C parsing and implementation oddities, GCC compatibility issues, tools preparation ( autoconf etc), libraries etc.

The ToPas C preprocessor and parser has been tested for MSVC and gcc compatibility. Configure is a problem on Windows; I used to configure C libraries on linux, then compiled the result on Windows. No further problems encountered so far.

DoDi

At least since C98 the preprocessor is part of the parser, due to macro expansion requirements.

A bunch of syntax errors here, because the Pascal preprocessor and parser does not understand C syntax.

POINTER(longint)

You missed the goal :-(

The C code is translated into separate ppu/o files, which can be added to the Uses clauses. Eventually a library unit or (package?) project can enumerate the types, constants, variables and functions of the C modules, which shall become available in other units. In the case of a library unit this unit can be added to the Uses of other Pascal units.

If you ever had used CBuilder, you would better understand how a compiler can compile modules of various languages, and create object files usable from all languages.

DoDi

There is no C98, only C89 and C99. Which one do you mean?

You missed the goal :-(

And you the point :) Such a compiler has to deal with *any* kind of ugly macro stuff not only of specially tailored code for this purpose. If this would be doable, it could be also done with h2pas, ToPas or whatever.

This works only because the headers are made for this purpose.

C# is already dead because it is tied to a propriety Java lookalike platform but with even more serious bloat. It will be out of fashion within the next decade. No matter how fast your hardware, native code will always be the faster option. If high connection cloud and web servers are the future then small footprint applications and fast execution of instances will never have previously been more important.

Okay so there is Mono but do you trust M$ not to take it out with a patent infringement lawsuit? Even if M$ were to ultimately lose the claim, the legal fees would be prohibitive for Mono to defend. Do you want to put years of development effort into C# and dot net which could vanish in a second?

ASP.NET is a powerful technology under light loads but why anyone would use dot net on the desktop is beyond me. Are your desktop users in less developed countries than the US likely to be running the latest version of Windows and dot net? I do not think so.

Object Pascal will live on because Delphi and Lazarus are awesome technologies delivering human readable raw speed applications at a low level which cannot be matched for speed and power by any Just In Time CLR or interpreted languages.

Visual Basic was launched by M$ as a lightweight toy to allow non-professionals to go beyond their spreadsheet "applications". Then "serious" software vendors started developing in VB. Nonetheless M$ crapped on them all by discontinuing the native compiler. Now it is for Delphi and Lazarus to facilitate the engineers and accountants and whatever non IT professionals (and the IT houses also!) to write quality code. These applications will deliver high performance and yet will be easily understood by c++ purists and other career programmers.

As soon as C# goes out of fashion then because M$ only goes forward., there will be no backward compatibility...you have been warned!

FWIW: i'm aware of numerous Oberon coders that might find it nice to be able to do Oberon stuffs with FPC and offer their wares to a wider venue ;)

you cannot stop the lemmings ;) :P

on the contrary... it is about what the schools teach and they are all in the lemming camp :rolleyes: :? :(

The frontend, and making sure the generated code meets targets, survives testsuites, complies to standard (e.g. aliassing rules)

Parsing compatibility I assume. So it eats everything that could turn up in a gcc header? It eats the entire /usr/include on Linux?

Hans-Peter Diettrich wrote

The ToPas C preprocessor and parser has been tested for MSVC and gcc compatibility. Configure is a problem on Windows; I used to configure C libraries on linux, then compiled the result on Windows. No further problems encountered so far.

Sorry, maybe I missed somewhere but where is the link to "ToPas". Is it possible to look at it?

Best regards,
Paul Ishenin.

Sorry, maybe I missed somewhere but where is the link to "ToPas". Is it possible to look at it?

http://sourceforge.net/projects/topas/

For some strange reason the Download button now downloads the documentation only, not the source code.

DoDi

Try with that link http://sourceforge.net/projects/topas/files/

__________ Informaci?n de ESET NOD32 Antivirus, versi?n de la base de firmas de virus 4428 (20090916) __________

ESET NOD32 Antivirus ha comprobado este mensaje.

http://www.eset.com

<opens can of worms>
Perhaps a utf8 compiler supported string type?
</opens can of worms>

Regards,

Andrew Haines

Andrew Haines het geskryf:

<opens can of worms> Perhaps a utf8 compiler supported string type? </opens can of worms>

It's always nice to day dream. ;-)

Regards,
- Graeme -