intfiction.org

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.

Does anyone else have any comments? Is it time to publish this properly?

Can we add a clarification about @set_font 0?

Hmm. I'd rather not really. If it's not something that requires the version to be set to 1.2 it shouldn't be there.

There is probably a need for a document listing futher classifications than what 1.1 provided. Perhaps a page on the IF wiki?

We could also have a selector to explain what an interpreter would do for @set_font 0, but I doubt that'd really be very useful.

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...

It should be in some version of the specification. If we're not going to change the old versions retroactively, then it should be in the new version.

Has consensus even been reached on @set_font?

Nope.

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.

http://curiousdannii.github.com/if/zspec12.html