What sort of changes would you like to see made to the Z-Machine standard? Please vote in this poll so that we can see what the community would find helpful. You can select as many options as you like. And if you think there’s another category of changes, please suggest it too. (Though I think changing the poll will invalidate the existing votes, so we probably can’t do that unless the suggestions are made before too many people have voted.)
Fix typos
Fix obvious errors
Clarify ambiguities when all or almost all interpreters agree
Note conflicting & incompatible understandings of the spec
Resolve incompatible understandings (ie, turn some interpretations into violations)
Hello anonymous second voter! I must admit I find the idea of clarifying ambiguities but not fixing typos or obvious errors a confusing position! If that’s not what you meant you should be able to change your vote, or you can write a comment to explain, but feel free to stay anonymous if you prefer. (Even as forum admin I don’t see who votes, and I won’t go searching the DB to find out. Your privacy remains secure!)
Yes, I’d assume that if the spec is in source control, casual readers or people not really involved in the project could just send in typo fixes whenever.
New features seem rather low priority. Having programmed z-machine games for a while, I can’t see what else is to be added besides maybe a save to data file feature!
I may be confused about what a standard is, then … part of the problem may too be that I took it to mean “something standard and visible to programmers, or with clear examples in Inform 7.” This may be off-base, and I may be tangled up in bad definitions.
Is that really necessary though? The optional operands to allow saving data files are part of the standard, so claiming 1.0 or 1.1 (for the optional prompt operand) compliance in the header should be sufficient to determine existence. If it isn’t, then the standard revision in the header isn’t being respected and the interpreters are not compliant.
Edit: Sorry, I wasn’t referring to new features but rather the existence of saving to a data file.
I would say the existence of support in Inform is not relevant to the z-machine standard itself. There can be other ways of creating story files besides Inform.
Edit: Think of it this way - Inform is a programming language/compiler/libraries. The z-machine standard defines the underlying “hardware”. The underlying machine may support things the software doesn’t (…yet).
Yeah, the Standard isn’t about what I7 makes convenient, but about what interpreters make possible. In theory anything the Standard allows can be exposed to Inform via extensions, but if it’s not in the Standard, you can’t assume an interpreter will handle it correctly.
Of course, many interpreters don’t fully match the Standard, but that’s a separate problem.
For those who don’t know the standard, perhaps linking the actual document (and GitHub repository, where people can suggest edits) would provide more context:
One thing not mentioned in the survey is consistency of terminology. I haven’t looked at the standard for a while, but I seem to recall that it used different terms for the same thing and that made it confusing. Perhaps there should be a glossary of terms.
Regarding new features, what new features? Wouldn’t that be z9?
We can add new features to current z-code versions as long as they’re backwards compatible. We only need a new version if we want to change how already existing features work. Either way, this should be in a new version of the Standard (1.2, 2.0 or something) rather than added to version 1.1.