I make use of -ue to auto-abbrev-compress my text a little for punyinform files. It saves a noticeable amount, but it also spews a large amount of text after the stats and errors (which makes sense, as the combination of text with objects is the last step). This blows away my scrollback buffers and I can’t get back to the stats report or the warnings.
I’d love a quieter version of this feature, even if it has to write the report of the abbreviations to a temp file.
There’s no way now to make use of Glulx’s functions in strings feature is there? (Other than manually encoding the whole string.) What if a string escape was added for functions?
inform -ue doesn’t make your story file shorter.
inform -u prints a report ending with suggestions for 64 Abbrev-commands you could include in your source. If you copy these 64 lines and paste them into your source (at the top of the file), you can then compile with -e to actually make use of these abbreviations.
I typically use -u every once in a while (typically just before a release), and -e every time I compile.
Aha! that explains a lot, then. Thanks!
If you’re using PunyInform, the library already has 64 abbreviations built-in, which are chosen based on the text in the library only. To tell the library that you’ve added your own abbreviations, you must also define the constant CUSTOM_ABBREVIATIONS.
The standard library doesn’t come with abbreviations.
Leaving aside the question of when to use -u (as fredrik says, you use it once in a while to determine the best Abbreviations list for your current game text):
It would make sense to omit the “Pass…” and “Selection…” lines. Nobody looks at them unless they’re debugging the optimizer algorithm. (Which I might need to do someday, but nobody does it regularly.)
Having regularly bent C language to my will, I disagree with you. 
This explains why I was confused: -e gave me a clear compression win! I’ve left -u off in my normal builds, and will have another look when I get toward release-making.
If -u could take a file-name to write the new abbreviations to, then the story file could include this file and there wouldn’t be a need to manually update the abbreviations list.
I don’t know how much this relies upon the compiler vs. the library, but can we please have inline format codes for changing the colour &c.? I’m specifically thinking of 8-bit systems, I wouldn’t recommend using colour on releases for modern systems. Let’s say that a developer wants to colour the active nouns in a sentence a different colour on the C64. Right now this would be laborious in the extreme and bloats the amount of z-code generated because we can’t just print_ret a single string and walk away.
If the z-code print routine were expanded to include colour format codes then whilst it would make the print routine larger, there would be many more savings anywhere a string needs to change colour (potentially every room description).
IMHO, this is exactly the sort of thing that should be handled by an extension, and there is one:
http://mirror.ifarchive.org/if-archive/infocom/compilers/inform6/library/contributions/znsi.h
It has the limitation that you have to allocate a buffer large enough to hold the biggest string you will use this for. And there’s no way for the library to check if you made the buffer large enough - if you haven’t, you will get a buffer overrun, corrupting other game data.
If you would implement this in the Inform 6 library, this would still be true.
If you implemented it in the compiler, you could split up the string into smaller parts, interspersed with commands to set the text colour. This would have two undesirable effects though: Printing a string like this to memory (a nifty trick which often comes in handy and is necessary for string manipulation) loses the formatting, and each print statement would end up taking up more bytes in the compiled file. So, it would still have its drawbacks.
Adding to what fredrik said:
The underlying fact is that the Z-machine cannot change styles/colors in the middle of a print operation. This means that, to get what you want, you have to break the print statement up into shorter strings.
I6 has a flexible syntax for this:
print "This is a ", (color) RED, (object) noun, (color) BLACK, ".^";
Since you’re defining the color() routine, it can do anything you want, and this covers lots more cases than color-changing.
You could imagine a more compact syntax – maybe something more like I7. But it would generate the same Z-code. It’s not very tempting to add a major new language feature for so little benefit.
This is ultimately what I needed to know, thanks! If it’s simply not possible to do as part of the compiler’s code-gen / z-code, then I’ll have to use routines / extensions.
David has just merged a substantial change which adds warnings about type errors in I6 code.
The idea is that if you define attr as an attribute and prop as a property, the compiler will now display warnings for mistakes like:
give obj prop;
obj.attr = 5;
move obj to prop;
(This was originally suggested by @fredrik – thanks!)
These are compile-time warnings, so they can only check declared symbols. Property/attribute values in variables are not checked. If you write
x = attr;
return obj.x;
…the compiler isn’t smart enough to see the problem. It also can’t do any checks if the property/attribute hasn’t been declared yet.
See https://github.com/DavidKinder/Inform6/pull/104 for a full description of the warnings.
I’ve tested this compiler against the 6/11 library, Puny 1.6, and last year’s release of Metro84. It doesn’t produce any spurious warnings in those cases. However, it would be helpful if it got some broader testing. If you’re doing something which you think is valid I6 code, but now generates a compiler warning, I’d like to take a look at it.
Thanks!
What did you use for testing against the 6/11 library?
Advent.inf. Plus a couple of other tiny test cases.
I’ll check that with the 6.12.x line and report back.
Very good, thanks.
Advent.inf looks fine with 6.12.5.
I haven’t been worrying about I7 code (since the code generated by I7 produces thousands of warnings anyhow).
But it turns out that this change doesn’t add any new warnings for a (one-line) I7 game. So that’s nice. In fact it gets rid of one spurious warning.