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

Kunle Odutola kunle.odutola@virgin.net
Fri, 15 Feb 2002 04:45:40 -0000


Hi Miguel,

> > 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.
>
> The semantic rules are going to be different, and I am not planning on
> having millions of:
>
> 	if (this_is_vb)
> 		...
> 	else
> 		...
>
> In the code, that just makes the code ugly and unmaintainable.  And
> whenever there is a difference, you will pay a high price for keeping
> the compatibility.

This is just a code refactoring issue Miguel, isn't it?.

> Again, the MCS goals, are very similar to Gnumeric: maintainability
> comes first.  Performance comes later.

Code refactoring coupled with judicious application of flexible design
patterns should allow us to have both in this particular scenario.

> > 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...
>
> With the CIL there is not much of a backend.  Specially considering that
> we will be writing a CIL optimizer that will perform optimizations on a
> CIL .EXE image independently of what compiler was used to generate the
> code.
>
> The CIL defines where the front-end has to stop.  And there is no moving
> there really.

Your analysis is right of course for current state of affairs. But, if mcs
supports many languages (and easy addition of others) and it's design is
clean/extensible enough, some enterprising soul might just step up to the
challenge.....perhaps a native executable code generator (perhaps by reusing
gcc's back end only)?

Kunle