I'm just curious, does there exist descriptions for the various SVN branches (purpose, maintainer, state)?

Florian has offered me an new branch, for my parser etc. projects, but he seems to be very busy right now. So I'll present a roadmap of my activities, all around the parser and compiler:

1. New machine documentation
In an attempt to strip down a physical machine to the minimum requirements, I've already created a no_cpu machine (based on M68K units), and started to document the requirements. An early (FPC 2.4) version of this project can be found in lazarus/examples/parser/, but it (the new trunk version) should be moved into the FPC SVN - into compiler/ or an add-on/contributions folder.

2. Preprocessor
The stand-alone preprocessor code ($PreprocWrite, commandline option -m) does not compile since a long time. I could it make work again, and already supplied the according patch in Mantis.

3. Parser
I have a couple of ideas, how the compiler and parser could be made more flexible, extensible and (possibly) more performant. In an first step I try to become more familiar with the parser and the parser/compiler framework. For that purpose I try to separate the syntactical and semantical actions in the current pareser, by moving the semantical part into subroutines. Later these subroutines can be moved into a dedicated directory, or into include files, so that they can be exchanged like currently machines can be exchanged, by adding their unit or include directory to the searchpath. The functionality of the existing code is *not* affected by this separation, but perhaps some improvements or cleanup (of pending todo's) may find their way into the trunk as well.

This separation allows to reuse or extend the OPL parser/compiler in further projects, *without* affecting the FPC code any more. A first project may result in an (Lazarus) component, that allows to use the *original* FPC OPL parser in other projects, as was the wish of several FPC/Lazarus users.

Further projects could implement additional front-ends for FPC, for other Wirthian languages (ISO-Pascal, Modula, Oberon...). These front-ends only have to produce the same data structures as the OPL parser does, so that the existing optimizers and machine code generators can be used for the remaining stuff. My primary goal is the use of the improved syntax of these languages, so that e.g. the choice of the Modula syntax could stop the endless debates about the formatting of begin-end blocks in source code. The use of the different semantics, e.g. the garbage-collector in Oberon, or the implementation of the according standard libraries, is beyond my intentions - but as long according projects do not affect the existing FPC code, everybody can start such projects freely :-)

The possibility of addional front-ends could turn FPC into an playground for language designers of every kind, making FPC known to a much broader audience...

I for my part see a chance to even implement a C front-end for FPC, based on my ToPas code, see <http://sourceforge.net/projects/topas/>. This way it would be possible to overcome the need for header translations, for every target and after every new library release, and also the immediate use of C code snippets or libraries in FPC projects could become possible, without separate DLLs or other shared libraries.

Please let me know what you think about my ideas. I really would like to see the beforementioned syntax/semantics separation in the trunk, once I could implement it.

DoDi

Hans-Peter Diettrich wrote

I'm just curious, does there exist descriptions for the various SVN branches (purpose, maintainer, state)?

The commit messages (mainly the initial one).

The stand-alone preprocessor code ($PreprocWrite, commandline option -m) does not compile since a long time. I could it make work again, and already supplied the according patch in Mantis.

And as I replied in mantis two days ago,
a) that option is not documented in the help page because it never worked in the first place (I don't even know what its purpose is) b) the code for that option predates svn (it was written more than 10 years ago), which is why it's in trunk rather than in a separate branch c) even if that code merits fixing and enabling, the patch you submitted cannot be applied for several reasons (detailed in the mantis bug report)

Jonas

You simply could have tried, and looked at the output. It does what every preprocessor does, i.e. execute the preprocessor directives and output the remaining parts (except comments) of the source file.

b) the code for that option predates svn (it was written more than 10 years ago), which is why it's in trunk rather than in a separate branch

Why a branch for a simple function of the compiler?

c) even if that code merits fixing and enabling, the patch you submitted cannot be applied for several reasons (detailed in the mantis bug report)

I'm really stumped by your detailed "reasons" :-(

Citing from your reply on Mantis:

The -m option and -dpreprocrewrite has never worked.

Now it does - so what?

I'm not even sure what the purpose of that code is. What does it do?

What a preprocessor does: remove comments and excessive whitespace, include files and handle conditional directives. The remaining code is written to an file.

And what can the compiler do after this patch?

It can output the preprocessed file, instead of an object file. In that file one can see which code remains, after the conditionally excluded parts have been removed. Very helpful when complex nested conditions and defines are used.

This patch seems to do a lot more than simply fix an undocumented and never-finished command line parameter, and the comments you added

seem > to indicate that this code is far from finished (lots of question

marks and TODO comments as you also mention above).

The questions arose from the missing (detailed) description of the preprocessor. They are easy to answer, but deserve an consent about the correct answer (desired behaviour).

Also, adding a lot of commented-out code is not good practice, it

only > makes the code harder to read.

I've left the original code for the case that somebody wants to know more about my changes, before adding it permanently to the trunk.

This is not necessarily an improvement: - from the old Objects to the current Classes,

This is not an improvement, it simply is a requirement. If you had studied the code, or only had compared the old outcommented code with the new one, you had found out easily that the compiler nowadays uses Classes, where it used Objects in the time the preprocessor was written.

This is also wrong: fixes a scanner problem (# 10 never occurs on Windows?)

How can you decline? Have you debugged the code, as I did? :-(

Please look up the declaration of TPreProcFile, and find that it is enclosed in $IFDEF PREPROCWRITE. It consequently *is* related, and the "override" is not harmless, because a destructor without "override" is never called by Free. Please test yourself, if you don't believe me.

And it's not my fault that the preprocessor related parts are scattered accross multiple units, and that the scanner is also involved. I only made the preprocessor compile in a first step, and then fixed the remaining issues, that prevented it from working properly. Should I supply two or more patches, which only make sense when applied together?

I hope that you have another closer look at the code, and adjust your wrong assumptions.

Regards
DoDi

Hans-Peter Diettrich wrote

Further projects could implement additional front-ends for FPC, for other Wirthian languages (ISO-Pascal, Modula, Oberon...).

IMHO a lot more interesting than ISO-Pascal, Modula, Oberon:

What about Delphi-Prism on that behalf. ?

(This supposedly would be easier to make working using a .NET/MONO-code generating backend compiler than by attempting to reproduce the appropriate functionality <as far as viable such as "parallel"> in the RTL.)

-Michael

In our previous episode, Michael Schnell said:

What about Delphi-Prism on that behalf. ?

If it relies on GC (and afaik Oberon has the same problem), an RTL based on GC first has to be explored first, and the extend of the changes.

But more importantly, what would be the use of supporting Prism?

(This supposedly would be easier to make working using a .NET/MONO-code generating backend compiler than by attempting to reproduce the appropriate functionality <as far as viable such as "parallel"> in the RTL.)

If you want paralel, take vector pascal, and implement it in e.g. the FPC or objfpc dialect. Implementing the whole of Prism and its extensive baggage for just that is insane.

Feel free to implement a Pascal front-end for Mono :-)

But what development language would you use for that project?

Honestly, a .NET back-end is less useful than e.g. a Java back-end, and requires much work in the front-end for assembly compatibility ("uses"). Next a new debugger-interface is needed, and a VCL.NET. All in all a very new project, that can inherit almost nothing from the current FPC :-(

DoDi

Marco van de Voort wrote

But more importantly, what would be the use of supporting Prism?

Before bashing me: I don _not_ vote for starting this really huge project, but nonetheless I think it would be great to have.

(1) Delphi Prism adds a lot of interesting language constructs such as parallel execution. Of course with Prism this is done using the .NET infrastructure, but such things of course also can be implemented in the RTL so that a native compiler could handle it. (No comment regarding garbage collection etc, as this already was mentioned by the Hans-Peter regarding Oberon.)

(2) I feel that using .NET / Mono as an "architecture" to compile to, would be a great addition, too, and while it's not viable with the "native" Pascal dialect, Prism takes care of presenting the paradigms decently to the programmer.

If you want paralel, take vector pascal, and implement it in e.g. the FPC or objfpc dialect.

I suppose this is a good idea, even tough I suppose that the .Net "parallel" paradigm is a lot more broadly known than that of Vector Pascal. so Hans-Peter might want to add VP to his list. Moreover "parallel" only is one example of Prism "goodies" that might be great to have.

Implementing the whole of Prism and its extensive baggage for just that is insane.

Agreed. In fact I doubt that there will be enough manpower available in the community to start such a project with the hope to get Beta state in a decent amount of time.

-Michael

In our previous episode, Michael Schnell said:

On 07/12/2010 11:51 AM, Marco van de Voort wrote: > But more importantly, what would be the use of supporting Prism? Before bashing me: I don _not_ vote for starting this really huge project, but nonetheless I think it would be great to have.

It is not bashing. It is stimulating you to come up with something better than pointing at some isolated syntax like paralel as motivation to support an hugely complex framework that involves frontend, backend AND libraries.

The question is if the implementation even survived the move from a managed GCed environment to a native non-GC one.

But why? What does it make possible? What would you use it for in practice, that you can't use Prism+mono for?

(not the ideal case of "just press the button and recompile, and slap mono under it", but a realistic scenario, with incompatibilities, version lag etc, several years to implement, at which point Prism maybe already is canned)

Prism is not horrible expensive like Delphi, and can sometimes be had for $99.

Like what? As said, parallel is not really Prism specific. Nearly any significant language sooner or later had a port or branch that experimented, even Pascal (see vector pascal, a TP dialect based one).

So I still don't really have an idea why you would want it, and what you would do with it, except "nice goodies" as description and probably a liking for "method" instead of "procedure/function".

And then I'm not even speaking if it is doable and worth it, and just restricting myself to the WHY?

Marco van de Voort wrote

But why? What does it make possible? What would you use it for in practice, that you can't use Prism+mono for?

In fact the Prism Compiler is free - but not open source -, but to use the IDE and a component library you even not only need to use payed service by Embarcadero, but also you need to use the Microsoft Visual Studio.

I feel that Lazarus as an IDE and component library is more desirable than Visual Studio. AFAIK there is no version of the Prism compiler that runs on Linux or Mac.

Moreover I thinks it's viable to prefer open source tools

Like what? As said, parallel is not really Prism specific.

See "Compiler features" in e.g.
http://prismwiki.codegear.com/en/New_Features
http://prismwiki.codegear.com/en/New_Features#August_2009_Release_.283.0.21.29 http://prismwiki.codegear.com/en/New_Features#May_2009_Release_.283.0.19.29 http://prismwiki.codegear.com/en/New_Features#February_2009_Release_.283.0.17.29 http://prismwiki.codegear.com/en/New_Features#November_2008_Release_.283.0.15.29

So I still don't really have an idea why you would want it, and what you would do with it, except "nice goodies" as description and probably a liking for "method" instead of "procedure/function".

In fact I did not test anything of this - and don't have the need to do so - and of course anything can be coded with what we already have. But if we want to go on attracting application programmers we might need to support the C# and .Net - based features that they learned in schools.

-Michael

Snapshots were broken. Think this is now fixed.

The v2.5.1 and v2.4.3 snapshots for go32v2 and win32 should now be updated more or less daily again in /v25 and /v24 respectively, on the fpc ftp sites /pub/fpc/snapshot/.

Regards John

Please help Logica to respect the environment by not printing this email / Pour contribuer comme Logica au respect de l'environnement, merci de ne pas imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei, die Umwelt zu sch�tzen. / Por favor ajude a Logica a respeitar o ambiente nao imprimindo este correio electronico.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

It won't find its way into my primary list, because it requires according updates of the internal compiler data structures, RTL and more. We'll need a team of experts that works together on the definition and implementation of all the new features, in all affected parts of the compiler. Some refactoring of the existing compiler infrastructure may be required before this step, so that the further development can stay synchronized with the mainstream development and fixes. The syntax/semantics separation is a step towards this goal, that can be followed by another generalization of the semantical actions.

DoDi

I feel that Lazarus as an IDE and component library is more desirable than Visual Studio. AFAIK there is no version of the Prism compiler that runs on Linux or Mac.

A platform independent solution would implement the IDE, compiler etc. in .NET/Mono, so that it can be used immediately on every platform, that supports .NET. AFAIK Java development systems went the same way...

DoDi

Hi!

Hans-Peter Diettrich wrote

Honestly, a .NET back-end is less useful than e.g. a Java back-end, and requires much work in the front-end for assembly compatibility ("uses"). Next a new debugger-interface is needed, and a VCL.NET. All in all a very new project, that can inherit almost nothing from the current FPC :-(

Sorry for the OT, but why do you believe that a .NET backend is less useful than a Java one?

Both "environments" have a stack based intermediate language (.NET: CLR Java: Bytecode) and a class system resolving around a base object class type. Both use the concept of "namespaces" to identify classes (the .NET one is solely file name based while the Java one is directory and file based). Also the CLR is standardized while the Bytecode is not.

I personally don't think that neither one is really better, but I myself prefer .NET cause it was designed to be used by multiple languages (e.g. C#, Delphi Prism, F#, IronPython, etc).

Regards,
Sven

Java tries to be "write once, run everywhere", while .NET is more like "write in any language, as long as you run it at our operating system". Forget Mono, it's doomed to always play catch with Microsoft's implementation due to technical and legal issues.

2010/7/12 Sven Barth

Huh ? That would be the day ? AFAIK Java doesn't need .NET ? Why would it need .NET ? It's runtime engine works on more platforms than .NET/Mono...

I would even say more:
if Java depended on .NET, why would anyone bother with Java ?

Michael.

In our previous episode, Hans-Peter Diettrich said:

Not frontend, not backend, and not most of the libs indeed.

I think it would be more logical to add a Prism frontend to Mono.

They are already doing that:
http://blogs.remobjects.com/blogs/mh/2010/05/23/p1504

Luiz

Alexsander Rosa wrote on Mon, 12 Jul 2010:

Java tries to be "write once, run everywhere", while .NET is more like "write in any language, as long as you run it at our operating system". Forget Mono, it's doomed to always play catch with Microsoft's implementation due to technical and legal issues.

There are two "levels" of .NET: on the one hand you have the bytecode format (CIL = Common Interface Language), and on the other hand you have runtime and its frameworks frameworks (CLI = Common Language Infrastructure).

A ".NET backend" would mean generating CIL bytecode as far as the compiler is concerned. Conceptually, this would be not very different to generating, e.g., LLVM byte code. It's just an intermediate format that can be fed into other tools and either be used in a JIT environment, or be statically compiled down to machine code (there is e.g. a GCC frontend that reads CIL, and subsequently can in principle generate machine code for any architecture supported by GCC -- but before anyone gets any dreams: this would still also require at least some rudimentary support for that architecture in FPC).

The advantage of generating such an intermediate format is that it lets you take advantage of many tools that have been written by other people if you wish to do so.

Supporting the CLI (like Delpi.NET/Delphi Prism) would additionally require adding support for an extra "operating system" to the compiler and the RTL, namely the "CLI platform". It's this latter part where Mono is indeed generally about one generation behind the latest Microsoft version.

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

A .NET development system is typically built on top of .NET, a Java development system on top of Java.

FPC instead is not built on top of a single system, and supports more than a single target. That makes it different from beforementioned development systems.

The Delphi maintainers decided to restrict the development system to Windows, but plan to allow for multiple targets by cross-compilation (and remote debugging?) features (Delphi "X").

DoDi