Michael Melvin wrote: > So...anybody up for porting an xTalk compiler to a REALBasic plugin? We Well, I'm not up for writing the plugin myself, but I had a vision for an xTalk which will address this issue. Here's the basic premise. Since the xTalk language is so close to the way I think it my head I spent little to no time translating from my thoughts to my program. I realized that this is probably xTalks single most powerful feature, and was wondering if you could create an xTalk which actually supported multiple languages. Out of that came the idea of separating out the syntax in which a particular command is expressed from the actual command itself. Java Bytecodes do this same thing. (There is an Ada->Java compiler as a demonstration). MetaCard also seems to support some sort of "compilation" to speed up execution. So the idea has already been proven, just not implemented to the degree that I am talking from what I've seen. So the end result is: English->MetaLanguage Spanish->MetaLanguage C->MetaLanguage Perl->MetaLanguage Once we have this MetaLanguage defined we can then add back end plugins. MetaLanguage->x86 MetaLanguage->PlamPilot MetaLanguage->French (no reason we couldn't go back up) MetaLanguage->RealBasic In my search for this MetaLanguage I realized that two primary already existing candidates would be Java Bytecodes (which I have pretty much ruled out), and the GCC internal representation, which I don't completely understand but has all the components. So in the end the code for our stack gets saved as the GCC internal representation, and the engine becomes an interpreter for the GCC internal rep. We then can add new players on the project easily by providing documents on how to add new frontends and backends and looking for people who are talanted with the GCC compiler. The extra benefit is that anyone who wants to use OpenCard has the ability to port any application that was written in a language we have a frontend for. -- Michael --
