When you use block value types (indexed text etc) the code a phrase produces is actually placed in a SHELL function, with the head rule function instead being used to initialise the block value and close it down when finished.

It would be useful to be able to do this with other functions. I am having a look at refactoring Flexible Windows, as it is very slow because every time you change a window it runs a bunch of code. If we could use the same sort of stuff as block values do, then the window configuring could run once, accounting for several changes at once.

Similar to invocation phrases, I suggest the following syntax:

To foo: ...

To foo -- initialising: ...
To foo -- finalising: ...

If multiple to foo phrases are used in one rule, they would collectively only run the initialising and finalising code once.

The existing manuals do not qualify as reference manuals, and will never do so, as they are not even intended to do so. The well-hidden syntax document is a start, but does not actually give specifications for half the syntax elements, and does not explain the semantic restrictions.

As a programmer who is extremely picky and perfectionist, I found myself having to learn the language partly by reading the source code (in three languages -- I6, I7, C), and partly by fighting with the IDE as it rejected constructions which appeared perfectly valid from the syntax documents and the "manuals".

My longest struggle was figuring out that (a) there was simply no such thing as an asymmetric relationship between one X and one Y, and (b) there was also no way to directly create a new object-valued field on an object, despite the syntax suggesting that both were possible. Once I figured out what was legal, I could work around it, but the restrictions were undocumented.

That's not cool. It's extremely off-putting. This is a language with great potential, but it's essentially undocumented. The writing which has gone into the existing 'manual' is really intro-book stuff, no good at all as a reference work. The examples are certainly useful, but the rest of it is completely worthless, since it doesn't provide enough information to differentiate between semantically *or* syntatically valid and invalid sentences.

A basic reference manual targeted at programmers could be written pretty quickly by someone who actually understood what was going on, and it would save huge amounts of aggravation. This should be considered a separate (and easier) project from the "intro" book "Writing with Inform"; reference manuals and tutorials are not the same in any way.

Or at least make it possible as an option. The fact that it isn't appears to be a piece of special-casing deep in the hardwired Inform 6 scope routines. (As it is, scope search goes down into the players contents, and goes up to the room, and goes down from the room, but the *room itself is deleted from scope* for some reason.) Actually, I think those were hard-wired in Inform 6 -- are those scope routines written in C?

Well, anyway, it turns out to be incredibly hard to work around this oddity in the scoping rules: you have to reimplement *all* of the lighting and accessibility rules to figure out whether the room "should be" in scope, and you have to do it individually for each actor. I found a shortcut (and put it in an extension which I'll toss out for beta testing sometime) but it's ugly.

Anyway, I expect fixing this would require a lot of low-level work, but it would sure help clean things up.

It would be useful to allow phrases to be defined which would cast between values, for example:

To decide what indexed text is (file - an external file): ...

Such a phrase wouldn't have any non-variant text. Alternatively, and to make clear that it is a special phrase, it could be worded like this:

To cast an external file to indexed text: ...

To prevent headaches the compiler should not use more than one conversion at a time. That may not be enough to prevent headaches... perhaps the compiler should also complain if reciprocal casting phrases are defined? I don't know if that would help.

Parsing should respect the semantics of the library actions.

When only one item out of the candidates is valid (according to the semantics of the action) then it is unnecessary to request disambiguation. E.g opening a door when only one door is closed.

In 6G60 here are some fixes I found, (desiderata: use the most unlikely likelihood so users can override)

[why not "opening a closed thing: it is likely"?
a closed thing can be unopenable so it isn't necessarily possible that the player can open it
]
Does the player mean opening an open thing: it is very unlikely.
Does the player mean closing a closed thing: it is very unlikely.
Does the player mean opening an unopenable thing: it is very unlikely.
Does the player mean closing an unopenable thing: it is very unlikely.
[prefer open things to locked things - opening a locked thing gives a failure message]
[prefer locked things to open things (unlikely vs very unlikely) - informative]
Does the player mean opening a locked thing: It is unlikely.
Does the player mean closing a locked thing: It is unlikely.

[a thing must be open AND enterable to enter - but users should be able to override]
[Does the player mean entering an open enterable thing: It is very likely.]
Does the player mean entering a locked thing: It is unlikely.
Does the player mean entering a closed thing: It is very unlikely.
Does the player mean entering a not enterable thing: it is very unlikely.

[case of holding x-y and wearing z-y: should wear x-y but default asks for disambiguation]
Does the player mean wearing something worn by the player: It is very unlikely.
Does the player mean wearing something not worn by the player: It is likely.

[handle case of holding x-y and wearing z-y: should take off z-y but default asks for disambiguation]
Does the player mean taking off something worn by the player: It is likely.
Does the player mean taking off something not worn by the player: It is very unlikely.

Does the player mean inserting into a closed container: It is very unlikely.
Does the player mean inserting into a locked container: It is unlikely.

Does the player mean taking something worn by the player: It is unlikely.

[Does the player mean locking something locked with something: It is unlikely.
Lock doesn't seem to poll rules before disambiguation. Use a custom verb or an extension.
]

This is an issue of very minor import, but Inform presently accepts commands of the following form:

>take A, B, C
>take A and B, C
>take A, B and C
>take A and B and C

but not

>take A, B, and C

which tries to look for an object called "and C" and cuts off the whole action with "You can't see any such thing."

As Andrew Plotkin points out, this has been around for twenty years without anybody complaining about it, and it took a fairly unusual game to make the issue arise at all. Still, there are legitimate differences about the correct way to punctuate lists, I7 allows the serial comma in other contexts, and this issue is obscure enough that players are unlikely to remember which form is the correct one.

I don't think that authors can add this functionality without using I6. (See http://www.intfiction.org/forum/viewtopic.php?f=7&t=5209 ).