|
I've thought about this a bit... I7's rulebook nature seems like it'd be a good fit for the event-driven model that's common in GUI and network applications. It also has some features like relations (more specifically, the relative clause syntax for stringing together relations) that don't appear in mainstream languages, and it'd be interesting to see if those end up being widely applicable.
However, I7's current implementation is not well-suited for this. The I7 compiler is tightly coupled to I6, so if you want to turn I7 into machine code, probably Plan A would be to translate the I6 code to C, or patch the I6 compiler to generate LLVM code. I think it'd be impractical to translate it to Java, C#, or any other language with a strict type system. (Plan B would be to compile to Glulx as usual, then embed a Glulx interpreter into the finished program and come up with some way for it to shuffle requests between the VM and the native library, which would hurt performance but save you a ton of time. This is how Guncho works.)
The Inform library is another issue. Most of the "traditional" Inform library, the IF stuff, is not going to be useful for general-purpose apps and would need to be stripped out. The newer stuff that was added to support I7 features like rulebooks and heap values would still be useful, but for performance reasons you might want to reimplement a lot of it. For example, I7's memory manager is kind of wasteful and bizarre, and although its regular expression functionality is impressive for being written in I6, in a real app you'd want a fast, standard library like PCRE.
One more issue is I7's data structures. The ones it has are mostly fine for what they are: tables are like SQL tables, dynamic relations are typed hash tables, lists are typed vectors, indexed text is mutable strings. But there are no trees, linked lists, records/tuples, or even floating-point numbers (yet). The dynamic structures like lists are always copied by value, which is a huge restriction on their usefulness (not to mention wasteful). Objects and tables are the only ways to combine more than one data type in a single entity, but neither of them are dynamically allocated; my extensions address that problem, but only partly.
Also, unless your name is Graham Nelson, you'd have to make all these changes without touching the I7 source code. A lot of them can be done by editing the template files, but the compiler still generates a lot of I6 code programmatically, which puts constraints on how radical your changes to the template and runtime environment can be.
...
Actually, this suggests a Plan C: don't directly compile the generated I6 code, just treat it as an intermediate representation. Read everything I7 generates, including comments and the index, to reconstruct the type info that gets lost in translation to I6. Then generate new code based on what I7 already generated, but modify it as you go, rewriting snippets of code to fit your needs regarding performance, readability, types, memory model, linking to native code, etc. Benefits: you could work around nearly every problem above. Drawbacks: it's a lot of work and it breaks compatibility with low-level I7 extensions (though you likely wouldn't use those anyway).
|
Login
Register
FAQ
Search
Members
