Inform 7: Possible future developments -------------------------------------- Emily Short and Graham Nelson January 2007 1. Context On its release in April 2006, Inform 7 was described as a "public beta". It had been tested only by a small group of users: in the months following, about 500 bug report forms were to be submitted. The baseline design was not complete, and the first announcements trailed future support for the Glulx virtual machine, for the Skein and Transcript on Windows Inform as well as Inform for OS X, and for illustrations. These have now been delivered, and the first phase of the project is about complete. This interim report aims to respond to some of the discussion about I7, and especially to specific suggestions made to us. Our first response must of course be to thank all of those who have taken the trouble to try the software, and to write to us about it. Reaction to I7 has been too various and too nuanced for any general summary to be possible, but it may be worth noting that we still have little experience of I7 through the whole end-to-end design cycle of a work of IF. The first month saw a small blizzard of questions and reactions (Google suggests that May 2006 was the highest-traffic month in RAIF's history). Inform 6 users reacted to the first sight of I7 by trying to safeguard existing capabilities: wanting to be assured that it is possible to write hybrid I6/I7 works, to include verbatim I6 code, and so forth. Today many users have solid experience of writing medium-sized works with I7, and low-level I6-interface features are talked about less. But relatively few of these works have been finished yet - not surprisingly since most non-speed-IF takes most of a year to complete. So perhaps the least discussed features of I7 are those relating to "publishing" - bibliographic data, cover art, and so on. We considered such features a major part of what I7 was trying to do, but it is as yet unclear whether people like them, and few of the suggestions below relate to publishing. We would be interested to receive more feedback on this. The wariness of I7 authors entering the 2006 IF competition - they mainly steered clear of blorbed story files with cover art - reflects that I7's default story file format, though based solidly on existing formats, is not yet widely accepted. This may be because Treaty of Babel-compatible interpreters and IF browsers are not yet widely used. We hope to do more in 2007 to champion interpreters and IF browsers which are cross-IF-virtual-machine, and which make IF generally more like iTunes and less like /usr/bin. 2. General critique Before passing to specific topics, we would like to say something about two sustained lines of critique: 2(a). It has an ideology I7 has an ideology. Its design is based on a view, not universally accepted, that the creation of IF is more like creative writing than typical software engineering. I7 is arguably a domain-specific word processor rather than a domain-specific programming IDE: it pays attention to word counts but not to checking code in and out of source repositories, for instance, and it offers model implementations in the form of recipe-like examples rather than a C++-like standard template library of code. While Inform is very much intended to serve the IF community, the existence of other powerful IF tools with different ideologies (notably TADS 3) allows us to pursue our design ideas without the burden of being the only viable option for IF writers. But we feel pangs when users are frustrated, and would like to do what we can to make the system more useful, because one of our design goals is practicality. Moreover, we accept that a tool which imposes its own methodologies has a much greater obligation to be well engineered than a tool which doesn't. This is a challenge we have to meet. The single biggest area of discomfort - for some users - is the seamless joining of the user interface with the language and its underlying tools, and a number of suggestions amount to requesting that we break the system up into components. We continue to believe that the holistic approach of I7 - in which the language, the standard world model, the user interface and the documentation all overlap - is better in this domain than the traditional command-line tools approach, in which a compiler, a set of standard templates, a text editor, a test harness, etc., should be "orthogonal" in the sense that each component can be switched for a different one - so much so that not all components are even supplied with the system. We believe that this goes beyond convenience arguments (though it is true that IF tools have in the past sometimes been shockingly hard even to install) and that cohesion has genuine merits of its own. The system would be weaker without the tight integration between components we now have: for instance, the NI compiler and the Web browsing kit inside the user interface application share some non-standard HTML protocols in order to make source reference icons work; the documentation and the UI similarly have to agree on some JavaScript to make the "paste this source text in" buttons work, and so on. The interface, the language, the compiler, the documentation and the examples are all one environment, and we intend this to remain true. The challenge for us here, then, is to find ways to provide better facilities for those wanting to access I7 at a lower-level, perhaps to batch process files at the command line level (something we do ourselves when regression-testing the compiler - it's always telling you something when you have to use "secret" features which you don't make available to others), or wanting to use source-control repositories. It must also be acknowledged that the joined-up approach has hindered the availability of I7 on other platforms, and in particular that it has caused inconvenience to the IF-on-Linux constituency. We hope to address this too. 2(b). It's a cathedral, not a bazaar At present, I7 is a mostly closed "cathedral" project rather than a mostly open "bazaar" project. But it is opening up gradually, and we hope this interim report is a small but helpful step. The majority of behind the scenes activity is a lengthy project of rewriting the whole NI source code (about 62,000 lines in a dialect of C and 10,000 lines of I6), replacing makeshift implementations, writing documentation, adding test cases, and so forth. As with any program of this size, rewriting is like painting the Forth bridge: when you finally reach the far end, you need to start again at the beginning. But NI is more robust and maintainable than it was back in April and bug reports have made a large contribution by exposing design misunderstandings as well as plain implementation errors. We do not feel we are at a point where it is useful to publish our bug-tracking database or to announce roadmaps for future development. For one thing, we don't want to box ourselves in. The history of programming language design (see, e.g., the proceedings of the ACM's HOPL conferences) tends to show that unhappy compromises are made at that most vulnerable time when the language is not yet mature but where its designers are already preoccupied by not breaking existing code. We want to be clear that I7 is a work in progress and to retain our ability to make major changes. In particular, we are more likely to use this freedom to move away from I6 methods than towards them. Bjarne Stroustrup's book on the evolution of C++ is eloquent on how compatibility with C (and the C linker) was on the one hand the single factor which gave C++ immediate and widespread credibility, but on the other hand the single biggest source of messy and unsatisfactory compromises, some of which persist to this day. This was not because C was a poor language: it was simply that it had different priorities. For I7, that half-help and half-hindrance is provided by I6. We have mostly found that minor compromises in I7 in order to fall in with familiar I6 conventions have been wrong. We want to keep on changing features like this, withdrawing them if necessary. All changes are evaluated against a corpus of about 700 source texts, but we are willing to break compatibility where a clear gain can be made. The other general motivation is to find changes which both simplify the system and at the same time make it more flexible, by eliminating what might be called special treatment. For instance, the reform of rulebooks in the December build made it possible to specify any choice of default outcome for a newly created rulebook - something which I7 had internally used to make "instead" rules work differently from "before" rules, but which was a facility not offered to the user. In effect, the built-in rulebooks had privileges which user-created ones lacked. Removing this made the design more robust, too: little ad-hoc features are to debugging what salients are to frontiers, the sticking-out-bits which are so dangerous for armies to defend. Conversely, where we find that existing source text is having to resort to a very hacky implementation to do something reasonable, this represents a salient the other way: a gap in the feature set. Finally, though, the actual experience of users is the acid test for what improvements should be made. About 200 changes have been proposed by users: the most popular of these, where not already carried out or overtaken by developments, are discussed below. 3. Release schedule and maintenance We have only informal policies, but the following is our current practice: - New releases are spaced apart by at least a fortnight, but usually not more than a month. To be worth releasing, our internal build has both to pass all existing tests and to contain at least a dozen bug fixes, or at least two or three new features. - The Mac OS X release and the Windows release are usually a day or two apart. In general we don't release the OS X build if the Windows version is likely to be held up longer, but we can't guarantee a schedule. - Each new build is posted at www.inform-fiction.org, and announced in a brief posting as a new thread at rec.arts.int-fiction. - As bug report forms are mailed to us, we try to acknowledge them, but we do ask for a little indulgence - it takes a surprising amount of time to assess them. Internally, we grade bugs from 1 to 5 in their importance - a mixture of severity and likelihood to hold people up in practical work - and, mostly, fix in that order. It sometimes (but not all that often) happens that a bug is reported by several people at once, but when this does happen, it's helpful rather than not - we see the problem arising in different ways. On the other hand, experience shows that when we initially think two bug report forms describe the same bug, we are sometimes wrong. This is one reason why at this stage we don't think it would be helpful for users to browse a list of "known bugs" and to send in reports only if theirs are "new". - Actual crashes - in which the NI compiler crashes rather than issuing an internal error and failing more gracefully - are always graded 1, and are fixed as promptly as possible. At present none are known. - To give some kind of snapshot, there are currently 39 grade 1 bugs, 109 grade 2, 68 grade 3, and 74 others (thought to be spurious or questionable). So there are about 220 issues needing attention, which is about typical. The total is not as bad as it sounds because it includes such things as minor typos in the documentation. - Any author with a work of IF on the point of release who is being held up by a bug is always welcome to tell us this, and we'll do what we can. 4. Inform 7 for Linux? The I7 user interfaces for OS X and Windows are already open source, and licensed under the GPL. The command-line-tool components of I7 - NI, the main compiler, and the blorbing tool (currently cblorb but likely to change to L. Ross Raszewski's iblorb) - are at present closed source, until we complete the current code overhaul. At present there is no Linux port of I7. We would be very happy to see one developed. But as yet, each time we have encouraged a proposal, it has not really worked out. We think a more useful approach would be for a small group of Linux programmers to collaborate. If such a group can come up with a sensible way forward, we will be happy to give them access to all of the sources and building tools used to make NI and its documentation, and to all of the images used for icons, etc., in the user interface. What would make a Linux proposal particularly attractive to us would be: - a general commitment eventually (i.e., not necessarily all at once) to port the whole system, and not only the command line tools (though we have no objection to these being independently runnable) - generally, to aim to replicate the user's experience; - a commitment to use file formats for e.g. the Skein enabling projects to be moved freely between Windows, OS X and Linux without change in their behaviour (as can already be done between OS X and Windows); - a measure of agreement on, e.g., whether to write for KDE or Gnome, and other issues such as use of WINE vs. native coding; - a mechanism for making it easy to release new versions of the Linux I7 when NI is re-released; - a general aspiration of making I7 easy as possible to install on Linux, and especially on the newer "consumer" forms of Linux such as Ubuntu; - if possible, a version for Solaris as well; - and an aspiration to work also on making a Treaty-of-Babel compliant interpreter for Linux play blorbed Z-machine and Glulx games, such as are compiled by Inform. Linux users should be able to see cover art and read blurbs about IF works, etc., just as OS X and Windows users can. It has been pointed out that the current license for NI and Inform 6 is arguably not broad enough for Linux norms (for instance, some distros would not allow I6 to be shipped with their releases). We are willing to re-address this: the decision has been postponed for now. While Inform will probably not move to the GPL, it may well move to an open source license granting freedom for derivative works but requiring that such works may only call themselves "Inform" if they comply with a reference set of behaviour - something like the TeX license, in fact. We certainly do not intend licensing issues to present any difficulty to Inform's users, and the only rights we wish to retain are the moral rights of authorship over the design of the language. 5. Non-English languages One of the final developments of Inform 6 was to adapt its run-time code so that it could be used to compile to a very wide range of languages. This proved a success, and translations were made to Dutch, French, German, Italian, Spanish and Swedish, among others. I6 itself was never intended to be altered for such use: for instance, the keyword "while" was not translated into Swedish for the benefit of Swedish authors, and the compiler's error messages remained in English. The assumption was that a Swedish author (let us say) would be able to read sufficient English to use I6; only the resulting work of IF would be in Swedish. In the case of I7, however, the source language and the final game language are so closely identified that the only finally satisfactory solution would be to translate all of I7's syntaxes, localising the application entirely. This is at present an overwhelmingly difficult task. Despite our initial expectation that I7 would not be a viable tool for non-English IF in the near future, the Rakontointeraktiva group has made surprising progress. Their requests for minor new features to make it easier for translators to hack the system (such as an ability to use translated I6 libraries and .i6 templates without having to open up the application bundle and make irreversible changes) seem to us very reasonable, and where possible we would like to be helpful. I6's internationalisation was a late addition to an already-mature system. At present, trying to stick a translation layer onto the run-time code produced by I7 is always likely to be a hacky business. We reserve the right to change internal implementation details - such as what the .i6 files are, and what they do - without notice. But we will do what we can to help translators, where this doesn't impede other progress. 6. Popular suggestions and areas for improvement Having talked about the larger questions, we would now like to comment in some detail on issues that have received at least a moderate amount of discussion. DOCUMENTATION (6.1) -- a more thorough elucidation of syntax: we mean for this to happen, but the time is not yet; too much is still in flux for the composition of such a document to be a good use of time. To partially address these problems until we can do better, we have been adding summary sections to each chapter of the documentation. (6.2) -- a formal grammar for the language: similarly, for now we regard Inform 7's syntax as being "that which makes the examples in the documentation work properly", rather than being defined by a precise grammar written up in (e.g.) Backus-Naur form. When the NI source is published, a (partial) BNF definition of the language will be available as part of it. (6.3) -- indexing of the documentation: also somewhat inefficient until things are in a more stable state. To partially address these problems until we can do better, we improved the search functions. (6.4) -- a more programmer-oriented and less inductive approach to the language: same concerns, really. This should eventually be done, but it's already a challenge keeping one set of documentation up to date with the state of the language, and a systematic programmer-oriented "reference manual" would probably only throw new light on exactly those areas still in flux. To some extent the released source for NI will be such a document (NI is written using a "literate programming" system which makes it publishable as a PDF document of heavily annotated and narrated code) - but that is likely to be too much rather than too little. (6.5) -- on the other end of the spectrum: a more tutorialish introduction to Inform 7; an I7 version of Ruins; other variations on "something shorter and simpler", including "a version of the manual with fewer words and more diagrams." However, the documentation as it stands is already our attempt at explaining I7 from the ground up, while still ultimately conveying the complexity of the program. If there's a need for other tutorials along simpler lines, those may have to be written by someone else. But that's probably just as well, considering that different people have different pedagogical styles. It's not quite the same thing, admittedly, but in lieu of such documents, we do our best to provide timely answers to questions on the newsgroup. (6.6) -- alternative forms of release for the documentation, including PDF files, files with easily-altered CSS, etc. To some extent these are created already by third parties, which is fine; I think the current feeling is that creating many of these ourselves would add another quite cumbersome step to the already fairly lengthy build process, and that it's better to hold off on such things until the program has stabilized more. In due course we do hope to publish a print-on-demand book of the documentation, and of course the PDF for that book would be available too. (6.7) -- plain-text files for the visually impaired: this is a case where technical difficulties are easier to overcome and the gain for some users is great, so we hope to address this soon. COMPILATION AND PROBLEM REPORTING (6.8) -- some form of sentence diagramming on rejected sentences to show more clearly which elements were understood how, to help people figure out why their syntax was rejected. NI already does a little of this kind of analysis, in that it shows what it believes to be the active verb in an assertion sentence which has gone bad, in all cases where searching shows that an alternative verb is possible - for instance, something like "the brackets support is heavy", where the verb might in principle be either "support" or "is". This is a little-noticed feature of I7 because in fact such sentences are fairly rare. A more common problem is for a sentence to have a valid interpretation which is not at all what the designer intended: "An orange in the fireplace is a fruit", for instance, can validly create an object called "orange in the fireplace". The simplest help here is probably an option to have a more diagnostic index - one showing which words were taken as the name of a new object. We will consider this. (6.9) -- for Inform automatically to detect story file size and determine whether it should reset the settings to compile to z8 or Glulx instead of z5. This sounds easy but is in fact pretty much impossible, because there's no way to know how large the compiled code will be until compilation has begun, and four separate VMs are being considered here. More helpful error messages have been added instead, which give explicit instructions on what to do to change VM (a simply process of changing the only setting in the Settings panel, usually). BASIC SYNTAX (6.10) -- some kind of alternative, non-natural-language syntax compiling to the same underlying constructs: interesting idea, but inconsonant with the existing project. No plans to pursue this. (We note that it might well be possible for third parties to construct preprocessors using lex and yacc which would be able to turn other languages into Inform 7 source text.) (6.11) -- a total overhaul to make things much more systematically rule-based than they already are, and to collapse the number of kinds of constructs in the language. The most complete expression of this idea is Andrew Plotkin's rather extensive reimagining of the system, but these things are essentially ideas for related languages rather than plausible directions for I7 itself to follow. I7 is somewhat constrained by the design decision to build on I6 as a code generator, but more importantly it aims to be above all a practical tool for IF. Striking a balance between rules ("You can't go north from here") and properties of objects ("This is a heavy ball") seems linguistically natural, even if a form of expression only allowing one of these approaches might be a cleaner design. No plans to pursue this. ARITHMETIC (6.12) -- the ability to use parentheses to bracket bits of the source for clarity. This is already possible in some circumstances (see below), but the documentation currently makes no use of this practice. We think it better to deprecate sentences which need clarity and to encourage writers to seek alternatives. (6.13) -- better syntax for arithmetic and a few more compact ways of expressing, e.g., incrementing and decrementing variables. There are several issues here. In some cases writing arithmetic formulae may indeed be the natural expression, just as a typical written book might break off text to write F = ma and then resume in words. Heavy-duty arithmetic is certainly easier to read and understand as a formula. On the other hand, in books it is generally written using abbreviated variable names: "Let m be the mass of a body, and a its acceleration: then the force F = ma", say. Writing simply "force = mass acceleration" would not be similarly expressive. So there may be a case for introducing equations, along the lines of conventions used in books (which is one of the design principles of Inform throughout). We would need to find a non-verbose but natural way to accomplish this. "Compact ways to increment and decrement variables" really amounts to a request for C-style "+=" and "++" operators. "+=" already exists in all but lexical token: "increase the score by 56" is a clear natural-language equivalent to "score += 56". On the other hand, postfix "++" and "--" have no clear equivalents, and we see no safe or justifiable way to add these. Those who really want them can always write an extension defining, say, To decide what number is (N - a number) ++: (- ({N}++) -). and while this requires white space around "++" and doesn't type-check that N is an lvalue (if it isn't, I6 produces an error), it does in other respects work. (6.14) -- clearer operator precedences. NI has basically no concept of operator precedence: neither, we feel, does English, which relies on the intonation with which a human reader speaks "let x be equal to y plus z times w" in order to communicate whether the addition happens before or after the multiplication. Clearly equations along the lines speculated about above would require a precise and traditional operator precedence. But we believe it would be inconsistent to apply such a thing to natural language forms. Instead, we do support the use of brackets to clarify such calculations: (34 times 10) plus 1 evaluates to 341, whereas 34 times (10 plus 1) evaluates to 374. AMBIGUITIES (6.15) -- "namespaces", or some other way to help prevent ambiguities. This is an important question and we haven't yet worked out our answer. It arises particularly when extensions are included: if one includes both Communism by V I Lenin and Impressionism by Vincent van Gogh, one is likely to find that both attempt to define "red". Even if they should both succeed, the result can only be confusing, which is why I7 indexes available extensions building a dictionary of possible clashes. Still, a better solution would be to allow each to have its own namespace, and to allow clarification from without to work using prefixes, as is done with languages such as C++ or Python: for instance, we could imagine being able to write "The canvas is Impressionism-red. Picasso is a Communism-red." - which may not be terribly elegant, but would be better than nothing, and would be reasonably concordant with written English. It is possible that namespaces might also be a benefit for chapters in the main source text, in some cases - if (as in the case of the "IF Whispers" event) a dozen IF authors are working, blindly of each other's source text, on a scene each for a work of IF, then name clashes are pretty well inevitable. Perhaps some might be averted. (6.16) -- better handling of pronouns, especially "it". This would clearly be a good idea, though it leads to some surprisingly difficult linguistics. Related to this: (6.17) -- the ability to use the name of a kind as a pronoun. For instance: Instead of giving something to a woman, say "You're not sure [the woman] would look after it properly." does not work at present, and many users feel that it should. Again, the technical difficulties involved are quite large - here it seems obvious that "the woman" refers to the woman appearing as a prototype earlier on, but other cases are less clear: what about... Instead of giving something to a Duchess, say "You're not sure [the woman] would look after it properly." ...for instance? - and there are also hazards involved because complicated text could become very ambiguous. (There are other snags, too. In "[the woman]" above, "the" is a signal that the proper noun should be used in the saying - it could not also be used as a determiner clarifying that the noun phrase refers back to some previously mentioned object. To have to accept "[a the woman]" as valid syntax, for instance, would be unfortunate, but it would be the only way to refer to the previously mentioned woman with the indefinite article.) I7's "called..." mechanism is intended to provide the same practical functionality but with no ambiguity: Instead of giving something to a woman (called the recipient), say "You're not sure [the recipient] would look after it properly." But this is more verbose and easy to forget to do. At any rate, we may well revisit this issue. We are in the mean time gradually improving the Problem messages arising from such uses. TEXT SUBSTITUTIONS (6.18) -- nested if/otherwise/end if inside quotations. Although this is technically possible we have decided against it on the grounds that it would quickly encourage illegible source text. If we were to accept this change, we would probably have to make the "[end if]" matching an "[if ...]" text substitution compulsory rather than optional. Again, we feel this would be a net loss. (6.19) -- substitutions and text variations within quotations for display. Quote boxes displayed in this way are a peculiar legacy of Inform 6, and in turn from the Infocom games "Trinity" and "A Mind Forever Voyaging". We do not intend to complicate the existing syntax, which provides only basic facilities, and instead suggest that this would be better taken up by extensions. (6.20) -- incorporating the extension Text Variations by Jon Ingold in the standard distribution, perhaps adding to its abilities somewhat. Although we do not intend to be blessing some extensions as canonical and others as apocryphal, we will probably include some form of Text Variations in future releases, subject to Jon's agreement. (6.21) -- a form of "[list of...]" that would omit articles entirely, rather than being synonymous with "[a list of...]". This would be internally consistent and add to the existing functionality, but on the other hand it breaks existing code (experiment shows that it causes 18 out of the 270 documentation examples to produce incorrect transcripts). We are leaning towards this change, but might be persuaded into something like "[list omitting articles of ...]" instead if there is any widespread protest. PHRASES (6.22) -- for block syntax to be changed to be more compact and/or more consistent and/or more intuitive according to some definition of intuitiveness. In principle we agree. Loop and condition bodies are currently a syntactic mess, and the use "begin" and "end if", "end while", etc., sits badly with natural language conventions. The result is aesthetically unappealing source text. The lack of an equivalent to "switch" is also keenly felt by some. We therefore propose a major syntactic change, breaking more or less every passage of I7 source text yet written. We need to be sure of our ground before making such a change, and for that reason we would like to go into the proposal in some detail. Consider the following valid I7 source text as an example: if the tree is green begin; say "How pleasant the garden is today."; now the squirrel is in the tree; end if; say "How dark and foreboding is the house." (One would normally use indentation to make this visually clearer, but at present indentation is ignored by NI.) We propose to abolish "begin" and "end", and to use indentation to signify block level, thus: if the tree is green: say "How pleasant the garden is today."; now the squirrel is in the tree; say "How dark and foreboding is the house." where it is the presence of indentation in lines 2 and 3 indicate what falls under "if". (Python of course lacks the semicolons as line terminators, but that's another story: Python has generally briefer statements than I7.) This proposal is seductive in that it does indeed resemble the way books would lay out hierarchical regulations or recipes. A further advantage is that blocks of code would then have the same syntax as phrases and rules, i.e., they would all take the form preamble : phrase 1; phrase 2; ... phrase n This significant-indentation feature is praised by some as Python's greatest innovation, damned by others as Python's hugest mistake: and some of its users think both things at once. The principal objection is that white space damage can invisibly change the meaning of code, and this is serious because white space (spaces, tabs, etc.) is silently altered by Web browsers and emailers, whereas other syntax (the spelling of words, punctuation, etc.) is not. Copy and paste operations, in most computing settings, consider themselves free to alter the text copied by (say) expanding a tab into four or eight spaces, without the user's consent or knowledge. Python avoids this in part by having quite a clever algorithm for parsing white space, and in particular being able to read indentation either in the form of sequences of spaces, or of tabs: it will only cease to read the source code properly if the two are mixed. But this is still a problem if one cuts and pastes between sources, or between a Web page and the source. The danger of "white space damage", though, would not be new. Tabs are already semantically meaningful in the handling of tables - a tab character divides table columns but a space does not. So some of the demerits of making tabs significant (in terms of being able to exchange code safely by raw email, scrape from web pages, e.g.) are already upon us. We feel that we can accept this additional hazard of meaningful white space, but that it would be prudent to see if the Inform user interface can parse and tidy up code pasted into the Source window from outside, so that source text is always stored in a canonical form (that is, with a single tab used for each level of indentation). It may also be worth copy operations which move text out of the Source expanding the tabs into spaces again. This would need quite some experimentation to get right. Two concomitant changes would also be necessary, and a third desirable: (a) A new use option would re-enable the old (i.e., the current) begin / end syntax, to make it simple to keep existing code working. This might also be helpful to visually impaired users, who would find indentation difficult to navigate with Braille keyboards or screen reading software. It would need to be possible to set this on a per-file basis, so that extension files could be written in "old form" and still work when included in "new form" projects. (b) Rules and phrases would be required to be written either in continuous prose, or as tab-indented lists, but not a mixture of the two. Block statements could only be used in the list form. (c) A form of "switch" statement could be introduced, using an ellipsis, along these lines: if the dangerous item is... the electric hairbrush: say "Mind your head." the silver spoon: say "Steer clear of the cutlery drawer." (6.23) -- for an explicit "break" and "continue" statement in "while" and "repeat" loops. In principle we agree. (6.24) -- for more complete and flexible negation, at the very least making it possible to write "if not..." or "unless..." wherever "if..." is now acceptable; and equivalent syntax for "when..." conditions. In principle we agree. (6.25) -- for "if we have..." tense-conditions to be replaced by some other syntax, because authors are confused by who this "we" might be, and/or wish they could say "if the player has...". We are considering this and may implement it, though it should be noted that then the seductively similar "if Mrs Wandering-Monster has..." would look as if it ought to work - but there is nothing like enough run-time storage in the Z-machine for this sort of complete historical record. (6.26) -- for phrases to be trivially definable with optional components or alternatives, as for instance To raise a/the subject of (gossip-topic - a person): ... allowing "raise the subject of...", "raise a subject of...", and "raise subject of..."; or again To dissect (N - a number) frog/frogs: allowing "dissect 1 frog" and "dissect 2 frogs". We are very attracted to this idea (the syntax, not the dissection of frogs) and believe it would constitute a general improvement to the usability of the language (and, especially, encourage extension writers to write extensions that are easy for authors to use). It is a technically tricky change to make, but in our judgement is worth it. Clearly there will need to be special syntax for those who really do need a literal slash in their definitions, but this will be uncommon. (6.27) -- to make phrase declarations consistent with the rest of the language in the way they name local variables, so that for instance we could write To raise the subject of a person (called gossip-topic): ... instead of To raise the subject of (gossip-topic - a person): ... This is an interesting proposal but leads to awkward ambiguities with the reading of "a" in front of "person". Would the syntax match "raise the subject of a Mrs Jones", or would it match "raise the subject of Mrs Jones"? It would also clash against the existing semantics of "called" when the "called" clause is omitted, as in cases such as this: To pick a number: ... What is meant here? Are we defining "pick a number", or are we defining "call (N - a number)"? Clearly we must rule in favour of the literal "pick a number", or else it will be impossible to make clear and safe definitions. So we would then have a situation where To pick a number: ... To pick a number (called the bingo): ... define entirely different phrases as seen from outside. By contrast, omitting the "(called ...)" clause from an action-matching pattern does not change the actions it matches: it only affects what named quantities are available inside the body of the rule. So we reject this proposal as resulting in a subtle clash rather than, as it first seems, an evident unification. On the other hand unification is no bad thing. It might be worth permitting rule preambles to use the "To ..." declaration syntax, thus: Instead of throwing (rubble - a thing) at (the target - a man): ... where there is no ambiguity raised. But we don't really see this as a high priority, and it takes us away from normal English prose style rather than towards it. It is certainly the case that To pick a number (called the bingo): ... should produce a more helpful problem message, explaining how it ought to have been worded. (6.28) -- to make definition declarations consistent with the rest of the language in the way they name local variables, so that for instance we would write Definition: a thing (called the glub) is a fish if the glub has gills. We have no objection to this, and it may be added as convenient, though it does not seem an urgent need. The present syntax Definition: a thing is a fish if it has gills. seems unproblematic in principle; in practice "its" (as in "its volume") is not very well handled at present, and this causes users some aggravation. (6.29) -- for phrases to be able to apply to single items or values, as in To annoy (current target - bobo): ... so that this would override To annoy (current target - a monkey): ... because it is more specific. Currently such single-target phrases are ignored. In principle we agree in the case of single things, but we are less enthusiastic in the case of unenumerated kinds of value - e.g. to allow To award (tally - 31) points: ... being allowed as an overriding definition of To award (tally - a number) points: ... Still, for consistency and generality this might be worth implementing. (6.30) -- lots of added synonymous syntax (e.g.: for "when play starts" to be the same as "when play begins"; "if X is more than Y" to be the same as "if X is greater than Y"). The desire here is to make I7 a little less persnickety and a little more generous with the fallible human memory, and we sympathize, but also need to exercise some restraint; creating additional syntax can mean cluttering the namespace unnecessarily and making the Standard Rules more complicated than they need to be. Still, some of these have already been accepted, where they do not generate conflict. Suggestions like this are addressed on a case-by-case basis. (6.31) -- along the same lines, and as a special case, for Inform to recognize alternative names for a couple of very common (and commonly mis-named) actions: "putting something in something" as an alternate of "inserting something into something", and "taking something from something" as an alternate of "removing something from something". This feels like a slippery slope: it accommodates novices but in a way that makes it less likely that they'll learn what they need to know (namely, how to look up action names in the actions index). We would prefer to write special-case problem messages specifically to catch these errors and direct the novice author on how to correct them. (6.32) -- lots of particular syntax suggestions that are not quite synonymous with the existing syntax and that amount to adding helper functions to the I7 library (e.g., "if the stop-time is 10 minutes ago", where I7 currently has no concept of "ago"). The desire not to over-bulk the library is strong, so except where these requests are extremely persuasive, we have been encouraging the suggesters to release extensions instead. But such suggestions are, again, addressed on a case-by-case basis. RULEBOOKS (6.33) -- variables whose scope is the lifetime of a rulebook being followed. At present all variable values either have local scope (these are the values defined by "let") or else global scope, making them accessible everywhere and by everyone. This means that more ambitious rulebooks which are trying to accomplish multi-stage or complex tasks end up using, or abusing, global variables as a way of passing information from one rule to another one further down the rulebook. (If the last rule is one that prints out a description of what has just happened, for instance, it is very convenient to allow any of the previous rules to send information to it.) Use of global variables for this purpose is bad not because untidy (though it is) but because it means the rulebook will fail if it is followed a second time during the course of its first following - the same reason why local variables are needed in routines which recurse. We accept this proposal, and hope to add it shortly: it fits naturally with the proposal for optional adverbial clauses on actions. KINDS OF VALUE (6.34) -- for better ways to describe a default, or null, value for given kinds. Most kinds of value in I7 have a null value: 0 for a number, 9:00 AM for a time of day, 1 for a figure number, the first created value for an enumerated kind, the command verb (i.e., word 1 alone) for a snippet, and so forth. I7 uses this concept internally to initialise all variables and properties, so that no value can be created which is invalid. But at present these null values are not well advertised, and some are not easy to describe in source text, especially since I7 is type-checked and does not have explicit casts. (There is particular awkwardness about the null text.) This makes it harder to write creative algorithms using tables as more exotic data structures in which values are sometimes significant and sometimes not. It may be that it would be helpful for the Kinds index to include a table of the null values for different kinds of value, and to define suitable constants for the null values of currently awkward cases. For instance, it might be worth defining a null value for "scene" which corresponded to the entire game, so that a test of being during this scene would amount to a test of whether the game is still playing (or whether we are asking the RESTART or QUIT question, e.g.). ACTIONS (6.35) -- for a way to define rules applying to actions performed both by the player and by NPCs. We need to revisit this, but have not yet decided what to do. The present situation is motivated slightly from implementation considerations (i.e., meshing with the I6 library) and partly from the observation that most rules do indeed apply to the player, and we do not want to complicate matters for these. (6.36) -- for more compact ways to write rules about non-player-character actions. We sympathize with the request but have yet to see a suggested phrasing that looks plausible (without leading to parsing ambiguities), and we haven't had any great success in thinking of alternatives ourselves. (6.37) -- for author-definable adverbial phrases in rules. Currently certain action-related rules can take specially-phrased addenda, as in Instead of going through the blue door: ... or Instead of taking something in the presence of Miss Prism: where "through the blue door" or "in the presence of Miss Prism" express conditions that could also be written (but with more tedious complexity) in a when statement. It would be good to let authors provide for their own adverbial clauses, especially as NI currently privileges the "going" action by allowing it clauses which no other action is allowed - and in general such singling out is poor design. In principle we accept this suggestion. (6.38) -- for a quick way to write rules about actions in which the noun and second noun are equivalent, as in Instead of tying the blue rope to the red rope or vice versa: ... This should be easy, and in principle we accept this suggestion. (6.39) -- for the action library to be rewritten in Inform 7. This is the most difficult proposal of any we are considering. The case for the proposal is that it would make it possible for people to read a natural-language form of what, say, the "can't take component parts rule" does, and that it would be more in the spirit of Inform 7 for more of the internals to be textual. The case against is that such natural language would nevertheless have to mesh with internals of the I6 library in probably mysterious and unappealing ways in any case, whether this is done in I7 or I6 syntax; that compilation of every game would be more time-consuming; that we would use more Z-machine memory; and that we would make it harder for library messages to be systematically overridden by users of foreign languages and in a way consistent with the underlying I6. The authors of Inform do not agree as to whether the advantages outweigh the disadvantages. A worthy but painful solution would be to provide a choice of implementations, somewhat like Python modules available in both Python and native C forms (e.g. StringIO and cStringIO). (6.40) -- for a way to store actions (preferably with any nouns or values used in the command) so they can be referred to later. We are sympathetic to this and it is one of the main motivations for some infrastructural work going on to make it possible to use large-storage values (i.e. values not fitting into a single virtual machine word): limitations in the Z-machine and Glulx virtual machine designs make these issues difficult, but we think that progress can ultimately be made. (A similar issue would be an ability to store prior typed commands.) RELATIONS (6.41) -- a way to make verb infinitives longer than a single word, thus tacitly allowing adverbs to be soaked up into them ("to quickly run", say, rather than "to run"). We could allow this, and it seems in principle fair enough, but it would a little bit of a nuisance to implement. TABLES (6.42) -- the ability to look up table entries by column as well as by row. This is not possible to make "type-safe" because different columns contain values of different kinds. Inform would not be able to tell what kind of value "row 3 of column K of the Table of Mixed Blessings" at compile-time, because it would not be able to anticipate all possible values of K which might arise. (Compare the case of C. In C, multi-dimensional arrays feature elements which have the same type in every column, so one can freely range across both row and column. A better comparison might be with an array of structures. If one devised, in C, typedef struct frog { int lily_pads_hopped_onto; char *favourite_song; float flotation; } frog; frog table_of_frogs[100]; then one would be able to refer to table_of_frogs[K].flotation, which certainly refers to a value of type "float", but there is no construct for "element J of table_of_frogs[12]", say, where J = 1 would mean "lily_pads_hopped_onto" - an integer - but J = 2 would look up "favourite_song" for a pointer to char, and so on. Since the compiler cannot predict J, it cannot be sure of the type of this value.) (6.43) -- for alternative ways to delimit tables, and/or alternative presentations of same. There are a number of suggestions; none is entirely convincing. On the whole we are happy as things stand. ACTIVITIES (6.44) -- grouping duplicates: currently if we have a number of instances of a kind (A block is a kind of thing. Two blocks are in the kitchen.), the grouping activity does not allow one to override the description of these objects, though it would if the blocks had individual names. Moreover, it would be nice to be able to get the number of items being grouped together and manipulate that information. To some extent we are postponing such issues until we have a better way to handle lists and sets of values, which is a long-term aspiration. PRINTING (6.45) -- overhaul of the way paragraph breaking works to be less mystical and capricious. Almost certainly needs to happen somehow, but this is a fussy, fiddly, easily broken system, and said overhaul keeps being put off. Andrew Plotkin once referred to his attempt to intervene as "sticking a butter knife into the live electric toaster of the Inform paragraph-breaking algorithm". It is not clear at all that any generally satisfactory algorithm exists: the surprising thing, in some ways, is how often the present method comes across as adequate. We are unlikely to change the automatic algorithm very much (and then with great caution) but better ways to explicitly override the automatics are more plausible. (6.46) -- more complete control over what gets printed in room descriptions, especially the concealment (or alternative description) of objects that are sitting on supporters that are themselves scenery. This is a big issue for users. We have fielded questions, suggestions, and complaints from everyone from novices to veteran authors working on major projects. I6 was not very flexible in this area, and at present I7 is only a little better. The looking action is broken up into a number of rules, but each of these is too complicated to make it practicable to replace. Rather than introduce ad-hoc activities, we are considering a more substantial rewrite of looking, perhaps on the lines of the Room Description Control extension by Emily Short. PARSING OF NOUN PHRASES (6.47) -- direct control over whether things are considered to have proper and/or plural names. Currently I7 extrapolates this from the phrases used to define objects, but a) it occasionally is wrong and b) there are occasionally times when it is useful to change these things during play. Particularly problematic are mass nouns, as in "Some flour is in the cup": Inform tends to notice the "some" here but ignore "is", marking the flour as plural even though this is not what we want. We probably do need to provide the ability to control this more directly. (6.48) -- ways to explicitly define some words *not* to be used in parsing the name of a given object. We accept this proposal. (6.49) -- ways to explicitly define additional plurals for kinds or individual objects. Similarly, we accept this proposal. SCENES (6.50) -- direct control of scenes, allowing the author to say "scene x ends" and similar things. One of us has an ideological objection to the direct starting and ending of scenes, on the grounds that scenes are meant to reflect things about the state of the world-model. The other one of us hasn't. For what it's worth, the reasons for the current design are: * that it guarantees that each action falls entirely within, or entirely outside, of any given scene, and therefore that "during..." clauses in the conditions for a rule are not affected by rule ordering; * that scene changes therefore occur like every turn rules, outside of actions; * that it promotes a more state-driven style of coding, in which it is clearer to someone looking at the source text when a particular scene starts and finishes; * that it makes it possible for the Scenes index page to show this information in a communicative way. It has been suggested that the documentation could usefully explain some of this, so that users can at least see why they are being asked to follow this model. (6.51) -- implementation of scenes as objects that can themselves belong to kinds, with associated behaviors and hierarchies. The question of whether "scene" should be a kind of object (like "region") or a kind of value (like "time") is one which we have argued over for more than a year now. At present it's a kind of value, which is in some ways appropriate, since it is an abstract label applied to something non-physical, so could be considered more like a colour or a number than like a room or a region. There are also a few implementation reasons why this is useful: one can have scene columns in tables, or scene properties. On the other hand, it is arguable that a scene is indeed something physical, in that it describes an extent of time much as a region describes an extent of space. (The reason "region" is a kind of object is because we want to be able to apply the containment relation to it: regions can be nested, and rooms can be inside them. These arguments do not apply to scenes, but it is certainly uncomfortable to be treating space and time as conceptually different.) More importantly, I7 is rich in ways to describe flexible conditions as applied to objects. It would be much easier to define what might be meant by a "scary" scene, say, if scene were a kind of object. Again, the principal authors of Inform do not agree about which is better. We may perhaps reach some compromise by providing features for handling values like objects, or vice versa, which render the question moot. (6.52) -- some syntax to define a scene as happening only once, e.g. The car crash is a one-time scene. such that this scene will be triggered only once and it will not be be necessary to write out the whole of The car crash begins when car crash has not happened and the car is in the ditch. but just The car crash begins when the car is in the ditch. In principle we agree. WORLD MODEL (6.53) -- the ability to define new compass directions: this has always been part of the plan but just hasn't been implemented yet. (6.54) -- backdrops whose locations are determined by a rule rather than by a set list of rooms or a region. In principle we agree and it may be that an activity could provide this. (6.55) -- for the device kind to be withdrawn and a "switchable" attribute used instead. The arguments here are philosophically quite sharply divided, and they bear on other kinds, too. The I7 kind hierarchy is intentionally light: there are only 16 built-in kinds of object. The total may indeed fall further: "player-character" is likely to be abolished (see below). Of the remainder, one kind is egregious but harmless, since it is easily avoided: this is "player's holdall", a survival from I6. There's at most one of these in any given situation, in practice, and it never needs to be anything other than what amounts to a sack. A minimalist view of kinds is that the essential determiner of kind-categorization is precisely the capacity to enter into special relations with other things, rather than the capacity to be in one state or another, or the capacity to be acted upon in specific ways; since we can write rules about action handling, and adjectives to describe state, that cut across the boundaries of kind. For instance, "supporter" is necessary as a kind because it defines the domain of the supporting relation. Similarly, we need room, thing, container, person, direction and region. It might well be argued that a minimalist view of kinds is just what I7 should take in defining its built-in set - since these are the ones that can't be got rid of. On the other hand, the logic of this is that we should abolish not only device but also door, animal, man, woman, backdrop and vehicle. In practice there are implementation reasons why it would be immensely difficult to make door, say, other than a kind; and if we take a more liberal view of kinds, that they should be used to express an essential and unchanging nature, then a door and an animal look rather better as candidates. And linguistically speaking, few kinds are as basic and relevant to everyday language as "man", "woman" and "animal". A more practical take on the minimalist view is to say that although the Standard Rules do not, in fact, define relations for all of these kinds, users will do. Clearly this is the case with "man" and "woman", for instance. But what about "device" or "vehicle"? The documentation examples do include relations on devices, but not very often. This leaves us back where we started. The rationale for the present restriction (that a device cannot simultaneously be, e.g., an animal or a vehicle) is that if an object needs to be two things at once, it's probably two objects joined together: e.g. for a robot dog with a switch, there are really two objects - the switch (a device) being part of the dog (an animal). But is it ever possible to say the macroscopic objects are so simple in character? We are still thinking about this. (6.56) -- for the handling of person kinds to be addressed in some way so that the player-character is not special; in particular so that the player-character can naturally be male or female. We are indeed minded to remove the "player-character" kind. See also-- (6.57) -- some handling for mass substances such as liquids. This was much discussed at one point in the planning stages of I7, but we're not sure the need for this is as keenly felt now, since several plausible implementations are already available in the Examples. We may revisit this, or may leave well alone. (6.58) -- various small and large suggested additions to the world model, including models for character posture; dialogue and conversation models; treatments of darkness; etc. Almost universally our response is to recommend that these suggestions (often inventive and appealing) be turned into extensions rather than being incorporated into the standard rules. PROPERTIES (6.59) -- either/or properties for kinds of value. Properties divide into either/or and value properties. Value properties can belong either to objects (the usual arrangement) or to constants of a new kind of value, created with a table. For instance, if we create a kind of value called "colour", then by defining a suitable table we can have a property called "wavelength", say, which every colour has its own value of. On the other hand, either/or properties can only belong to objects. If we lift this restriction, we would be able to write, say: "A colour can be soothing or jarring. A colour is usually soothing. Bright red is jarring." This is worth considering further, but may involve more work than first appears. OPTIMIZATIONS (6.60) -- for visibility checks to translate in Inform 6, where possible, to LoopOverScope calls in order to speed up such operations. We would need to investigate this further. MAJOR LANGUAGE FEATURES (6.61) -- more extensive multimedia support. We mean to add sound support for Glulx (the main hold-up at present is that adding sound to CocoaGlk for OS X is a non-trivial task), and we would then anticipate adding a capacity to use sound effects broadly equivalent to the current image support (i.e., fairly rudimentary); then to offer as much help as possible to those interested in developing extensions to do more elaborate things, and in particular to work toward compatibility with Ross Raszewski's GWindows package, which would allow authors to do a wide range of UI design tasks. At some point this is likely to be distributed as part of the standard Inform distribution. (6.62) -- ternary, i.e., three-way, relations: this is certainly possible, though not immediately a priority, and there would be significant run-time storage costs. A variant on this would be the ability to give a binary relationship one or more properties. (This arose during the writing of "The Reliques of Tolti-Aph, when the natural way to express that a spell A had been cast on wizard B for a limited length of time X would have been some kind of ternary predicate spell(A, B, X) - or better yet, a binary predicate spell(A, B) with a property called "duration" whose initial value was X. There proved to be no good way to express this (and storage was also a problem in the Z-machine), so the design compromised, which is why time-limited spells can only be cast on the player.) VERSION CONTROL (6.63) -- some form of version control for project management: definitely interesting, but the problem hasn't been tackled yet. Much of the elaboration of existing source-control packages is aimed at making it possible for many coders, in different places, to work simultaneously on the same source code. This is unlikely to be so high a priority for Inform, since little IF is widely collaboratively written (and also because the language is surprisingly resilient when it comes to merging text from two different authors). On the other hand, the protection against accidental loss, provision for branches, and ability to undo recent changes are all as helpful to the IF writer as to any other programmer. Of course, it is perfectly possible to check a whole Inform project bundle (a folder on Windows, a .inform file on OS X) into e.g. CVS or Subversion already; the question is whether Inform should provide more direct features, and if so, how. This is probably worth further discussion. (6.64) -- archiving of the current system used: when a large work of IF is finished, the project is to some extent mothballed, to be returned to only when a small batch of bug fixes seems called for - perhaps years later. What if, as is very likely right now, the language has dramatically moved on, so that the source text is now written in an incomprehensible ancient dialect? The prudent IF author may therefore wish to keep a backup copy of Inform as it stood when the work was finished, just in case, but it has been proposed that we provide features for archiving all the relevant material used by Inform instead - the extensions used, the form of the I6 library used, etc. Perhaps this can indeed be done, with some care, but Inform such a large system (large in terms of the number of inter-related components) that it may amount to simply zipping up a copy of the whole application in any case. (In the mean time, note that every previous public release of Inform 7 is archived at www.inform-fiction.org, just in case of need. We plan to continue this practice. Source code for past builds of NI is also archived.) USER INTERFACE Work on the user interface is more constrained than work on the language, in some respects, for several reasons: * we must try to keep the platforms roughly together, so that the look and feel of Inform is common to Windows and OS X; * we must try not to break human interface guidelines for either platform, so that users will not feel that the experience is unnatural; * we need to think about how difficult features are to implement on both platforms before going ahead; * we need to keep the system visually simple: it must not become plastered with buttons and controls. It is better to have one feature which is clearly comprehensible than have two in a way which is so visually complex that neither is properly taken in at a glance. The user interface of an application is where its design metaphors are presented: it must be communicative, largely intuitive, smooth in operation, and unlikely to shock. It must not lose its coherence by behaving like X for one purpose and yet behaving like Y for another. At present, for instance, we are working mostly on improving the visual communication and functionality of the Skein - perhaps the interface's most challenging concept. We want to tweak the interface to make the Skein more natural and appealing to new users, because we believe that the Skein/Transcript combination may be the most powerful feature of Inform to be underused. The most commonly raised requests are for: (6.65) -- a back (and for symmetry forward) "browser" button for going back and forth between HTML pages in the Documentation, Problems report, Index pages, etc. We've been discussing this for some time, and may have a solution. The difficulty is to do it without wasting screen space, confusing the look and feel, clashing against existing buttons, etc. The logic of the behaviour of such buttons is not as trivial as it might seem, since it can sometimes switch one panel to another (e.g. Index to Documentation). (6.66) -- ways to break up the source text into a collection of smaller passages, for those who find a single long text hard to manage. We would like to provide better navigation and search facilities in any case, because the single/multiple decision should not be made simply because large files are badly managed. (On this point, note that the new Headings gadget - currently available only on OS X, and therefore not seen by many I7 users yet - allows easy directory-style browsing through the headings in a source text. Note also that because one can have the Source open in both panels, one can already see two different parts of the source text side by side for comparison purposes.) Such features may buy off our softer critics, but there is also a constituency of users who feel strongly that the ability to arrange source text in multiple documents is essential. They may well be right. The thinking behind the present design is that it is simple, modeless (in the sense that the Source panel can only be showing the whole source), preserves the metaphor of the user interface - in that writing IF is supposed to be like writing a book - and encourages the use of headings. We are able to avoid #include-style directives, which makes the language a little cleaner. And, finally, we note that e-books generally make better sense as single book-long files than when divided into chapters; and the source text is in many ways just that, an e-book. Now that we have experience of some large projects - for instance "Floatpoint" runs to 80,000 words, the size of a fairly substantial novel - it is becoming clear that some kind of segmentation needs to be offered to the user as an option. This would need to be semantic, and related to headings, rather than syntactic, and controlled by file boundaries (or, worse, #includes). It seems to us that there is probably little practical distinction between (a) making the Source panel a folding text editor, with only one chapter folded out at a time, and on the other hand (b) making the Source panel display only single chapters, with some kind of gadget allowing the user to switch between chapters. We are considering the options. Miscellaneous other suggestions include: (6.67) -- improvements to the map index: this is technically challenging, and we haven't attempted to handle this yet. (There are also some ordinary bugs, as well as feature set improvements, to work on.) (6.68) -- ability to look at the standard rules and other packaged extensions from within the IDE and without going to special trouble. At present we allow installed extensions other than the built-in set to be opened in an external editor window. This display-in-a-second-window option is probably best, to maintain the purity of the Source panel, but certainly we should avoid special trouble. (The Standard Rules we don't really want to open up: they are a low-level, messy collection of interfaces to I6, in some places, and are not as editable as they appear since numerous things have to be done just right to make the whole thing work. The same argument doesn't apply to the other built-in extensions, which we should probably allow to be opened but not changed.) (6.69) -- more control over fonts and colors displayed: this is reasonable, up to a point, and the OS X application is currently adding support for use of the Font panel to make arbitrary choices of Source text display font. (6.70) -- ability to include other files into the project for note-taking and the like. This seems cluttery. We have discussed the possibility of allowing marginal annotations, etc., though this is not easy to implement: the main issue would be to retain visual simplicity. Generally speaking, Inform has chosen not to include the whole penumbra of files within the main project bundle - we have the concept of the Materials folder instead, and that's probably where an author's notes and sketches belong, too. (6.71) -- ability to lay out the map graphically with point-and-click controls in the index area. This is not only difficult to implement, but also at odds with the basic Inform design, and we will not go down this road. It would in any case not save much typing time since one still needs to type the names of the rooms being added to the map, whatever the interface used. (We did, however, make it easier to see a visual map drawing updated as one types the source text by adding the Refresh Index feature - command-I on Mac OS X - which provides more or less immediate feedback.) (6.72) -- ability to assign key bindings to change window focus and do other things within the user interface. Here we need to pay particular attention to conventions on the different platforms: for instance it's an act of folly for any OS X application to define command-H as anything other than "hide application", and a Windows author who makes the find key anything other than control-F is likely to be run out of town. We have therefore given up on any hope of having common keyboard shortcuts across platforms; similarly, the menu layouts are not quite the same. While some degree of customization may be possible, it doesn't seem to us tremendously important. (6.73) -- ability to rearrange locations of tabs. Again, we don't see this as a compelling gain. (6.74) -- a button to paste extension examples into the main source, just as other examples are pasteable. We agree: this is highly desirable; there are no show-stoppers, but it's not a quick thing to add; and we simply haven't written the code yet. (6.75) -- a bug-report-filing automator allowing people to create and send bug report forms automatically from within the IDE. This we don't want to do. There are concerns that it would lead to massive overreporting (especially by novices who have not really grasped the basics) and/or keep people from trimming their source down to a reasonable size - something which is extremely helpful. We do not observe any reticence on the part of Inform users in reporting bugs now. (6.76) -- automatic table management of some kind, such as a tab allowing the author to edit in something like a spreadsheet. This presents more problems than it solves, quite apart from breaking the "it's like writing a book" metaphor, and it is unlikely to happen. Automatic table displaying, where the user interface would be more sensitive to tabs and would try to show tables in the source text with their columns nicely aligned, is more appealing - but it is by no means trivial to implement, and we haven't given this any priority. (6.77) -- allowing threads in the Skein to rejoin if they represent the same basic play strategy, but exploring two different variations for a while before returning to the main plot. An interesting proposal which presents significant coding challenges.