Inform 7: Possible future developments
Emily Short
state of Inform "in a week or so". This document turned out to take us
longer than I expected, but it is also more thorough than I originally
anticipated. We're open to feedback, as always.
-- Emily
=====
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 combinations 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 combinations, especially as NI
currently privileges the "going" action by allowing it combinations
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 L. 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.
Aaron A. Reed
into a number of these issues, and it's great to see them enumerated
and explained.
The amount of thought and work that goes into the further development
of this language continues to amaze me. I'm making fantasic progress on
my current opus, spending more time writing and less time butting heads
with programming issues, so I appreciate your work every day. Thank
you, thank you, thank you.
Adam Thornton
Emily Short <ems...@mindspring.com> wrote:
>A few weeks ago I promised to post something on the current and future
>state of Inform "in a week or so". This document turned out to take us
>longer than I expected, but it is also more thorough than I originally
>anticipated. We're open to feedback, as always.
I have a long response, which unfortunately is a frothing rant, to
section 4. I think I will sit on that, shop it to friends for editing,
and eventually post it in a more measured form than it currently
exists. However, I cannot in good conscience idly let this pass:
>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."
This makes my brain bleed.
I will, assuredly, be continuing to use the Old Style, probably for I7's
lifespan, and I applaud the designers' realization that some sort of
switch to provide for extant code is required. In general, it is my
considered opinion that syntactically-significant whitespace is the
devil's handiwork, and that those who advocate its use are, by and
large, syphilitic feces-flinging crack-monkeys.
Adam
David Fisher
> COMPILATION AND PROBLEM REPORTING
...
> (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).
How about this: If the setting is z5 and compilation fails because it does
not fit, automatically set it to z8 and start the compile again (leaving the
setting at z8 afterwards and informing the user that this has been done).
Then it would take twice as long to compile the first time, but be fine from
then on.
> PHRASES
...
> We propose a major syntactic change, breaking more or less
> every passage of I7 source text yet written.
[ ... snip explanation of indentation signifying block level ... ]
Another possibility is wiki-style bullet points:
if the tree is green
* change x to 2
* now the squirrel is in the tree;
say "How dark and foreboding is the house."
Deeper levels are signified with more asterisks ("**"). The ending
semi-colon is still needed when the indentation level goes from 1 to 0
(after "the squirrel is in the tree"), but is otherwise optional (since a
group of "*"s signifies the end of the previous command).
> (6.39) -- for the action library to be rewritten in Inform 7.
Definitely !
One reason is that this would allow non-I6 people to understand what is
really going on in the library, and to therefore be able to write
replacement routines if they want to ... (and even if you know I6, replacing
a routine can sometimes mean trying to work out what the I7 equivalent is
anyway).
David Fisher
Aaron A. Reed
> I will, assuredly, be continuing to use the Old Style, probably for I7's
> lifespan, and I applaud the designers' realization that some sort of
> switch to provide for extant code is required. In general, it is my
> considered opinion that syntactically-significant whitespace is the
> devil's handiwork, and that those who advocate its use are, by and
> large, syphilitic feces-flinging crack-monkeys.
The decision to implement this alongside the existing mechanism is part
of what I was lauding. This fits in great for me since I indent my code
anyway and always forget to type "end if"; it allows for people like
Adam and various programmer friends of mine who hate Python to continue
coding exactly as they had before. Hurrah for choices.
One concern that was unclear from my reading of the design: would
indentation be required for all conditions or only multi-line ones
requiring a begin and end in the current system? It's more economical
and aesthetic to just leave something like this as a single line: "if
any cat is shedding, now all allergic people are sneezing; otherwise
now all allergic people are happy".
Aaron A. Reed
> > (6.39) -- for the action library to be rewritten in Inform 7.
>
> Definitely !
>
> One reason is that this would allow non-I6 people to understand what is
> really going on in the library, and to therefore be able to write
> replacement routines if they want to ... (and even if you know I6, replacing
> a routine can sometimes mean trying to work out what the I7 equivalent is
> anyway).
The designers expressed concern about I7 libraries increasing the build
time and memory usage of compiled games, but I agree that being able to
see exactly what the action library is doing would be extremely
valuable in certain debugging situations, and would also give people a
much better sense of what's going on "under the hood," especially those
newer people who are not bringing I6 experience to the table.
Would it be possible, perhaps, to have an Inform 7 version of the
action library available in the documentation or on the website, even
if the compiler continues to consult the standard I6 version when it
actually builds a game? This might meet the reference and educational
needs, while avoiding the potential problems.
Andrew Plotkin
> In general, it is my
> considered opinion that syntactically-significant whitespace is the
> devil's handiwork, and that those who advocate its use are, by and
> large, syphilitic feces-flinging crack-monkeys.
But some of us are syphilitic feces-flinging crack-monkeys *with
style*.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't subjected you to searches without a warrant,
it's for one reason: they don't feel like it. Not because you're innocent.
Andrew Plotkin
>
> Would it be possible, perhaps, to have an Inform 7 version of the
> action library available in the documentation or on the website, even
> if the compiler continues to consult the standard I6 version when it
> actually builds a game? This might meet the reference and educational
> needs, while avoiding the potential problems.
That was my thought as well. (Just as, say, Python has a pure-Python
implementation of the pickle module, and then a native-code (C)
implementation for speed.)
Adding regression tests to guarantee semantic equivalence is a bunch
of work, but not really difficult. (Python does not currently have
that for pickle, but it's on their TODO list.)
Adam Thornton
Andrew Plotkin <erky...@eblong.com> wrote:
>Here, Adam Thornton <ad...@fsf.net> wrote:
>> In general, it is my
>> considered opinion that syntactically-significant whitespace is the
>> devil's handiwork, and that those who advocate its use are, by and
>> large, syphilitic feces-flinging crack-monkeys.
>
>But some of us are syphilitic feces-flinging crack-monkeys *with
>style*.
Well, that's as may be.
Adam
Andrew Plotkin
> Here, Adam Thornton <ad...@fsf.net> wrote:
> > In general, it is my
> > considered opinion that syntactically-significant whitespace is the
> > devil's handiwork, and that those who advocate its use are, by and
> > large, syphilitic feces-flinging crack-monkeys.
>
> But some of us are syphilitic feces-flinging crack-monkeys *with
> style*.
To clarify: I don't advocate Python's whitespace system unreservedly.
In fact, I think it's the most annoying thing in Python. *But* it's
the least annoying most-annoying thing in any computer language I am
familiar with. It doesn't get in my way when I work.
I7's if/begin/end-if model *does* get in my way, and indentation is
the best idea I know of to replace it.
But the problems of pasting text to/from Usenet, web pages, and email
must be addressed. It's broken now for tables, and it would be
comprehensively broken if I7 adopted Python rules as-is. Best
suggestion I've got: have the IDE editor format with tabs in the
buffer, but translate to spaces when saving and copying. (And
translate from spaces to tabs when loading and pasting.) This
shouldn't be *too* much work for the editor code.
Emily Short
Andrew Plotkin wrote:
> To clarify: I don't advocate Python's whitespace system unreservedly.
> In fact, I think it's the most annoying thing in Python. *But* it's
> the least annoying most-annoying thing in any computer language I am
> familiar with. It doesn't get in my way when I work.
>
> I7's if/begin/end-if model *does* get in my way, and indentation is
> the best idea I know of to replace it.
>
> But the problems of pasting text to/from Usenet, web pages, and email
> must be addressed. It's broken now for tables, and it would be
> comprehensively broken if I7 adopted Python rules as-is. Best
> suggestion I've got: have the IDE editor format with tabs in the
> buffer, but translate to spaces when saving and copying. (And
> translate from spaces to tabs when loading and pasting.) This
> shouldn't be *too* much work for the editor code.
Yeah, I have this fantasy that such a change would actually fix the
table aggravations too, as a side effect.
However, this may be my crack-monkey tendencies acting up again.
ChicagoDave
> This makes my brain bleed.
>
> I will, assuredly, be continuing to use the Old Style, probably for I7's
> lifespan, and I applaud the designers' realization that some sort of
> switch to provide for extant code is required. In general, it is my
> considered opinion that syntactically-significant whitespace is the
> devil's handiwork, and that those who advocate its use are, by and
> large, syphilitic feces-flinging crack-monkeys.
Normally I give you guys (Emily and Graham) a wide amount of latitude
in my first reactions to things.
This will not be one of those times.
I agree with Adam.
Whitespace as a logical portion of source text is evil, horrifying, and
wrong.
And then making it an "option" is even more horrifying. You want to
split the world into two camps, one always ravaging the other. Code
will be in two directories on the archive (one with whitespace, one
without).
And you intend to release a BNF when you're "done"? What will that look
like? I can hear the people over on the compiler newsgroups cackling,
well, like feces-flinging crack-monkeys.
This is simply the worst possible course of action I could imagine for
Inform 7.
My opinion may not mean much, but please do not do this.
David C.
Andrew Plotkin
>
> And then making it an "option" is even more horrifying. You want to
> split the world into two camps, one always ravaging the other. Code
> will be in two directories on the archive (one with whitespace, one
> without).
I know that TADS 2 suffered from a syntax split in this way, and it
was not a good situation. However, there are not two TADS source
directories on the Archive.
This scheme, if it happens, will allow a game of either style option
to include extensions of either style option, without the game author
worrying about it. (Graham has stated this in email, if he left it out
of the big post.)
> And you intend to release a BNF when you're "done"? What will that look
> like?
I7's syntax, from a formal-grammar point of view, has been getting
simpler and more consistent since May.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't thrown you in military prison
without trial, it's for one reason: they don't feel like it. Not
because of the Fifth Amendment.
ChicagoDave
> This is simply the worst possible course of action I could imagine for
> Inform 7.
>
> My opinion may not mean much, but please do not do this.
I'm sticking by my vote.
This portion of Emily's post so overwhelmed me that I had forgotten all
the other parts, which were enlightening. I have to re-read the portion
_after_ the whitespace proposal since that's the part that I least
remember. I will post more comments when I've sufficiently recovered.
David C.
Timofei Shatrov
to confuse everyone with this message:
>> Adam Thornton wrote:
>> This makes my brain bleed.
>>
>> I will, assuredly, be continuing to use the Old Style, probably for I7's
>> lifespan, and I applaud the designers' realization that some sort of
>> switch to provide for extant code is required. In general, it is my
>> considered opinion that syntactically-significant whitespace is the
>> devil's handiwork, and that those who advocate its use are, by and
>> large, syphilitic feces-flinging crack-monkeys.
>
>Normally I give you guys (Emily and Graham) a wide amount of latitude
>in my first reactions to things.
>
>This will not be one of those times.
>
>I agree with Adam.
>
Me too. In light of this I may even start developing LIFP again (and the result
won't be pretty!)
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Eric Eve
news:1169183879....@l53g2000cwa.googlegroups.com...
>> Adam Thornton wrote:
>> This makes my brain bleed.
>>
>> I will, assuredly, be continuing to use the Old Style, probably
>> for I7's
>> lifespan, and I applaud the designers' realization that some sort
>> of
>> switch to provide for extant code is required. In general, it is
>> my
>> considered opinion that syntactically-significant whitespace is
>> the
>> devil's handiwork, and that those who advocate its use are, by
>> and
>> large, syphilitic feces-flinging crack-monkeys.
>
> Normally I give you guys (Emily and Graham) a wide amount of
> latitude
> in my first reactions to things.
>
> This will not be one of those times.
>
> I agree with Adam.
>
> Whitespace as a logical portion of source text is evil,
> horrifying, and
> wrong.
I'm not sure I feel as strongly as that (or, at least, that I would
wish to express myself as strongly at that), but this was the
proposal that made me feel the most uneasy, and my initial gut
reaction is to hope that it gets dropped. Is the intention that the
same indenting would also replace the existing syntax for repeat and
while loops? If not then introducing an indexing syntax for if while
retaining begin... end repeat/end while would seem to be introducing
another needless inconsistency into the language.
I suppose the problem arises at least in part because of the clash
between the need to preserve the natural-language metaphor and the
need to provide a clear and convenient programming syntax, and
natural language is not generally used for expressing program
control statements.
The most natural way of expressing a block 'if' would be to separate
the statements by commas: e.g.
if the red door is open then say "You see Mrs Bumble come stumbling
through the door. As she enters the room, she falls flat on her
face. ", move Mrs Bumble into the Lounge, now Mrs Bumble is prone;
The problem with this is that it does not readily allow for nesting
blocks (something that natural language surely never attempts).
Perhaps the most programmer-convenient way to cope with this is to
use braces or whatever to enclose blocks:
if the red door is open
{
"You see Mrs Bumble come stumbling through the door.
As she enters the room, she falls flat on her face. ";
move Mrs Bumble into the Lounge;
now Mrs Bumble is prone;
}
This is clear, minimizes typing, and readily allows nesting. Of
course it departs from the natural-language look, and makes the code
look, well, more code-like, but then neither the existing syntax
(with begin and end if) nor the proposed new syntax (with
identations) really resembles natural language all that much either.
The existing syntax is perhaps the best compromise (possibly barring
an odd tweak or two) between clearly delimiting blocks and
maintaining something that looks vaguely like English; making
indentation determine the extent of blocks seems to me to be already
moving towards a coding paradigm (if it seems a natural way to do
it, it's becauuse it's how programmers often lay out their code, not
because it otherwise resembles anything one would see in natural
English or a printed book), in which case one may as well go the
whole way and include the braces (or whatever othe pair of
delimiters you care to use). Conversely, I'm not sure that the
version with braces is much further removed from natural language
than:
if the red door is open
begin;
"You see Mrs Bumble come stumbling through the door.
As she enters the room, she falls flat on her face. ";
move Mrs Bumble into the Lounge;
now Mrs Bumble is prone;
end if;
Though, as noted above, I grant that the appearance is perhaps a
little less code-like.
Note that with the proposed indentation syntax (which may or may not
be properly preserved in this post), we'd have:
if the red door is open
"You see Mrs Bumble come stumbling through the door.
As she enters the room, she falls flat on her face. ";
move Mrs Bumble into the Lounge;
now Mrs Bumble is prone;
Here the indentation within the quoted string (intended to show that
it's a continuation of the previous line) becomes harder to
distinguish visually from an indentation intended to show nesting to
a further level:
if the red door is open
"You see Mrs Bumble come stumbling through the door.
As she enters the room, she falls flat on her face. ";
move Mrs Bumble into the Lounge;
if Mrs Bumble is carrying the egg
now the egg is broken;
"The egg she was carrying in her right hand smashes on
impact,
spilling yolk and white all over the carpet.";
now Mrs Bumble is prone;
Without explicit delimiters, this becomes increasingly hard to read,
I feel. I also suspect that without explicit delimiters the
potential for subtle and hard to trace bugs becomes that much more.
E.g., it would be easy for the above to be mis-coded as
if the red door is open
"You see Mrs Bumble come stumbling through the door.
As she enters the room, she falls flat on her face. ";
move Mrs Bumble into the Lounge;
if Mrs Bumble is carrying the egg
now the egg is broken;
"The egg she was carrying in her right hand smashes on
impact,
spilling yolk and white all over the carpet.";
now Mrs Bumble is prone;
And possibly harder to spot why Mrs Bumble doesn't end up prone when
she enters the room without the egg (espcially for an author seeing
what s/he expects to see when trying to track down the error in
his/her own code).
That said, I'd otherwise like to echo Aaron's thanks for a most
interesting document; in the main the directions indicated look
pretty encouraging.
-- Eric
d...@pobox.com
On Jan 18, 11:46 pm, "Emily Short" <emsh...@mindspring.com> wrote:
> A few weeks ago I promised to post something on the current and future
> state of Inform "in a week or so". This document turned out to take us
> longer than I expected, but it is also more thorough than I originally
> anticipated. We're open to feedback, as always.
An admirable work. Thanks.
drj
d...@pobox.com
On Jan 18, 11:46 pm, "Emily Short" <emsh...@mindspring.com> wrote:
> 2(a). It has an ideology
2a. I'm so glad you admit this. It's probably the single most
important thing to know about where Inform 7 is heading.
> 4. Inform 7 for Linux?
4. You're cutting off your nose to spite your face because of 2a. You
don't want users if they aren't zealots.
> (6.1) -- a more thorough elucidation of syntax:
6.1 hurray, and (6.2) good luck.
> (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.3 hurray.
> (6.4) -- a more programmer-oriented and less inductive approach to the
> language: same concerns, really.
6.4 hurray, but it doesn't seem remotely consistent with 2a.
> 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."
>
6.22 Significant white-space seems like a good match for Inform 7 and
my experience with Python suggests that its livable with. I'm probably
with Andrew Plotkin re Python: its white-space syntax may well be one
of the worst features but its certainly the least-horrible
most-horrible language feature of all languages. Practical observation
from Python: there are no holy wars about bracing style (where to put
the '{' and '}', or "begin" and "end if"): More code (from different
programmers) looks the same.
Of course, using tabs is stupid and wrong and should not be tolerated.
> (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.24 Hurray! Good luck with "not".
> (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.25 Doesn't "if Mrs Wandering-Monster has..." only use more space if
the author asks for it? You only have to keep track of those objects
and properties whose historical record is requested.
> (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.29 As a move towards the flexibility and power of Common Lisp's
defmethod of course I support this.
> (6.33) -- variables whose scope is the lifetime of a rulebook being
> followed.
6.33 aka dynamic binding aka special variable (Common Lisp). Naturally
a good idea. Even better if actually implemented a general dynamic
binding feature rather than this special case.
> (6.39) -- for the action library to be rewritten in Inform 7.
6.39 What is the motivating factor here? Is it that people want the
action library to be more thoroughly documented?
> (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.
6.43 As things stand is a state that is stupid and wrong and should not
be tolerated.
> (6.51) -- implementation of scenes as objects that can themselves
> belong to kinds, with associated behaviors and hierarchies.
>
> 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.51 Really I see this as a consequence of the bogus distinction
between values and objects. And if you provide "features for handling
values like objects, or vice versa, which render the question moot",
then maybe you will too.
> (6.55) -- for the device kind to be withdrawn and a "switchable"
> attribute used instead.
6.55 Aside: give something the property "Inform library switchable" and
it's perfectly happy to be a switch. I like this.
> (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.
6.59 Oh look properties are just functions on things. See
rules/properties unification.
> (6.64) -- archiving of the current system used
6.64 I think that you should recommend that anyone publishing a work
also archive the version of Inform 7 used to create it. I already do
that simply so that I can continue to use the references to the Inform
7 documentation that I've placed in my comments. It's not enough for
me to reference a particular section of the documentation by number
because that changes from release to release, so I have to include the
Inform 7 release number too.
>
> USER INTERFACE
This whole section has the smell of "we like both sorts of music here:
country _and_ western" to it.
> 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.
6.66 No-one ever wrote a book in a single file. The eBooks comment
confuses presentation with creation. Sure, if I want to show my source
code to someone give me a presentation option that makes it into a
single long "eBook", but don't expect me to write it like that.
BBEdit and Xcode (not to mention of course vi and emacs) allow the
author many many navigation options, but in particular a drop down that
can be used to jump to any definition of a function / class / section.
That sounds like a good addition to me. No, not by going to the Index
panel. This is independent of any decision to make the editor folding,
or restricted to single chapters, or operate on multiple files. It may
well ease the pain that some people have. Right-click "go to
definition" would move the IDE more towards modern expectations too.
> (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.67 My favourite suggestion here, which I don't think I've submitted a
"bug report" for, is that the map be live and update as one plays the
game.
> (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.70 Materials that support the design and creation of a work are
different from materials that are included in the published form.
Seems dangerous to conflate the two.
> (6.75) We do not
> observe any reticence on the part of Inform users in reporting bugs
> now.
6.75 How would one observe a reticence?
> (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.
6.77 what would double clicking on a node past the merge point mean?
Play both (all) branches through to that point?
drj
vaporware
> > We propose a major syntactic change, breaking more or less
> > every passage of I7 source text yet written.
> [ ... snip explanation of indentation signifying block level ... ]
>
> Another possibility is wiki-style bullet points:
>
> if the tree is green
> * change x to 2
> * now the squirrel is in the tree;
> say "How dark and foreboding is the house."
>
> Deeper levels are signified with more asterisks ("**"). The ending
> semi-colon is still needed when the indentation level goes from 1 to 0
> (after "the squirrel is in the tree"), but is otherwise optional (since a
> group of "*"s signifies the end of the previous command).
I like this. It doesn't depend on easily broken whitespace, and it's
more natural than indentation: outlines are used to show ordered
hierarchy in printed works. Indentation is sometimes used for
paragraph-sized quotations, but it's rarely nested.
vw
Blank
> "Emily Short" <ems...@mindspring.com> wrote in message
>
>> COMPILATION AND PROBLEM REPORTING
>> (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).
>
> How about this: If the setting is z5 and compilation fails because it does
> not fit, automatically set it to z8 and start the compile again (leaving the
> setting at z8 afterwards and informing the user that this has been done).
> Then it would take twice as long to compile the first time, but be fine from
> then on.
>
>> PHRASES
>> We propose a major syntactic change, breaking more or less
>> every passage of I7 source text yet written.
> [ ... snip explanation of indentation signifying block level ... ]
>
> Another possibility is wiki-style bullet points:
>
> if the tree is green
> * change x to 2
> * now the squirrel is in the tree;
> say "How dark and foreboding is the house."
>
> Deeper levels are signified with more asterisks ("**"). The ending
> semi-colon is still needed when the indentation level goes from 1 to 0
> (after "the squirrel is in the tree"), but is otherwise optional (since a
> group of "*"s signifies the end of the previous command).
>
I think the above is much better than using invisible markers in the
text. I have enough trouble working out why my code isn't working
without having to worry about whether it's because the code window is
showing when it should be showing instead.
jz
John Roth
That's a very common, if somewhat overstated, reaction to
Python's use of indentation for block structure. There's also
a counterpoint - most people who actually try using Python
for a while discover that their objections vanish within a half
hour or so.
Calling it "significant whitespace" is disingenous. While that's
technically true, it's significant in only one very specific, although
admittedly important, context.
The problems with moving code around are pretty messy,
and I doubt if there's ever going to be movement on fixing
HTML and various mail clients. However, they're solvable.
The solution I would prefer is to use a different transportation
syntax: the current syntax would do, as would a braces
notation. Then the IDE could translate when it detected the
transportation syntax.
I suppose therer are a few people who have to use Python
for work requirements, and hate the indentation with a
passion. However, I've never heard of one.
So, to model your rant, I dismiss opinions such as yours
as the deranged ranting of someone with absolutely no
practical experiance of what they're babbling about.
John Roth
Stuart Moore
> I will, assuredly, be continuing to use the Old Style, probably for I7's
> lifespan, and I applaud the designers' realization that some sort of
> switch to provide for extant code is required. In general, it is my
> considered opinion that syntactically-significant whitespace is the
> devil's handiwork, and that those who advocate its use are, by and
> large, syphilitic feces-flinging crack-monkeys.
I take it, then, that you are not a fan of Python? In all honesty, I'd
prefer the whitespace method to the "begin...end" method, myself, so
long as you could use any amount of whitespace to delineate, and not
just an arbitrary amount.
--
Stuart "Sslaxx" Moore
http://sslaxx.livejournal.com/
Adam Thornton
Stuart Moore <N...@SPAM.HERE> wrote:
>Adam Thornton wrote:
>> In general, it is my
>> considered opinion that syntactically-significant whitespace is the
>> devil's handiwork, and that those who advocate its use are, by and
>> large, syphilitic feces-flinging crack-monkeys.
>
>I take it, then, that you are not a fan of Python?
Python is a very nice language, except for the whitespace issue.
Which is much like saying [SPOILER] that Quirinus Quirrell was a pretty
good Defense Against The Dark Arts professor, except for the fact that
he had Voldemort growing out of the back of his head.
It would be correct to presume that most of my little glue programs are
still written in Perl rather than Python.
Adam
Adam Thornton
vaporware <jmc...@gmail.com> wrote:
>David Fisher wrote:
>> if the tree is green
>> * change x to 2
>> * now the squirrel is in the tree;
>> say "How dark and foreboding is the house."
>>
>> Deeper levels are signified with more asterisks ("**"). The ending
>> semi-colon is still needed when the indentation level goes from 1 to 0
>> (after "the squirrel is in the tree"), but is otherwise optional (since a
>> group of "*"s signifies the end of the previous command).
>I like this. It doesn't depend on easily broken whitespace, and it's
>more natural than indentation: outlines are used to show ordered
>hierarchy in printed works. Indentation is sometimes used for
>paragraph-sized quotations, but it's rarely nested.
However, this does break the natural language aspect on which Graham is
so keen. That said, nested loops break natural language, but they are a
practical necessity for those of us writing I7 games.
I find some sort of non-whitespace syntactic-nesting-level marker much
more palatable, personally, than significant indentation. It is, of
course, not my language to design, and being some 50,000 words into my
WIP, I'm not going to start over in another language even if I7 *does*
take the hideous turn to syntactic whitespace.
Adam
Neil Cerutti
> On 18 Jan 2007 21:17:59 -0800, "ChicagoDave"
> <david.c...@gmail.com> tried to confuse everyone with this
> message:
>>> Adam Thornton wrote:
>>> This makes my brain bleed.
>>>
>>> I will, assuredly, be continuing to use the Old Style, probably for I7's
>>> lifespan, and I applaud the designers' realization that some sort of
>>> switch to provide for extant code is required. In general, it is my
>>> considered opinion that syntactically-significant whitespace is the
>>> devil's handiwork, and that those who advocate its use are, by and
>>> large, syphilitic feces-flinging crack-monkeys.
>>
>>Normally I give you guys (Emily and Graham) a wide amount of
>>latitude in my first reactions to things.
>>
>>This will not be one of those times.
>>
>>I agree with Adam.
>
> Me too. In light of this I may even start developing LIFP again
> (and the result won't be pretty!)
I can't understand why this (possible) decision is generating so
much angst. Lacking arguments to rebut, I will cast my vote with
the proposal.
How is this problem handled in everyday English? The answer is,
I think, that it doesn't come up. There's no everyday English
convention for Inform 7 to use, so something transparent and
simple (semantic indentation), seems like a good idea. It beats
"begin" and "end" soundly, at least. Are there any other ideas?
It will be necessary to forbid the mixing of spaces and tabs. My
preference is to forbid tabs completely, but some people still
swear by them, despite their disadvantage of being unportable.
Decent editors will be configured to insert the correct number of
spaces to come to a tab stop when you press tab. The Inform 7 IDE
will most likely need to be augmented with block-selection and
block-indent-change commands to make this work seemlessly.
But I'm sensitive to how other programmers feel about I7 syntax.
Feelings are important; perhaps important enough to quash this
idea.
--
Neil Cerutti
Blank
I agree. "Writing IF is like writing a book" is only a metaphor. We're
not writing a book, we're writing unambiguous text that can be parsed by
a dumb bit-bucket. Metaphors are all very well, but if it starts
dictating that a poor tool be chosen over a useful tool, it's time to
wave it goodbye.
I wonder if nesting brackets of different types would be useful. So an
if clause would be either
(if condition, do this; do this; do this; otherwise do this; ...)
or
{if condition, do this; do this; ... otherwise do this; do this;}
That would let us write code like this-
Every turn when the player is in the elegant dining room:
(if the red door is open and Mr Fumblefingers is not in the dining room,
now Mr Fumblefingers is in the dining room; say "Mr Fumblefingers
hurries through the door, stumbling over the frayed carpet and "; {if Mr
Fumblefingers is carrying the loaded tray, try Mr Fumblefingers trying
dropping the loaded tray; otherwise say "waving his arms wildly to
steady himself.";} otherwise say "You hear muffled sounds from the other
side of the door.";) Say "The clock ticks loudly."
jz
Neil Cerutti
> Note that with the proposed indentation syntax (which may or
> may not be properly preserved in this post), we'd have:
>
> if the red door is open
A colon, as in Python, will not go amiss.
> "You see Mrs Bumble come stumbling through the door.
> As she enters the room, she falls flat on her face. ";
> move Mrs Bumble into the Lounge;
> now Mrs Bumble is prone;
The convention in I7 is to have no line break in the string, so
how it wraps is up to the IDE. Right now, it does this, which
makes my attempts at block structure a failure.
if the red door is open:
"You see Mrs Bumble come stumbling through the door. As she
enters the room, she falls flat on her face. ";
move Mrs Bumble into the Lounge;
now Mrs Bumble is prone;
> Here the indentation within the quoted string (intended to show
> that it's a continuation of the previous line) becomes harder
> to distinguish visually from an indentation intended to show
> nesting to a further level:
>
> if the red door is open
> "You see Mrs Bumble come stumbling through the door.
> As she enters the room, she falls flat on her face. ";
> move Mrs Bumble into the Lounge;
> if Mrs Bumble is carrying the egg
> now the egg is broken;
> "The egg she was carrying in her right hand smashes on
> impact,
> spilling yolk and white all over the carpet.";
> now Mrs Bumble is prone;
>
> Without explicit delimiters, this becomes increasingly hard to
> read, I feel. I also suspect that without explicit delimiters
> the potential for subtle and hard to trace bugs becomes that
> much more. E.g., it would be easy for the above to be mis-coded
> as
The IDE should be in charge of making this look good, with the
option to allow the programmer to insert line-breaks and
indentation way he or she prefers. A line-continuation marker,
inserted by the IDE at an apposite indentation level would be
nice. Imagine the backslash below appears in pale-red. A little
arrow would be nicer.
If the red door is open:
"You see Mrs Bumble come stumbling through the door.
\As she enters the room, she falls flat on her face. ";
move Mrs Bumble into the Lounge;
if Mrs Bumble is carrying the egg
now the egg is broken;
"The egg she was carrying in her right hand smashes on
\impact, spilling yolk and white all over the carpet.";
now Mrs Bumble is prone;
--
Neil Cerutti
Andrew Plotkin
will incur somebody's wrath.)
Would the deeper level look like
if ...
* do ...
* if ...
** do ...
** do ...
Or would it look like
if ...
* do ...
* if ...
* * do ...
* * do ...
Here's my problem with this idea: it requires just as much editor
support as whitespace indentation. The editor needs to be able to
insert a new row of stars, matching the previous line, when I hit
enter. If I'm using the second format (which I would, since I use tab
indentation *now* and will continue to) the editor should be able to
add and delete the star-tab combo with single keystrokes -- in fact,
when I hit tab or delete. It will certainly need commands to star-up
or star-down the selected region of lines. And it need to (continue
to) support the current IDE preference for tab width.
But if you have that level of editor support, most of the objections
to whitespace indentation are solved anyway. At that point, you might
as well just add a IDE preference "visible tabs" which draws a
medium-grey asterisk at the left edge of each tab in the document.
You still need to convert the source to ASCII asterisks when you're
saving and copying-out. But, as I said, the editor already needs to
convert tabs to spaces; it would be part of the same operation.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't thrown you in military prison without trial,
it's for one reason: they don't feel like it. Not because you're an American.
Stephen Granade
> Here's my problem with [the wiki * convention] idea: it requires
> just as much editor support as whitespace indentation. The editor
> needs to be able to insert a new row of stars, matching the previous
> line, when I hit enter. If I'm using the second format (which I
> would, since I use tab indentation *now* and will continue to) the
> editor should be able to add and delete the star-tab combo with
> single keystrokes -- in fact, when I hit tab or delete. It will
> certainly need commands to star-up or star-down the selected region
> of lines. And it need to (continue to) support the current IDE
> preference for tab width.
>
> But if you have that level of editor support, most of the objections
> to whitespace indentation are solved anyway. At that point, you might
> as well just add a IDE preference "visible tabs" which draws a
> medium-grey asterisk at the left edge of each tab in the document.
>
> You still need to convert the source to ASCII asterisks when you're
> saving and copying-out. But, as I said, the editor already needs to
> convert tabs to spaces; it would be part of the same operation.
In fact, this would be my preference: have the IDE show the indention
through grey symbols of some kind and have it fiddle on
saving/loading.
Stephen
--
Stephen Granade
stephen...@granades.com
jameshcu...@gmail.com
> In article <eoql8t$5td$1$8302b...@news.demon.co.uk>,
> Stuart Moore <N...@SPAM.HERE> wrote:
>
> >Adam Thornton wrote:
> >> In general, it is my
> >> considered opinion that syntactically-significant whitespace is the
> >> devil's handiwork, and that those who advocate its use are, by and
> >> large, syphilitic feces-flinging crack-monkeys.
>
>
> Which is much like saying [SPOILER] that Quirinus Quirrell was a pretty
> good Defense Against The Dark Arts professor, except for the fact that
> he had Voldemort growing out of the back of his head.
I take it, then, that you have *practical* objections to Python's use
of whitespace? Given what's at stake here - the future of Inform 7,
your significant standing in the community giving you more sway than
someone like me - I'll assume that you've at least used Python and had
some difficulties with it.
If not, then I suggest you do so. After many thousands of lines of
Python code, I've quite literally never had a problem with it; no one
who is more experienced than I am ever seems to have a problem with it;
and most of its denouncements are very much of the "what if" sort. Use
of any number of decent, free, Python-aware editors (I'm told you like
emacs) means almost never even having to think about it at all.
(There are many valid reasons to dislike Python. Whitespace is not one
of them.)
>
> It would be correct to presume that most of my little glue programs are
> still written in Perl rather than Python.
I just threw up a little in my mouth. Thanks, Adam.
>
> Adam
Best,
James
Adam Thornton
jameshcu...@gmail.com <jameshcu...@gmail.com> wrote:
>I take it, then, that you have *practical* objections to Python's use
>of whitespace? Given what's at stake here - the future of Inform 7,
>your significant standing in the community giving you more sway than
>someone like me - I'll assume that you've at least used Python and had
>some difficulties with it.
I've used it some. I am not by any means an expert. I haven't written
anything large and original in it; mostly I've had to find bugs in other
people's Python.
I find tabdamage and, in general, damage incurred by passing the source
around via email without attaching it, to be problematic.
>(There are many valid reasons to dislike Python. Whitespace is not one
>of them.)
What are some of the others? Otherwise it strikes me as a rather nice
language.
>> It would be correct to presume that most of my little glue programs are
>> still written in Perl rather than Python.
>
>I just threw up a little in my mouth. Thanks, Adam.
At least Perl *knows* it's ugly. To be honest, *my* Perl isn't even
*really* Perl 5. It's Perl 4-and-a-half that reads, essentially, like
Bourne Shell with better string handling, better arithmetic handling,
and regexps. Given what I use it for, which is "glue between other
things in places where I need something a bit studlier than a nasty bash
one-liner," it works well for me. I don't doubt that for actual
applications Python is much preferable.
Adam
Adam Thornton
Andrew Plotkin <erky...@eblong.com> wrote:
>But if you have that level of editor support, most of the objections
>to whitespace indentation are solved anyway. At that point, you might
>as well just add a IDE preference "visible tabs" which draws a
>medium-grey asterisk at the left edge of each tab in the document.
Oh, all right. You aren't *ALL* poo-flinging monkeys. I promise not to
go on a homicidal rampage if I7 moves to significant whitespace. I'll
just sulk quietly to myself.
Adam
Emily Short
Eric Eve wrote:
> I'm not sure I feel as strongly as that (or, at least, that I would
> wish to express myself as strongly at that), but this was the
> proposal that made me feel the most uneasy, and my initial gut
> reaction is to hope that it gets dropped. Is the intention that the
> same indenting would also replace the existing syntax for repeat and
> while loops? If not then introducing an indexing syntax for if while
> retaining begin... end repeat/end while would seem to be introducing
> another needless inconsistency into the language.
Just to clarify (I don't want to join into the argument itself until
people have had a bit more chance to air their thoughts): yes, this
would apply to all forms of block structure, including while and repeat
as well as if/otherwise and so on. This would unify the handling of
these blocks and remove the annoyance some users feel when they
accidentally type "end if" instead of "end repeat" out of habit.
(I realize that using brackets would also have both of those effects;
that's a different argument, and, as I said, I just want to make the
proposal clear, for now.)
Emily Short
making any arguments myself, so just to answer the points where I can
clarify:
> > (6.39) -- for the action library to be rewritten in Inform 7.
>
> 6.39 What is the motivating factor here? Is it that people want the
> action library to be more thoroughly documented?
Well, yes, but more thoroughly documented in a specific way: one that
will provide a template version of the code so that authors can easily
tweak and replace rules from library actions.
> BBEdit and Xcode (not to mention of course vi and emacs) allow the
> author many many navigation options, but in particular a drop down that
> can be used to jump to any definition of a function / class / section.
> That sounds like a good addition to me.
The Mac IDE already has a header-navigation dropdown; this is
definitely in.
d...@pobox.com
On Jan 19, 5:31 pm, a...@fsf.net (Adam Thornton) wrote:
> In article <1169226969.563976.229...@l53g2000cwa.googlegroups.com>,
>
> jameshcunning...@gmail.com <jameshcunning...@gmail.com> wrote:
> >(There are many valid reasons to dislike Python. Whitespace is not one
> >of them.)
> What are some of the others? Otherwise it strikes me as a rather nice
> language.
Just the usual: annoying statement / expression distinction, which
really blows up when you try and use lambda; bizarre scoping rules and
incomplete closures; failing to unify foo.x and foo['x'].
It's probably my 3rd favourite language, and my 2nd favourite language
that I can actually get paid to write in (I've not been paid to write
Lisp yet), and my favourite language for those adorable glue programs
(like the one I just wrote to compute and optionally fix checksums in
glulx files).
FWIW before I started writing seriously in Python (that is, for money)
I too though that the whitespace thing was batshit insane. I got over
it by line 1000 or so.
drj
-
> On 2007-01-19, Timofei Shatrov <gr...@mail.ru> wrote:
>> On 18 Jan 2007 21:17:59 -0800, "ChicagoDave"
>> <david.c...@gmail.com> tried to confuse everyone with this
>> message:
>>>> Adam Thornton wrote:
>>>> This makes my brain bleed.
>>>>
>>>> I will, assuredly, be continuing to use the Old Style, probably for I7's
>>>> lifespan, and I applaud the designers' realization that some sort of
>>>> switch to provide for extant code is required. In general, it is my
>>>> considered opinion that syntactically-significant whitespace is the
>>>> devil's handiwork, and that those who advocate its use are, by and
>>>> large, syphilitic feces-flinging crack-monkeys.
>>> Normally I give you guys (Emily and Graham) a wide amount of
>>> latitude in my first reactions to things.
>>>
>>> This will not be one of those times.
>>>
>>> I agree with Adam.
>> Me too. In light of this I may even start developing LIFP again
>> (and the result won't be pretty!)
>
> I can't understand why this (possible) decision is generating so
> much angst. Lacking arguments to rebut, I will cast my vote with
> the proposal.
>
> How is this problem handled in everyday English? The answer is,
> I think, that it doesn't come up.
When writing technical documentation, one sometimes wants to elucidate a
concept using predicate logic. Structured text of the form:
WHEN <condition>
<action>
.
.
.
OTHERWISE
<action>
.
.
.
can be more appropriate than equivalent English (long-winded)
statements. The typographic convention employing indentation yields
acceptable results. There are times, of course, when one augments the
predicate using narrative text.
> There's no everyday English convention for Inform 7 to use,
> so something transparent and
> simple (semantic indentation), seems like a good idea. It beats
> "begin" and "end" soundly, at least. Are there any other ideas?
>
> It will be necessary to forbid the mixing of spaces and tabs.
Why?
> My preference is to forbid tabs completely, but some people still
> swear by them, despite their disadvantage of being unportable.
Why? Are we talking about allowing I7 text to be edited outside the IDE?
Therefore, shouldn't the tab indentation level should be a
user-configurable item?
> Decent editors will be configured to insert the correct number of
> spaces to come to a tab stop when you press tab