[Mono-dev] C# source-to-source compiler
monoman at gmail.com
Thu Nov 4 08:02:16 EDT 2010
Plugins for compilers in the syntax tree part, aren't easy to make it work,
because the tree segments need to coalesce into a single consistent tree,
without cycles or disjoints segments.
That said, there is already a compiler for .NET/Mono that has a pipelined
design where you can add or substitute stages, it is the Boo compiler.
Also Boo already support Macros what make it easy to extend it's syntax,
without having to change the compiler itself.
Give it a look:
Rafael "Monoman" Teixeira
"We live in a world operated by science and technology. We have also
arranged things so that almost no one understands science and technology.
This is a prescription for disaster. We might get away with it for a while,
but sooner or later this combustible mixture of ignorance and power is going
to blow up in our faces."
On Thu, Nov 4, 2010 at 7:47 AM, jan jan <jve7gm at gmail.com> wrote:
> Hi Mark,
> This is interesting - I refer to these as 4GL's - in a nutshell, a compiler
> that generates code for another compiler, google it if u want; what I do
> find odd is the need for it as lots of ground breaking work went into the C#
> specification it's really as simple as you can get. Problem with them in the
> long run of history is they tend to assume and follow best-practice patterns
> which is not always suitable and lead to performance issues later on.
> You're better off writing your own parser/generator/plugins for whatever
> you're planning here. If you do have unique fundamental ideas for the
> language talk to the specification teams to see if they can include it in
> future; in knowing C# I can't possibly think of something at this time!
> Perhaps a plugin infrastructure for the C# compiler itself is not a bad
> idea? - Anyone? Why do IDE's have them but compiler's don't ? Geez ... and
> don't say we didn't think of it!!!
> On Thu, Nov 4, 2010 at 11:15 AM, Andreas Nahr <
> ClassDevelopment at a-softtech.com> wrote:
>> Hi Mark,
>> either I'm misunderstanding your idea or you are misunderstanding some of
>> the .Net architecture.
>> 1) C# has no own runtime library, it is practically a runtime-library-free
>> implementation on top of the CLR base class libraries/VM.
>> 2) I don't understand why you ever wanted to change the virtual machine in
>> your situation. IF the runtime support you need can even be expressed in
>> code (and that's what I'm understanding from your post) then there is
>> no need to modify the VM at all.
>> The next question is why you want a source-to-source compiler. It is the
>> usual and good practice to compile source to IL and I don't see any reason
>> why you shouldn't.
>> If you want to be your language an extention of C# why not just take one
>> existing C# Compiler (e.g. dmcs) and add the constructs you need?
>> Happy hacking
>> > -----Ursprüngliche Nachricht-----
>> > Von: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-
>> > bounces at lists.ximian.com] Im Auftrag von Mark Farnell
>> > Gesendet: Donnerstag, 4. November 2010 05:54
>> > An: mono-devel-list at lists.ximian.com
>> > Betreff: [Mono-dev] C# source-to-source compiler
>> > Hi,
>> > I plan to design a language based on an extention of C#, and I would
>> > like to use the mono compiler and abstract syntax tree.
>> > The language extension would require some runtime feature, which can
>> > be implemented by:
>> > - modifying the virtual machine, or
>> > - C# runtime library
>> > In the former case, it can be time consuming for me to navigate
>> > through the virtual machine.
>> > In the latter case, I would need a source to source compiler reading
>> > code written for the extended language and output pure C# code that
>> > links to my runtime library.
>> > For the latter option, I would like to modify the dmcs compiler to
>> > read the code written in the extended language and output pure C# code
>> > (rather than CIL bytecde).
>> > Is this possible? Are there other better ways?
>> > Thanks!
>> > Mark
>> > _______________________________________________
>> > Mono-devel-list mailing list
>> > Mono-devel-list at lists.ximian.com
>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list