[Mono-list] Re: Should I fork the MonoBASIC project out of MCS?

[Kunle Odutola]

> -----Original Message-----
> From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]On
> Behalf Of Miguel de Icaza
> Sent: 13 February 2002 21:55
> To: A Rafael D Teixeira
> Cc: Ravi Pratap M; mono-list@ximian.com
> Subject: [Mono-list] Re: Should I fork the MonoBASIC project out of MCS?
>
>
> Hello!
>
> > Do you think it is better to abandon our previous design of a single
> > executable capable of compiling many sintaxes? I´ve already
> merged MonoBASIC
> > code with the Feb-10 snapshot and it is working, albeit still
> lacking true
> > MonoBASIC compiling.
>
> It is funny that you bring this up, because I just fired you an e-mail
> about this precise subject.  For the sake of those reading the mailing
> list, I believe that having two compilers share the current driver will
> not work.
>
> Visual Basic and C# have vastly different semantic analysis
> requirements, and different ways of generating code, so at this point I
> am very skeptical of using the C# code base as the VB compiler code
> base.

Disagree. The VB.NET language (which MonoBASIC is designed to compile) is
*almost* C# with a VB-derived syntax. I suspect that that there is a great
deal more similarity once you get past the lexer/scanner than there are
differences. If we were talking about earlier versions of VB, you [probably]
would be right.

What sort of differences in semantic analysis have you encountered or
foreseen that strongly suggest splitting the compilers?. I haven't looked at
mcs in detail for a while but there is a great deal of value in having a
framework that allows for multiple compiler front-ends to share an
increasingly sophisticated back-end. Or back-ends, in due course...

It reduces the TTM for adding new languages to Mono. Perhaps, what is needed
is a re-factoring of msc to have explicit interface for plugging in
different implementations of pretty much everything. This should cater for
extensions/implementations that are compiled into mcs.exe as well as those
supplied as stand-alone or external assemblies.

Kunle