[Mono-devel-list] Re: [mono-vb] VB.NET Compiler - Regarding

[Rafael Teixeira]

Hi Jambunathan,

First, I've missed you in the last weeks, I'm happy you came back.

Second, You've been reading my mind, don't you... I was thinking of
doing just that. Since Marco Ridoni made some huge contributions,
years ago, I could not keep mbas in sync with mcs, what I had done
after the fork for some months...

Well, mbas was forked so that mcs development would not be hampered,
but I still think they can share a lot of code. I would prefer that
logic to be shared as libraries but certainly Miguel prefers the
current 'single-piece' design for mcs, so maybe we could use them as
netmodules, or just shared source, for the time being.

Another possibilties I am studying: 
- using the boo compiler pipeline with a VB.NET parser.
- advance current mbas to a better stage, and then see what can be
refactored/componentized between it and mcs.

Anyway, I would love to see your bmcs code (BTW I would prefer a name
like mvb for such experiment).

Have you already tackled the case-insensitive-symbol-resolution issue?
It's surely something that should be componentized (made pluggable -
strategy design pattern) , as the parser/tokenizer currently are in
mbas.

Best wishes for you too,
-- 
Rafael "Monoman" Teixeira
---------------------------------------
I'm trying to become a "Rosh Gadol" before my own eyes. 
See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment.

On Wed, 5 Jan 2005 17:29:42 +0530, Jambunathan K
<kjambunathan.devel at gmail.com> wrote:
> Hello All
> 
> As you might be knowing, I had been contributing to mono's VB.NET
> compiler for a brief period of time (in my capacity as an employee of
> Novell)
> 
> Now that I am no more bound with Novell, I am one among the whole lot
> of you involved with Mono.
> 
> Over the Christmas week, during some spare time, I had been spending
> some time building a VB.NET compiler out from the then mcs-HEAD. I am
> calling this new mcs derivative as bmcs ('a pun on gmcs').
> 
> I have essentially replaced C#'s tokenizer and parser (cs-tokenizer.cs
> & cs-parser.jay) with the mbas' tokenizer and parser (mb-tokenizer.cs
> & mb-tokenizer.jay) and I have got to a point where I can compile some
> simple, but not so trivial 'VB.NET programs'. I plan to evolve the
> current C# core towards a VB.NET core by liberally borrowing from the
> curent mbas code.
> 
> Here are e a few strong reasons why I indulged in such an experiment:
> 
> The current mbas code branched off from mcs sometime in 2001-2002.
> This essentially leaves the "compiler core" as an alpha quality one.
> Also two years is too much of a time that the code bases have diverged
> significantly.
> 
> As I see, during the last two years, the VB.NET compiler code has
> essentially evolved on two fronts: 1) Merging patches or features from
> the mcs core which was added to mcs since the mbas fork 2) Introducing
> VB.NET specific semantics.
> 
> With the new approach 1) the effort spent on (1) gets reduced
> significantly 2) The trees could be get in sync so that pulling in
> partial classes or generics supoort in feature would be relatively a
> simple task. 3) It opens up possibility of a single mammoth code base
> that can be built to either C# compiler (mcs/gmcs) or VB.NET compiler
> (bmcs). Or atleast it will show up avenues for building a reusable
> code emission library from the current compiler for building new .NET
> langauge compilers.
> 
> I would be spending some time pampering this new beast. It is going to
> be essentially a night job and develop in bits and pieces.
> 
> If the community sees a value in this experiment and (IS interested in
> co-operatuing with me) I am willing to get in a new subdir mcs/bmcs in
> to svn.
> 
> Otherwise I can privately nurture my efforts and release it to the
> community once it is a sufficiently evolved.
> 
> I invite views from the community. (I would be particularly happy to
> hear from anyone who is willing to co-opearte with this effort of
> mine.)
> 
> With best wishes for the new year 2005,
> Jambunathan K.