AW: [mono-vb] Future of Mono's VB.NET

Jochen Wezel - CompuMaster GmbH jwezel at
Sat Apr 22 11:39:50 EDT 2006

Hello Miguel and Rafael,

I like this idea :)
>From my point of view, it sounds great to me since it gives the opportunity to benefit from the gmcs work. And there has been and will be lot of work as I can see.

(But I'm not a guy who is able to make recommendations in the compiler area, this level is too high for me. Here, the compiler gurus (e.g.: you! ;-) have to tell a word.)

Well, so far for my comments here.

-----Ursprüngliche Nachricht-----
Von: mono-vb-bounces at [mailto:mono-vb-bounces at] Im Auftrag von Miguel de Icaza
Gesendet: Donnerstag, 20. April 2006 15:52
An: mono-vb at
Betreff: [mono-vb] Future of Mono's VB.NET


    Yesterday I met with Rafael and we discussed a bit what we wanted to
do with Mono's VB compiler.   

    The situation is that today's VB compiler is based on a fork of mcs circa 2002.  And although some of the improvements to mcs made it into mbas, they were not all incorporated.

    To make things worse, the new VB.NET supports generics.   So we are
wondering whether it would not be a better idea to start a fresh fork from gmcs (along the same proposal that Jambunathan had a year or so
ago) and implement VB that way.  Lets call this effort "mbas2".

    The idea would be to go in chunks: we could integrate individual commits that were done to the old mbas tree, and determine one by one whether it applies to mbas2.

    Maybe not all of the code can be salvaged, but if we can get even 40% of the old code migrated into the new tree it would be a big plus.

    Now, this might be insane, because once I was talking to someone on the VB.NET team and when I told them how mbas was written he said "I did
not think that VB.NET could be implemented that way".   Maybe our
approach is completely busted, but I do not know enough about VB.NET to know.  I just know that if the original mbas idea made sense, we should probably start from scratch.

    Now, since we are already too close to 1.2, we should probably develop this on a separate tree, to avoid breaking the build of "mono/mcs", so it should be another top level module in the Mono repository.  And we should probably also kill "mcs/bmcs" (at least we could retrieve the few patches that were done there).

Mono-vb mailing list
Mono-vb at

More information about the Mono-vb mailing list