[Mono-devel-list] Pascal compiler?

[Willibald Krenn]

Grant Hess schrieb:
> Other than the fact that I don't know what the Delphi.net extensions to 
> the language spec are, I'd love to begin on this. 

I'll dig into this - basically I think foreach is in, attributes of course and 
new visibility identifiers. Then there are co-classes, namespaces (multiple ones 
per unit, not just dotted unit names AFAIK) and lack of pointers IIRC (and 
absolute keyword).
Finally some changes to language semantics, as the unit finalizer might not run 
in case e.g. C# code is using the Delphi.NET code; Destructors are implemented 
via IDisposable; IIRC also the interface inheritance is sane now (I could be wrong)
Completely new are unicode identifiers support (expect for published properties) 
and Delphi will get generics in the NET 2.0 timeframe. (Some small generics 
additions might find their way back to Delphi.Win32 according to Mr. Thorpe.)
Oh, and thanks to .NET, Delphi now has operator overloading.

BTW: String[i] := "X"; doesn't work anymore IIRC.

  I've spent almost 10
> years working in Delphi (well, I did start with Turbo Pascal 8) ) and 
> would love to see it available in an open platform.

I too started with Turbo Vision - but more on a hobbyist approach. (I'm just 
finishing my thesis, so no great work experience there.. *g*)

>> We have four possiblities as I see it:
>>  1.> Implement from scratch with some compiler generator
> 
> This seems possible, but some Delphi features are more difficult to 
> describe in a parser generator than just building directly in a 
> recursive decent.

RD also tends to be faster; Downside is the maintenance AFAIK.

> 
>>  2.> Implement from scratch (based on the recursive descend parser 
>> from above)
> 
> I have built (not production quality, unfortunately) several different 
> rd parsers for pascal and variants over the years.  I agree it is a 
> fairly simple process.  One thing that looks promising for this route is 
> the fact that the object oriented design paradigm has matured greatly 
> since the last time I tried this. (Or maybe I've just learned how to use 
> it better? 8)  )

Well, I haven't got that much experience in writing parsers or compilers, except 
for some prototype parser and some exercices.
The RD Parser I mentioned is very simple: Just a bunch of static methods that 
eat tokens and that's it.

BTW: The nice thing about automatic parser generators is that you get error 
recovery, which is a bit tough to implement in RD. The question is 'do we need 
it?' If we want to support some compile-while-type of thing or want to print out 
a list of errors, I fear we do.


  I
> think that we would be better off in picking just one single (specific) 
> language definition and working with it exclusively.  Perhaps we could 
> expand compatibility to other flavors of pascal later, once we have an 
> actual working implementation.

Absolutely agreed - let's get some subset of Borland Delphi to compile first..
Afterwards we can still see if we want to support i++ ;-)

>>  4.> Take (g)mcs and make it understand Delphi
> 
> I would love to be able to leverage all of the talent that has been used 
> to make the mcs and gmcs compilers.  Even if we could merge a new parser 
> onto the gmcs back-end it would simplify the task greatly.
> Furthermore, the optimization work being done on the gmcs compiler is a 
> great attention getter for me.

I have to agree: "Don't re-invent the wheel."

So how do we start? Do we need a mono svn module, or do we work off-site e.g 
sourceforge?

I guess we agree on C# as programming language, so we do not need another 
Delphi.NET compiler for bootstrapping (though we need very good unit tests then) 
and probably can reuse existing utilities for the C# and VB(?) compilers.

Willi