[mono-vb] Future of Mono's VB.NET
kjambunathan.devel at gmail.com
Sat Apr 29 03:37:46 EDT 2006
To add to this:
The tests for VB.NET compiler regression is neither coherent nor complete.
It is only limitedly useful.
I had bunch of VB.NET files that I was targetting to compile (or not compile
successfully as the case may be) when I had worked on Expressions support in
bmcs. This was fairly comprehensive to cover a broad spectrum of scenarios.
For whatever reasons, I haven't gotten these in to svn and my workspace is
The compiler regression script written in perl may be used for automated
regression for the future implementation.
On 4/29/06, Jambunathan K <kjambunathan.devel at gmail.com> wrote:
> 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".
> Emotionally this appeals to me.
> The following items favor this proposal:
> 1. VB.NET is not "standardized". This is to our advantage for we can scope
> and define what mono's VB.NET will or will not support.
> We can leave out certain constructs like supporting error numbers or
> mapping error numbers to exceptions. Going down to the last detail as in
> retaining error numbers across vbc and mbas2 would be seriously detrimental
> to progress and should be avoided at all costs.
> In short, the implementation should be in spirit rather than in true
> literal sense.
> 2. We build on an existing infrastructure that is rock solid and
> equivalent if not better in power. Yet we are starting from scratch in that
> all C# compiler constructs will be passed through a "VB.NET" filter and
> In short we would be standing on giant's shoulders.
> 3. If we decide to go down this path, we need to go with surgical
> precision starting from expressions and working all the way up to higher
> semantic units like delegates. (This in my IMHO is where mbas had seriously
> In short it is a marathon and so it should be treated. Any desire for
> quick results would be against the rules of the game.
> 4. gmcs and mbas2 trees should be twins till such time as mbas2 relies on
> gmcs for borrowing major features. If gmcs is reasonably mature this would
> neither be a big overhead nor a major challenge.
> All 1-4 were the philosophy behind bmcs as it started as a fork of gmcs.
> I stuck to these principles for close to 3 months when I was comitting
> bottomline patches to the bmcs tree. This is refelected in the ChangeLogs.
> 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.
> Miguel as someone who has worked on mbas and who has personally worked and
> intreacted with Anirban (the then mbas owner) I can say with certainty that
> this would be an exercise that would not only be time consuming but would
> also be of little value add.
> Even if we decide to go down this path, we would miss nothing if we
> restrict the patches to those that were committed before Anirban took over.
> Neither am I a C# or VB.NET programmer (in the remotest sense) nor am I am
> compiler guru. I am making these observations as a practitioner and as
> someone who spared some sincere love over mbas/bmcs.
> Jambunathan K.
> On 4/20/06, Miguel de Icaza <miguel at novell.com> wrote:
> > Hey,
> > 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).
> > Miguel.
> > _______________________________________________
> > Mono-vb mailing list
> > Mono-vb at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-vb
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-vb