This weekend I knocked over some I6 compiler improvements that have been requested for a while. (Some were implemented a few years ago in a development tree that fell by the wayside.)
I’ve been filing detailed bug reports on the Inform bug site; you can follow them there.
These would come out as an “Inform 6.33” release, not yet scheduled. Currently the patches exist only in my I6 github tree. They have not yet been adopted into David Kinder’s master repository. So now is a good time to comment if I’ve done anything dumb. (Say, used the wrong opcode to implement “font off”. Cough. Oops.)
- An #Undef directive to cause a previously defined constant (only) to become undefined.
What it says.
- Extend the action statement to support <action arg1 arg2, actor>
This supports frotz’s effort to have the I6 library support NPC actions. The idea is that an I6 game author can write code like <Take pie, orc> to invoke an action on an NPC rather than the player. (Note that I just implemented the syntax, not the result! If you try to use this with the current I6 library, the actor argument (orc) will be silently ignored.)
(Yeah, it would have been nicer to support <orc, Take pie>. I couldn’t get it to parse reliably. Sorry.)
- Stop using the fixed-pitch header bit in font on/off
In Z-code V5 and up, the “font off/on” statement will use the @set_font opcode instead of tweaking bit 2 of the header. (Font 4 for “font off”, 1 for “font on”.) If you stack font and style changes, this change may cause slight difference in display behavior on some interpreters. I caught Mac Zoom behaving differently in one case; not Gargoyle or Parchment, though.
- Extended Replace directive: “Replace new old”
This is an idea I had years ago. If you add a second argument to the Replace directive, the function you’re replacing is preserved under the new name. This lets you replace an I6 library function but still invoke the old functionality. It’s like a simplistic form of I7’s “Before/after foo activity: …” Not sure if it’ll really be useful, but there it is.
The #End directive in a #Included file should only terminate that file
After messing with this one, I’m considering throwing it out. The #End directive is pretty useless as it stands (it stops compilation dead, like end-of-file). But it wouldn’t be a lot more useful to be able to jump out of an #include file. I mean, I’ve never wanted to.
It occurred to me that a likely idiom for using this would be
But to handle that, we’d have to declare that the directive terminates the open #ifdef – otherwise it would stay around until the end of the program, and confuse everything. But that brings up all sorts of other issues about open #ifdefs. (Do they all get resolved at the end of the include file? Can an include file #endif an open #ifdef from the parent?) It turns into a headache. I say if you want to not compile a chunk of code, #ifdef it out, don’t try to make use of this #end thing.