What is the governing philosophy regarding changes to Inform 6?

I have noticed that on several occasions in recent years the question has come up about how to address various issues in the Inform 6 compiler and the Standard Library 6.12. In some cases, changes are made to the compiler. In others, changes are made to the library. In some cases, backwards compatibility with pre-existing code is deemed the highest priority, but compliance with the DM4’s explicit and implicit specifications also seems to be judged important. It seems likely that there are other values informing these decisions, as well.

Is there any formal articulation of the values involved here and their relative priorities, or is it always an ad hoc decision? If there is a formal articulation, is it public?

2 Likes

I’m not aware of any sort of formal process regarding Inform 6. My approach since I took custody of the Standard Library is to always preserve backward compatibility.

For what it’s worth, I think that a DM5 is long overdue.

7 Likes

The library and compiler are separate projects, obviously.

I think I’ve talked about my philosophy for the compiler before, but I can’t find the post. Basically, it’s like this, most important first:

  • The compiler shouldn’t ever crash.
  • Fix code generation bugs where the generated code doesn’t work at all.
  • Backwards compatibility. If possible, old source code should compile exactly the same game file as before. (Ignoring the serial number, etc.)
  • Fix code generation bugs where the generated code doesn’t follow the language spec.
  • Add features to support more VM features and more flexible game file generation. (E.g. new opcodes, static arrays.)
  • Add optional new language features.
  • Improve the “UI” of the compiler – features that don’t affect generated code. (Improved command-line options, speed, information display, etc.)
  • Deprecate and remove existing compiler features that are causing problems. (I haven’t done this yet but I have some proposals up; see https://github.com/DavidKinder/Inform6/issues .)

There are of course plenty of judgement calls here. There have been cases where the generated code didn’t follow the DM4 language spec and I said “Let’s fix that”; there have been cases where I said “Let’s document that the DM4 is wrong.”

I’ve also fixed some code generation bugs that made old source code not compile the same. (But I thought long and hard about those cases.)

When I think about these questions, I’m looking at how much code is affected (both compiler code and game code!), how far back the problem goes, whether the compiler behavior is internally consistent… lots of stuff.

Now, that’s looking only at the compiler (and DM4 chapters 1-7, 38-45). When you bring in the library it gets more complicated. This is what gets back to the “Z-machine dictionary alignment” thread.

My view on the library takes into account that:

  • The compiler has to support several different libraries now, including Puny and Metro.
  • Historically, the I6 library has never tried to maintain perfect backwards compatibility. (It tries to be pretty good but you have to read the release notes when changing library versions in your game.)
  • There was a long period (roughly 2004-2012) when the I6 library was completely unmaintained and static.
  • I’m not a library maintainer.
3 Likes

My question was general in nature, so as to better understand the perspective of the maintainers. Thank you for your in-depth response, zarf. Hopefully, I’m not the only person who will benefit from it. (Perhaps @DavidK would like to chime in, as well.)

I don’t have anything to add beyond Zarf’s very comprehensive answer. :grinning: