Agreed. A gestalt system is handy for keeping track of extensions, but where are the extensions? And where will they be specified, if not in a future revision of the Z-Machine Standards Document for which we’d increment the standard number anyway? For example, Glulx’s gestalt codes are listed in the Glulx spec and used to test for the presence of optional features which are also described in the spec. If you have Z-machine extensions in mind, like the transcript submission feature, why not wait until you can put those in the spec too?
One extension which has proved useful on Glulx, and may also be useful on Z-code, is veneer acceleration. Z has opcodes for low-level object manipulation, but Inform games have still become increasingly reliant on veneer routines for property access and bounds checking.
Thanks, will change that. For the 1.0 spec should I reference the inform 6 site, graham’s site, or the archive?
I would be expecting those requesting a selector and opcode to both have a solid implementation planned, as well as being economical in the opcode use. I for example plan to use a single opcode for all of my future Parchment experiments. And if things get in very dire straights, then we could start specifying sub-opcodes: set one unused opcode to EXT_LONG, have it’s first operand be the subopcode, and the remaining operands be the arguments for that. We’d then have another 2^16 extra opcodes if needed.
It’s important to fully document what has actually been done. You can see this in the new HTML5 spec, which documents the previously unknown errors that browsers make. Similarly, I’d want to document all of the unofficial extensions that people have made, even if they’re not any real use anymore. It’s important because if some new extension is highly popular we don’t want to exclude Zoom for supporting it because it already has a custom opcode of that value. Instead we document what Zoom has, and ensure that any new extensions will use unique opcodes. Just like the original 1.0 standard really… there’s a whole lot of useless stuff there, some of it only relevant for one game or one interpreter, but it’s still been documented.
They can be specified wherever, and I’ll refer to them in the registry (which I’ll be keeping up to date.) Just like how FyreVM is referenced in the Glulx spec. There isn’t really any need for Zarf to keep incrementing the Glulx version. I guess the version number is more for interpreters than the code itself, as it means interpreters can go “there’s no way I can support enough of what this game needs so I just won’t try.” With the gestalt system anything could have a work around, but a too high version number means writing work arounds would have been too much work.
Agreed, although I’m also interested in trying pattern matching.
I agree, in principle – I could just use gestalt from here on out. I’ve been bumping the minor version number (which doesn’t affect any terp or game behavior), and I plan to keep doing that. For debugging, is the only real reason.
Does anyone know of any other extensions out there in the wild? I’ve checked Frotz, Nitfol, Gnusto (obviously), Zplet, ZLR and ZMPP and haven’t found any yet.
If there is going to be a 1.2 release, is there interest in correcting/clarifying sticking points from 1.1? In implementing my interpreter I’ve found a couple of issues that I think would be good to fix in the standard (including one clear defect); I imagine other interpreter authors have run into issues as well.
Well, I think multiple attempts at updating the standard would be more of a problem than letting slide a few issues, so I don’t figure there’s much point, especially since the issue I’ve run across aren’t exactly earth-shattering.
The defect was that output streams 3 and 4 are listed as V5+ in the 1.1 standard (1.0 is self-contradictory on this point), but many Infocom stories that are V3 and V4 made use of stream 3 and/or 4. This doesn’t affect interpreters because they (at least the ones whose source I’ve looked at) don’t bother doing the version check. The only reason I found out about this defect is because I did do a version check, and Trinity failed almost immediately.
I would love to see an updated, unified standard instead of separate documents that correct each other.
Another defect in 1.0 that comes to mind: section 6.4.1 says V4 has a maximum of 3 routine arguments, but V4 defines @call_vs2 which allows 7 arguments.
This might be a bit of jumping the gun to comment on this as my first post, but I have something I want to bring up. I’m currently about 80% done implementing a Z-machine, which is about the extent of my background.
Over all the idea of this seems pretty sound, but I think that the use of a number to ID the different extension to the interpreter has the potential for trouble.
One thing I’ve seen in the world is that this sort of thing can cause problems really quickly, especially if they catch on. Not only do you need to officiate the ‘official’ selector codes you have to worry about unofficial ones. While the spec does allow for a range of private codes the odds are pretty good that any private extension will have a 50/50 chance of using $F000 instead of a random number. Collisions in this space can and will cause a problems.
So, if I might make a different suggestion. Why not try using a string. It’s not much harder to do then anything numbers, it could eithor follow the same embedding rules as @print and @print_ret with the optional argument before the embedded string or be a paddr to the string. The upshot of this is you can use something like mime types or URIs to ID the extensions, which can be be descriptive and lower the chance of collisions (I would also suggest lower case string comparisons).
For example you could have things like:
Standard Version: “Standard-Version” “uri://curiousdannii.github.com/if/zspec12.html”
Transcript: “Transcript-Protocol” “uri://curiousdannii.github.com/if/transcripts.html”
Zoom: “Zoom-Profiling” “uri://www.logicalshift.co.uk/unix/zoom/Profiling”
Zoom: “Zoom-StackDump” “uri://www.logicalshift.co.uk/unix/zoom/StackDump”
Private: “X-Whatever” “url://whatever.com/”
I have some other thoughts on the interpreter number, but as that’s not part of your proposal I’ll wait on that.
Thanks for your comments. While we could use strings instead, I don’t think the overhead would be worth it. For both the Z-Machine and Glulx there have been so few extensions made that I wouldn’t expect this to be a common problem - I don’t really expect it to catch on. The age of javascript interpreters may change that, but we would also expect custom interpreters to be locked to playing only certain files.
Having the whole specification in a Wiki would be a step forward: that might allow more effective updating. Note that I’m not volunteeing to do this, though…
vaporware’s Infocom documentation explains where the “previous font” wording came from, and zarf’s proposed behavior makes the most logical sense.
If I were updating Glk Frotz today, I would change @set_font 0 to do nothing and return the current font. Fortunately I have the luxury of time and can wait to see what ends up in the spec.
I’ve updated the draft with my position on this issue, which is effectively that the 1.2 standard is orthogonal to any clarifications of the 1.0/1.1 specs. It would be wonderful to have them, but I don’t think this spec is the appropriate place for them (as they won’t depend on @gestalt) and I’m not up to writing those clarifications either.
