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

[Jambunathan K]

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
lost.

The compiler regression script written in perl may be used for automated
regression for the future implementation.

Regards,
Jambunathan K.


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
> refactored.
>
> 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
> failed.)
>
> 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.
>
>
> Cheers,
> 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...
URL: http://lists.ximian.com/pipermail/mono-vb/attachments/20060429/d946d0b1/attachment-0001.html