Make the template layer available for browsing from within the IDE. Minimally, this might mean making the Reserved extensions folder available from within the Extensions menu (probably with a different name, e.g. Templates). More useful would be an Index pane or special documentation page listing the templates and the order in which they are compiled (if this is straightforward). Links from this index could take us to the i6t file and to each template file's documentation (i.e. the docs currently available only in the Appendix A and B pdfs). If the goal is to hide the template layer from most users, perhaps an option in the preferences would be appropriate?

Currently the only way to define a kind of action is to give an example of it; e.g. "Looking is acting fast."

It would be convenient to allow a kind of action to be defined directly, by "Acting fast is a kind of action." This would be especially convenient for extensions that define a kind that may or may not be populated by the authors that use it--for instance, an extension might want to write rules for "acting fast" in case the author wanted to define any actions as acting fast, without forcing any particular action to count as acting fast.

As the author of a number of multimedia extensions for I7, I've heard from a couple of users asking whether there is a briefer way to assign figure names to image files. As I'm working on a WIP that currently has well more than 100 defined figures, I understand why they'd want that. The standard syntax works well for a handful of figures, but there is a lot of extraneous typing when the number of figures goes beyond that. Would it be possible to allow figures (and perhaps sounds) to be defined using special-purpose tables? A simple Table of Figures or Table of Sound Files, with just 2 columns to fill in (figure/sound name and file reference), would be efficient and simple to fill in. A dollop of whipped cream on top of this would be if it were unnecessary to write "Figure of" for each figure-name, this instead being added by Inform when the table is processed.

The current game banner looks like

Release 1 / Serial number 160227 / Inform 7 build 6M62 (I6/v6.33 lib 6/12N) SD

The parenthesized part is boilerplate and conveys nothing useful even for deep I6-hacker types (like me).

- The I6 compiler is packaged with I7 and will not change, unless someone deliberately upgrades it in place -- which is likely to be a bug-fix update that does not change the "6.33" version label. (Yes, I've done this, and no, I didn't touch the label.)

- "6/12N" is hardcoded in the template layer and dates from the era when we thought that the I6 library would be updated in parallel with I7 as a separate project. That never happened, so the "6/12N" is a fossil.

If we knock that stuff out, we're left with

Release 1 / Serial number 160227 / Inform 7 build 6M62 SD

...which is all we want. (Release and SN belong to the game; "Inform 7" is the language; "6M62" is critical info for any I7 bug report; "SD" indicates that it's a debug build, which should always be visible.)

Names of kinds of values can grow to arbitrary length, and it can become tiresome to type them out over and over when working with code that makes heavy use of some particular complex KOV. Therefore, being able to introduce shorter aliases would be useful. It could look something like this:

A sequence transform denotes a phrase list of numbers -> list of numbers.
A number grid denotes a list of lists of numbers.

That's a fairly simple macro system. Slightly more useful would be if we could make generic aliases:

A sequence denotes a list of numbers.
A K transform denotes a phrase K -> K.
A K grid denotes a list of lists of K.

The only complication I can see is that we might need a way to specify plural forms as well. That could perhaps be done as a parenthetical remark after the singular form.

I have projects that are no longer in the history file of Inform. I have associated story.ni files with Inform, but all that happens is the Inform welcome screen appears. So there is no real file association with Inform.

After selecting “Open an existing project” when I move to the folder where the story.ni file is, the list remains blank. Even if I type in the file name (story.ni), Inform will do nothing to open the project. (That is, when I click on Open, *nothing* happens. It doesn’t open the file, it gives no error message, it doesn’t close. It just sits there as if I had not done anything at all.)

Expansion of the rules model to allow rules to act on multiple,
typed parameters, as in:

Reaction rule for a powder (called reagent A) with a powder (called
reagent B): ...

To combine (reagent A - a powder) with (reagent B - a powder):
consider the reaction rules with reagent A as the first component
and reagent B as the second component.

(The original proposal is laid out in more detail at
http://groups.google.com/group/rec.arts.int-fiction/msg/964587315d0702b4).
It is undeniable that the main "decision mechanisms" provided by Inform -
phrases, properties, rulebooks, actions - nearly meet at the edges, and
that as their capabilities increase they overlap. Here we are looking at
the border-line between phrases and rulebooks. The introduction of rulebook
variables in 2007 moved these closer together, because it meant that the
collective rules of a rulebook could share "local variables" like those of
the definition of a phrase. This new proposal would move the two concepts
closer together still: it would allow a rulebook to have a general kind
(K1, K2, ..., Kn) --> K - assuming that we are also allowed to make the
outcome of a rulebook a value of any general kind. At present, only a
phrase can behave like that.

More flexibility in how the parser copes with object names given
the instruction to "Understand the foo property as describing a bar", where
foo contains an enumerated kind of value. At present this only allows the
property to be given at the beginning of the object name, like an English
adjective. This is fine for colours and temperatures, but fails in some
other cases, for example a "can of cola" or "glass of lemonade" where cola
and lemonade are elements of a "flavour" kind of value.

One approach is to make flavor a kind of thing instead, and use a relation
to parse the name: "can of [something related by flavoring]". However, this
way we lose the other effect of the understand-property-as-describing
syntax, which is distinguishing identical objects. Cans filled with
different flavors will be collapsed into a single inventory listing, and
the parser will arbitrarily choose one rather than disambiguating, even
though they can be distinguished by typing.

The proposer suggested four possible improvements in this area:

(1) Allow the understood property value to appear anywhere in the
object name, not just at the beginning.

(2) Add an activity, or some other mechanism, for customizing the way
objects are distinguished. Running an activity for every call to
Identical() could be a performance problem, but it might be enough
simply to add a way to tell Inform that members of kind K are
distinguished by properties P and Q, even when those properties can't
or shouldn't be parsed as part of the object name.

(3) Allow the "[something related by X]" syntax to work with relations
between objects and values, not just between objects.

(4) Allow the understand-property-as-describing syntax to work with
object properties, not just values.

(3) and (4) seem entirely reasonable. With (2), the performance problems
are indeed horrible in general, but the issue here seems to be to
distinguish objects related to different things, and it may just be that
Inform needs to compile cleverer "parse_name" routines. (1) is something we
are very reluctant to do, again for run-time speed reasons, but also
because it would make object name parsing much more ambiguous and
complicated. To sum up, we accept the general point that something needs
to be done here, and will experiment.