I brought up the idea of transferring @Marvin’s (David Fillmore) Github repository for working on the Z-machine Standard to the IFTF’s Github account. I then PMed him about this specifically and he’s okay with it. How should this proceed?
6 Likes
(We are talking about https://github.com/DFillmore/Z-Machine-Standard.)
To be clear, transferring the repository over doesn’t mean someone will start working on it. Looks like Marvin did a burst of edits in summer of 2019; nothing since. I see a small list of issues filed by Dannii, CAS, and Fredrikr.
Correct. That’s the repository I mean.
My intent was to 1) place custody of the Z-machine Standard under the IFTF and 2) work on it. There are a bunch of issues and pulls that could be easily settled but for @marvin’s lack of time to attend to them. Lately @Player701 provided impetus to do more work on the Standard by pointing out a bunch of ambiguities and raised unanswered questions about what a proper Z-machine ought to be doing (Z-machine standard: unclear aspects/ambiguities)
1 Like
It would be great to move some of that stuff forward, but I would want to see a group of people discussing the issues and reaching consensus before changes are pushed. E.g. the last few posts in that thread.
(To be clear, not me. I don’t know nearly enough about Z-code trivia.)
1 Like
I will try to get something moving on this issue this weekend. I have a vague memory that one of the last things I did to the Standard in my repository was to substantially rewrite a section to try to make it clearer, and instead made it worse. So I should look at reverting that before any transferring happens.
Thanks!
Is this what you mean?
Maybe this also should be done with the already commited changes?
Is this gonna emerge in a The Z-Machine Standards Document, version 1.2 or version 1.1 with a new date (current date is “24 February 2014”, here).
I don’t know. What do people think we need?
I’d like us to get explicit approval for each change from the current Z-Machine stable interpreter maintainers. Ideally unanimous decisions, but potentially just a quorum if it’s not an important question. (We’re nowhere near either for a version 1.2, so for now it would just be updates to 1.0 and 1.1. Though maintaining two sets of standards is extra work. I’m not sure why we can’t just move to one standard, clearly marking which parts are for version 1.1.)
(Approval from people currently writing interpreters would be good too, but I think it’s most important to get the approval of the maintainers of the interpreters that are actually being regularly used to play games right now.)
We should update Praxix for each change, so I propose moving it’s home to the repo. Actually I’d also like to remove all the visual tests from Praxix so that it can be entirely and easily automatically tested. Then it would be helpful to have another test for visual things. (Or multiple tests perhaps, doesn’t really all need to be in one.)
1 Like
So, I never considered the documents on github to be official, they’re a work in progress that needs approval. The current version of the Standard is the one at The Z-Machine Standards Document: Contents not the one on github.
I think that any change to the documentation which is just fixing errors or clarifying behaviour should just result in edited versions of 1.0 and 1.1. That is, if it’s behaviour which is known and accepted, but the Standard is wrong or unclear, update the current Standards. Any behaviour which is currently unspecified ought to remain unspecified until some theoretical future version of the Standard (1.2, presumably).
2 Likes
Version 1.2 should be for behaviour you can’t expect in a 1.1 interpreter.
Minor vaguenesses and inconsistencies should just be edited into the spec if we can agree on what the best option is.
If there’s anything that the stakeholders can’t agree on, then the competing interpretations should both be mentioned (in the notes rather than the spec), which basically turns that part of the functionality into a “do not use”.
In other words, I think my main disagreement with David is that I’d say if everyone agrees, we should still clarify things that are currently unspecified. That will just make it easier for people in the future.
Makes sense to me. (“Current” meaning “we can get hold of them to discuss it”, obviously.)
I maintain that page. I’m happy to update it when there’s a concensus about it.
I don’t think there should be any editing of the 1.0 or 1.1 standards. If there is something “wrong” in them, correcting those things is for 1.2. Or perhaps append a letter (1.2a, 1.0b, etc) or another decimal point (1.0.1, 1.2.3, etc) for the benefit of, say, students implementing interpreters from scratch; who for whatever reason might not want to make their interpreters compliant with the latest standard.
Maybe there’s not enough to call it 1.2 but I absolutely think there should be a revision number that distinguishes different iterations of the standard
That’s what the date is for.
That’s not a use case I think we should cater for.
“1.1 dated Sept 2023”?
That confirms my suspicion of it being a Bad Thing to edit an already-released Standard. That use case was the best justification I could come up with for it to be a Good Thing.
Nothing’s stopping someone who wants to intentionally implement an old, unclear, buggy, and incomplete specification. But I don’t think we should go out of our way to support that use case. If that’s not what you meant, then could you explain more?
If the standard was rigid enough in the first place, then we could consider how we might want to freeze it in place. But it’s been an incomplete work in progress from the beginning.