I6 compiler - Sean Barrett's varying text modification

A conversation on twitter between Sean Barrett and Jon Ingold revealed something I did not know about: Sean Barrett authored in 1999 a modification of the I6 compiler adding what he called “varying strings”, which allowed to write I6 statements like:

print “The man {%whistles|smiles at you expectantly|scratches his head}.”;

The statements between brackets are alternative fragments of texts that can be displayed either randomly (prefacing with %), in order, cycling (&), or randomly with no repeat (!) compared to the previous statement. This can create very quickly and easily variations of the text, which helps in making the game not repeat itself.

This is, of course, very similar to functionalities in Inform 7 (“One of”) and Ink. Jon Ingold says used this modification extensively in some of his games, and it made him aware how nice cheap text substitution was; Ingold also says he authored the code behind the “one of” feature of I7 inspired by the modification by Barrett.

The Barrett modification hasn’t seen the light of day, because the I6 compiler license explicitly prohibited distribution of modified version, and Barrett did not get an answer from Graham Nelson about that back in the day. He distributed it to a few people back then, but it’s never been integrated in the I6 compiler; now that the I6 compiler has changed its license, Barrett made the source code available.

I would like to propose to integrate it into the Inform 6 compiler. This functionality seems very interesting for Inform 6 (it is a beloved feature in Inform 7 and Ink, after all); moreover, the code is basically already written. Some things to consider:

  • The modification is for the Inform 6.21 compiler, which means some adaptation or careful treading would be needed to replicate this in 6.34;
  • It is for the Z-Machine version of the compiler (not the bi-platform or Glulx one);
  • The modifications are relatively minor (200 lines in states.c, an extra function in header, an extra array in arrays.c, basically) and are prefaced by #Ifdef statements. I would probably need someone who is more familiar with the current compiler code to look at it and confirm.

Would the maintainers of the I6 compiler mind? (The I6 compiler is mostly used as a tool for I7 if I recall, so anything that modifies it would potentially affect them if problems occur)
What channel is best to discuss this? (this thread, a mantis issue, a github issue?)


I can just speak on the I6 Library, but I like this.

1 Like

This is interesting! I must have taken a look at it when it was released (twenty years ago), but I don’t remember it at all.

I have mixed reactions but (TLDR) I’m generally against including this in the Inform 6 compiler.

High-level reactions:

I6 still gets some use as a user-level language (ie, distinct from its use as an I7 back-end). But not very much. This means that new user-level features aren’t really going to get shaken down and tested quickly. With a major new feature like this, it’s hard to tell whether the design is really solid or sufficient for real-world use. It might take a couple of compiler releases to hammer that out, and that means years at the present rate of I6 use and update.

I don’t think that’s good for the language or the software. My feeling is, if you want fancy high-level features like this, write your own markup language and a tool to generate I6 code from it as part of your build process.


This syntax inducts { as a special character in printed strings, which is an enormous breaking change in the language. It would be better to work off the standard I6 string escape character, @. Perhaps "@<foo|bar>" would work. (But I haven’t verified that that would be compatible with the existing language.)

You’d also want a way to escape the special characters | ! % & inside the variant list. @@124, etc, might suffice; you’d have to test that.

I’m also wary of hard-coding functionality into the compiler like this. This patch has four variant behaviors; adding more requires both a language change (new prefix character) and a compiler change (new generated code). In comparison, I7 has seven behaviors, and an author can add more with a bit of (I6-level) coding effort.

A more general feature might look like "@<xyz:foo|bar>", where the compiler invokes a textvariation_xyz() routine, defined either in the veneer or in user code.

1 Like

Mind you, it would be totally fine if someone updated the patch to fit the current I6 code and made it available as a Git fork.

If it got significant use, I could change my mind about merging the change in. (Subject to the syntax nitpicks above! :)

Thanks for the replies!

Zarf, I understand (and that’s why I asked). The code wasn’t released but disseminated; the testing it got was from the author and Jon Ingold, I assume.
I understand your point about the fact it’s not going to be tested very much. (And when you say “maybe if it gets some use”… well… absolute or relative numbers? :slight_smile: )

I like your @<xyz:foo|bar> syntax suggestion. It’d require more work, but it seems more general and more legible. Could we technically envision doing something like " @<prefix:foo|bar> -> call the PrefixVaryingStrings function on foo and bar", with the function defined in a piece of library code? That would make things more extensible.

I’ll try to fork the compiler and integrate the code, and we’ll see about the rest I guess.

I checked my email records. I see that in 2004, Roger Firth pointed out the http://nothings.org/games/if/ page and the “Varying Strings” mod in particular. This was in the context of having a “inform6/compiler/patches” directory on the IF Archive.

My position was that it would have been fine (and not abusive to the old I6 license) if nothings had uploaded his code as a patch (diff). It didn’t wind up happening, though.

1 Like

I managed to port the modifications to the latest version of the compiler without too much trouble. The fork is here, for anyone interested ; however, for now it is Z-Machine only.

The Glulx version should be coming soon, I’m just stuck on replacing calls like assemblez_2_to(loadw_zc, ... (and add_zc, mod_zc, and assemblez_2_branch, assemblez_3…) to their proper Glulx equivalent. Might have to dive in other parts of the code to understand how it works…

1 Like

Suggestion for its *nix name ? :wink:

I currently have:

inf615 inform inform55
inf634 inform52 inform6

(plus inform54 under dosbox…)

I’m toward infsb634; Suggestions ?

Best regards from Italy,
dott. Piergiorgio.

When you run it, it lists itself as “Inform 6.21v” (or “Inform 6.34v” for the updated version).

I suppose if we’re considering it a fork of the language, it should be “Inform/v 6.34” or some such variant. I don’t have a strong opinion though.

Oops, forgot to change that too! I like Informvs, Inform 6vs, or infvs, for varying strings (the name of the internal constant), personally.

Did this ever make its way to the IF Archive?

I never did post it because I didn’t catch up with the latest version of the compiler and I couldn’t make it work for Glulx compatibility. I tried finding the appropriate Glulx replacements for code that generated Z-Machine assembly but didn’t go far (not an expert of the internals). Sorry!

What about Barrett’s original version – does anyone know if that has been uploaded? I searched the full list of entries at the IF Archive but didn’t find anything that looked like it (i.e. nothing including “inform_varying” in the name).

I haven’t personally. Probably not a bad idea! The direct link in my first post still works.

I don’t see it up there either.

I have submitted the ZIP file (inform_varying.zip). I’ll post back with a link to the location once it has been processed.

The IF Archive has processed the submission. The final location of the ZIP file containing the code and instructions is: https://ifarchive.org/if-archive/infocom/compilers/inform6/source/patches/inform621_varying.zip