Future of Mono's VB.NET

Hello,

> Let me put another possibility on the table. Why not
base the new
> VB.NET compiler on the Boo infrastructure?
> 
> This would not require a fork at all but improvements
and refactorings
> to a shared code base on a ongoing basis. There are
already two
> languages based on the infrastructure (boo itself and
the scripting
> language for the Unity Game Engine - UnityScript).
> 
> I'd love to see that collaborative development
happening.

But isn't Boo still missing generics support?

It just feels to me that VB.NET and C# are close enough that
a compiler
forked from gmcs is probably easier to do than reusing Boo,
specially
considering the generic components.

Rafael did mention this Boo proposal, but I do not know
enough about the
internals of Boo or what Boo exposes that would make this
easier.

Finally, the other downside is that integrating the patches
from mbas
into a new fork is mostly a straightforward task, while
basing it on Boo
sounds like writing code from scratch.

Miguel.
_______________________________________________
Mono-vb mailing list
Mono-vblists.ximian.com
http
://lists.ximian.com/mailman/listinfo/mono-vb

On 4/20/06, Miguel de Icaza <miguelnovell.com> wrote:
> Hello,
>
> > Let me put another possibility on the table. Why
not base the new
> > VB.NET compiler on the Boo infrastructure?
> >
> > This would not require a fork at all but
improvements and refactorings
> > to a shared code base on a ongoing basis. There
are already two
> > languages based on the infrastructure (boo itself
and the scripting
> > language for the Unity Game Engine - UnityScript).
> >
> > I'd love to see that collaborative development
happening.
>
> But isn't Boo still missing generics support?
>

Not for long 

> It just feels to me that VB.NET and C# are close enough
that a compiler
> forked from gmcs is probably easier to do than reusing
Boo, specially
> considering the generic components.
>

Well, Boo was already described as a mix of VB.NET and C# by
some.

We need a different parser in any case. Just by integrating
this new
parser into the boo pipeline would get us a long way. In
fact Daniel
Grunwald integrated the #develop VB.NET parser into boo some
time ago
so it's possible to write some kind of VB code already with
boo. The
semantic differences were not implemented but that would be
the same
work for boo or gmcs with one nice difference: we would be
sharing
code!

> Rafael did mention this Boo proposal, but I do not know
enough about the
> internals of Boo or what Boo exposes that would make
this easier.
>

Boo architecture is open enough so you can plug different
parsers,
different type system rules, overloading resolution schemes
and such.
Don't get me wrong it would still take a lot of work to get
that
openess to a point where we will say: beatiful! But
collaboration can
certainly gets us there and it looks like a fun ride from
where I
stand.

> Finally, the other downside is that integrating the
patches from mbas
> into a new fork is mostly a straightforward task, while
basing it on Boo
> sounds like writing code from scratch.
>

Forking is generally a dead-end for code sharing. That's
what happened
to mbas. That's what will eventually happen to mbas2 I
guess. At some
point the two versions just diverge so much that the gap
just gets too
scary.

What will it be, the blue pill or the red pill? 
Rodrigo
_______________________________________________
Mono-vb mailing list
Mono-vblists.ximian.com
http
://lists.ximian.com/mailman/listinfo/mono-vb