[Mono-list] Mixing languages within

George Birbilis George Birbilis" <birbilis@kagi.com
Fri, 17 Dec 2004 17:14:45 +0200

see CodeDOM in the MSDN/.NET documentation, might give you some ideas

e.g. have in C# special comments embedded with your HSPL language or 
something like that (in C++ its maybe easier since the preprocessor allow 
you to do that without using comments, but some HSPL(hsplCommandString) 
macro). Then have C# compiler emit CodeDOM, then patch that CodeDOM tree 
where needed with the code generated from your HSPL commands (e.g. if they 
were comments you'd look at the tree for all comments and if they were 
special you'd remove them and add the corresponding code from your HSPL 

or something like that...

George Birbilis (birbilis@kagi.com)

> Of course, If you want to get really nuts :P,
> you should probably be able to create a compiler that has plugins from
> different languages and do something like this....
> namespace {
>   language C-Sharp {
>   }
>   language VisualBasic {
>   }
> }
> I mean... but then you would be really creating a new language anyway...
> Inless you could find out a way to pass the specific language functions to
> the appropriate compiler...
> I mean thats if you just want to be really crazy!!! :)
>>> I don't know what the .Net standard would have to
>>> say about this....
>>> I would like to mix C# and (say) Hypothetical String
>>> Processing Language
>>> (HSPL) and (say) Hypothetical Data Processing
>>> Language (HDPL) within the
>>> same source code file. e.g.
>> <snip>
>>> Is this a crazy idea?
>> I think so.  I'm not sure what someone else might say,
>> but my problem with this is that every compiler would
>> have to know about every other compiler and there
>> would have to be some standard for how to shift around
>> from one compiler to the next and pass type / symbol
>> information and IL code around as well.
>> I don't think it's feasible, and I'm pretty sure it's
>> not even close to being supported by the standard.  I
>> doubt it's prohibited directly by the standard
>> (because, after all, you could argue that this
>> wouldn't be C#, but some variant of C# and so wouldn't
>> be bound by the standard at all), but I surely
>> wouldn't want to try to build the compiler for it.