Inform 7: Possible future developments

[Emily Short]

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.

-- 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]

Much thanks for this inside look into what's going on with I7. I've run
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]

In article <1169164007....@a75g2000cwd.googlegroups.com>,

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]

"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).

> (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]

Adam Thornton wrote:
> 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]

David Fisher wrote:
> > (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]

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*.

--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]

Here, Aaron A. Reed <aar...@gmail.com> wrote:
>
> 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]

In article <eophcg$p2p$2...@reader2.panix.com>,

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, 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*.

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]

> 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.

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]

Here, ChicagoDave <david.c...@gmail.com> wrote:
>
> 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]

> ChicagoDave wrote:
> 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]

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!)

--
|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]

"ChicagoDave" <david.c...@gmail.com> wrote in message
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]

David Fisher wrote:
> "Emily Short" <ems...@mindspring.com> wrote in message

[...]

> > 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]

David Fisher wrote:
> "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]

Adam Thornton wrote:
> 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]

In article <eoql8t$5td$1$8302...@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.
>
>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]

In article <1169211945....@11g2000cwr.googlegroups.com>,
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 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. 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]

On 2007-01-19, Eric Eve <eric...@NOSPAMhmc.ox.ac.uk> wrote:
> 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]

(The nice thing about this topic is that anything Graham chooses to do
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]

Andrew Plotkin <erky...@eblong.com> writes:

> 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]

On Jan 19, 10:29 am, a...@fsf.net (Adam Thornton) wrote:
> 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.
>

> >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.

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]

In article <1169226969.5...@l53g2000cwa.googlegroups.com>,

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]

In article <eoqs1n$9be$1...@reader2.panix.com>,

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]

For now (as I say elsewhere) I'd like to let people discuss before
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

[-]

Neil Cerutti wrote:
> 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.

Why? Isn't the I7 IDE the /only/ choice for producing I7 code? In other
words, will there be more than one "decent editor"?

> The Inform 7 IDE will most likely need to be augmented with block-selection and
> block-indent-change commands to make this work seemlessly.

Agreed. I hope that the owners will consider source code elision at all
levels, not just chapter (ref. 6.66(a))

> But I'm sensitive to how other programmers feel about I7 syntax.
> Feelings are important; perhaps important enough to quash this
> idea.

Some programmers coming to Python from other languages quickly adjust.
Those learning I7 will learn that as part of the language. Perhaps
others will find E. Raymond's post on this topic informative
(http://www.linuxjournal.com/article/3882).

[d...@pobox.com]

On Jan 19, 5:52 pm, "Emily Short" <emsh...@mindspring.com> wrote:
> For now (as I say elsewhere) I'd like to let people discuss before
> 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.

I looked for this after you said it was in and didn't find it. So I
looked again. And found it.

That's a not a dropdrown it's a disclosing tree. In a separate window.
It sucks.

drj

[Adam Thornton]

In article <1169229122....@a75g2000cwd.googlegroups.com>,

Emily Short <ems...@mindspring.com> wrote:
>The Mac IDE already has a header-navigation dropdown; this is
>definitely in.

It gets confused a lot, in my experience, on a 50kword source file,
though. So does the font handling in the IDE. However, compilation
proceeds fine, so it's not an actual structural problem with the code.

Adam

[Emily Short]

Adam Thornton wrote:
> In article <1169229122....@a75g2000cwd.googlegroups.com>,
> Emily Short <ems...@mindspring.com> wrote:
> >The Mac IDE already has a header-navigation dropdown; this is
> >definitely in.
>
> It gets confused a lot, in my experience, on a 50kword source file,
> though.

Yes, it sounds as though there may still be some bugs in it; this is
something we'll try to address, especially if people have sample
evidence.

The nature of the problem is obviously such that the standard bug
report may not be appropriate, of course; if anyone has held off
reporting something like this through being unsure how to send
appropriate documentation, email me and we can talk about what's
sensible.

[Emily Short]

Ah. Then perhaps I'm failing to envision correctly what you do have in
mind.

[Neil Cerutti]

On 2007-01-19, d...@pobox.com <d...@pobox.com> wrote:
> 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'].

Check out Python Warts, an excellent and as objective as might be
hoped critique of Python's worst features. Note that many of them
have been fixed in the last several versions.

http://www.amk.ca/python/writing/warts

I'm personally annoyed by the clunky print statement. But it's
easy to ignore in my own code, and no interesting, real code can
really use it, anyhow.

I'm not sure I understand what you mean by failure to unify foo.x
and foo['x']. The power of descriptors particularly impresses me,
and the other neat way sof manipulating attribute access make
Python very flexible. I can imagine it can make code harder to
interpret.

> 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.

The worst disadvantage of it is that if leading whitespace is
stripped from a program (as sometimes happens in various
transformations Python code on the web (especially on crap web
forums)), it is impossible to automatically recover the correct
code. Opening and closing markers are very annoying, but code
can't lose its meaning despite borked formatting.

--
Neil Cerutti

[Neil Cerutti]

On 2007-01-19, Emily Short <ems...@mindspring.com> wrote:
> For now (as I say elsewhere) I'd like to let people discuss before
> 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.

Yay! <clap, clap, clap, clap>

--
Neil Cerutti

[solar penguin]

David Fisher wrote:

> 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).

That looks good. Definitely more readable than trying to count
whitespace or keep track of too many begin/end if statements.

[Neil Cerutti]

On 2007-01-19, - <x...@x.com> wrote:

> Neil Cerutti wrote:
>> It will be necessary to forbid the mixing of spaces and tabs.
>
> Why?

Because then you cannot tell by sight if two lines really have
the same amount of leading white-space.

>> 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?

Yes, even when all tabs are automatically translated to spaces on
the fly, it is user configurable. Other users won't be able to
easily reconfigure it to their own preference, but it's not too
hard to do. In Vim, :set noet, :retab, :ts=N, :retab, :set et.

>> Decent editors will be configured to insert the correct number
>> of spaces to come to a tab stop when you press tab.
>
> Why? Isn't the I7 IDE the /only/ choice for producing I7 code?
> In other words, will there be more than one "decent editor"?

I hope it doesn't remain that way. Plus, I'm starting to feel
really guilty about asking for all these new feature while not
helping David out with any patches.

>> The Inform 7 IDE will most likely need to be augmented with
>> block-selection and block-indent-change commands to make this
>> work seemlessly.
>
> Agreed. I hope that the owners will consider source code
> elision at all levels, not just chapter (ref. 6.66(a))
>
>> But I'm sensitive to how other programmers feel about I7
>> syntax. Feelings are important; perhaps important enough to
>> quash this idea.

--
Neil Cerutti

[Adam Thornton]

In article <eor1j5$rh6$1...@aioe.org>, - <x...@x.com> wrote:
>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.
>
>Why? Isn't the I7 IDE the /only/ choice for producing I7 code? In other
>words, will there be more than one "decent editor"?

That's an interesting question. It would be nice if one could use other
editors, but I get the strong impression that this does not align with
Graham's vision.

>Some programmers coming to Python from other languages quickly adjust.
>Those learning I7 will learn that as part of the language. Perhaps
>others will find E. Raymond's post on this topic informative
>(http://www.linuxjournal.com/article/3882).

Yeah, I've read it before and I still find significant whitespace hard
to deal with. I do, however, realize that I probably have a stronger
personal animus than most people in this newsgroup--I've also had to
maintain other people's COBOL and, to a lesser extent, dinosaur-era
FORTRAN.

Adam

[Adam Thornton]

In article <1169230921....@q2g2000cwa.googlegroups.com>,

Emily Short <ems...@mindspring.com> wrote:
>Yes, it sounds as though there may still be some bugs in it; this is
>something we'll try to address, especially if people have sample
>evidence.

The problem with the sample evidence is that I can't narrow it down. On
small projects, it seems to work fine. On my humongous
work-in-progress, it doesn't. Sometimes. It does seem to be tightly
coupled to whether or not the syntax-colorer gets it right, though: if
the syntax colorer sees all the headings, the navigator has it right
too.

Sometimes manually inserting and deleting line feeds will get the
colorer to recognize the headings and sometimes it will not.

And right this minute, for instance, it's got it exactly correct, as far
as I can tell: ten volumes, and the subheadings under each are correct.
It seems to get more confused the longer I work on it, for whatever
*that*'s worth.

Adam

[ChicagoDave]

> Emily Short wrote:
> 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.

Okay. The crashing vision of the whitespace issue has mostly subsided
and I'm ready to discuss this more openly. I understand the "problem",
in that the Begin and End statements are verbose, don't necessarily
align with "natural language", and are ugly to read.

Where to go from here?

It seems the ideology of I7 has always been to try to push things
towards a uniform syntax. For most things, I would agree with this
process. But one of the things I believe very strongly is that one tool
doesn't fit all problems. Inform 7 is already a "domain specific
language", as is TADS, Inform 6, Hugo, and other IF directed syntaxes.
But Inform 7 has taken on the heavyweight role of trying to mimic
written language. In most aspects of the Inform 7 syntax I would say
this works very well. I think the ability to map out a world has been
dramatically improved. The rulebooks have spaked a revolution in
theories about how IF can or should be constructed.

But natural language syntax can only go so far. The DSL faces
fragmentation. Instead of tap-dancing around this fact, why not embrace
it?

Let's simply admit that control blocks don't have a natural-language
equivalent and implement a logical structure for this portion of the
syntax.

Well, you've sort of done that by proposing the indentation solution,
which I really dislike. I've never used Python and don't plan to, but
this seems like a fragmentation that has a narrow appeal and where
Python is concerned, a sizable voice against its whitespace
requirements.

I think proposing a non-natural-language syntax for control blocks is a
good idea. But can we debate different styles first?

What programming syntaxes are used to handle logical control blocks?
1. C-like squiggly brackets.
I like it, but it doesn't seem to "fit" into the IF 7 look and feel
and might scare
non-programmers into thinking they've been hood-winked into
learning how to code.
2. Parenthesis
Not bad. Fits with natural language in the sense that it's used in
mathematical and logical expressions.
Still suffers from a bit of confusion with squiggly brackets.
3. Square brackets
Already used to tokenize things in I7. Not really an option.
4. Whitespace
My biggest complaint about this is that by its very nature, you
can't "see" the usage if the code is
accidentally mis-aligned. This, to me, is a fundamental flaw in
using whitespace as a logical construct
in source that will be compiled. It's great for reading, but a
compiler has to deduce meaning, and the
compiler isn't going to care if you made a mistake or gobs of your
source is mis-aligned.
5. Requiring End If, End Instead, etc.
I'm not sure why this is such a horrible thing. BASIC has been
using it for decades and has always been
associated with novice programmers, which is one of the concerns in
designing the syntax "nicely". It's
verbose, but would get rid of the Begin/End statements entirely.

I don't see any other solutions off the top of my head.

I would order these by preference as 5, 2, 1, 4, (ignoring 3).

David C.

[JDC]

I've encountered (I think) the same thing as Adam (in OS X build 3V01);
occassionally the syntax-highlighting would stop or skip sections of
the code, and the correspoinding sections disappear from the heading
dropdown. You could get it working again by finding the point where it
was stopping to work and inserting some text there (hitting enter and
then deleting the line feed again worked for me). I haven't started
anything substantial in the more recent builds. I also never found a
definite pattern for this, but my guess was something to do with a
limited number of context lines in the syntax highlighting.

That aside, I find the heading dropdown very useful (I had been using
the Inspector before this was available, which provided similar
functionality).

-JDC

[d...@pobox.com]

I guess I was being even more cryptic than is usual for me. Sorry
about that. Also please be noted that "it sucks" was my inconsidered
opinion after only a few seconds of using it.

I had kind of hoped that you'd look at Xcode or BBEdit (I don't use
BBEdit, I just watch over the shoulders of those who enthuse about it)
to see what I mean. I refer you to the following screenshot:

http://www.barebones.com/images/bbedit/function-menu-large.jpg

(referenced from
http://www.barebones.com/products/bbedit/benefitsomnipotence.shtml mmm
textual omnipotence)

Notice how above the buff rectangle where all the text is edited
(nicely shaded to point out where all the tab-stops are) has a strip of
controls just above it. Most of these are drop-down lists (in fact
this strip of controls is more than an homage to Xcode, it's a ripoff
(or, possibly, vice-versa; BBEdit is older than Xcode)). One of them
is labelled "Stkt01_to_MCSX"; this is the current function (er, I guess
the code is perl so it's a subroutine, but whatever). That dropdown
acts like a menu when you click on it, with each item being a function
(or other significant definition, according to the selected language)
that when selected will move the editing cursor to that definition in
the file. The menu is in the same order as the file.

Notice how economical that control is. Just 16 pixels high. And with
one click I can go to any definition in the current file. Much more
convenient that a floaty window which is trying to do too many things
at once. I can't even begin to think what might happen when that
floaty window needs a scrollbar. Perhaps the most convenient thing
about the BBEdit style dropdown is that it's always directly attached
to the editor window.

Some of the other dropdowns and controls on that horizontol strip just
above BBEdit's text area are worth mentioning. The one with the name
of the file on allows other files to be selected. I bet the one with
the book icon goes to the documentation. The one with a green square
lying on top of a white square goes to the "counterpart" (for example
in C, flips between the definition of a function in a .c file and its
prototype declaration in a header file). The one with a # icon goes to
the included files (would be extensions in Inform 7 I guess). Other
aspects of BBEdit that Inform 7 would do well to pay attention to would
be the line numbers in the margin, and the display of the cursors
current line.

I'm not suggesting that you blindly copy BBEdit or Xcode (after all if
I wanted to use those, then I would), but frankly the Inform 7 IDE
looks like its been designed by someone that has no knowledge of the
practices and tools used and refined by developers over the past decade
or so (this ridiculous conceit of a navigation control is just one
example). But of course it does, because (2a) "it has an ideology".
Cynical perhaps, but it definitely feels like the Inform 7 authors are
deliberately avoiding the practice of others because they are
prejudiced against such practice by their "ideology".

drj

[Neil Cerutti]

On 2007-01-19, ChicagoDave <david.c...@gmail.com> wrote:
> But natural language syntax can only go so far. The DSL faces
> fragmentation. Instead of tap-dancing around this fact, why not
> embrace it?
>
> Let's simply admit that control blocks don't have a
> natural-language equivalent and implement a logical structure
> for this portion of the syntax.
>
> Well, you've sort of done that by proposing the indentation
> solution, which I really dislike. I've never used Python and
> don't plan to, but this seems like a fragmentation that has a
> narrow appeal and where Python is concerned, a sizable voice
> against its whitespace requirements.
>
> I think proposing a non-natural-language syntax for control blocks is a
> good idea. But can we debate different styles first?
>
> What programming syntaxes are used to handle logical control blocks?
> 1. C-like squiggly brackets.
> I like it, but it doesn't seem to "fit" into the IF 7 look and feel
> and might scare
> non-programmers into thinking they've been hood-winked into
> learning how to code.

Squiggly brackets are fine. I would prefer semantic indentation,
but would have no problem with brackets of some sort, since I can
then indent my code as I like. Graham has never liked them, as
far as I can tell. ;)

> 2. Parenthesis
> Not bad. Fits with natural language in the sense that it's used in
> mathematical and logical expressions.
> Still suffers from a bit of confusion with squiggly brackets.

Sadly, parenthesis already serve various purposes in Inform 7.

> 4. Whitespace
> My biggest complaint about this is that by its very nature, you
> can't "see" the usage if the code is
> accidentally mis-aligned. This, to me, is a fundamental flaw in
> using whitespace as a logical construct
> in source that will be compiled. It's great for reading, but a
> compiler has to deduce meaning, and the
> compiler isn't going to care if you made a mistake or gobs of your
> source is mis-aligned.

That's really not an issue.

if X:
Do y
Do z
Do a

The error is extremely easy to spot.

> 5. Requiring End If, End Instead, etc.
> I'm not sure why this is such a horrible thing. BASIC has been
> using it for decades and has always been
> associated with novice programmers, which is one of the concerns in
> designing the syntax "nicely". It's
> verbose, but would get rid of the Begin/End statements entirely.

Basic carefully chose words more meaningful than begin and end,
though.

This raises another option for Inform 7: require everything to be
a code block--no more one-sentencers. That way, we could dispense
with begin.

--
Neil Cerutti

[Andrew Plotkin]

Emily was referring to the "Headings" widget in the main window
toolbar. Possibly you've removed that; or maybe you customized your
toolbar months ago and the "Headings" thing appeared after that.

(You also have to have the window toolbar set to Icons or Icon&Text.
The thing doesn't work in Text mode.)

--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.

[Adam Thornton]

In article <8a9sh.1471$G23...@newsreading01.news.tds.net>,

Neil Cerutti <hor...@yahoo.com> wrote:
>That's really not an issue.
>
>if X:
> Do y
> Do z
> Do a
>
>The error is extremely easy to spot.

Yes, but which error?

Did you mean

if X:
Do y
Do z
Do a

or

if X:
Do y
Do z
Do a

?

Adam

[d...@pobox.com]

On Jan 19, 7:03 pm, Neil Cerutti <horp...@yahoo.com> wrote:
>
> I'm personally annoyed by the clunky print statement. But it's
> easy to ignore in my own code, and no interesting, real code can
> really use it, anyhow.

Oh yeah. print. As a statement. What a stupid idea that is in a
language.

>
> I'm not sure I understand what you mean by failure to unify foo.x
> and foo['x']. The power of descriptors particularly impresses me,
> and the other neat way sof manipulating attribute access make
> Python very flexible. I can imagine it can make code harder to
> interpret.

Well, go and have a look at Lua to see what I mean.

> > 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.
> The worst disadvantage of it is that if leading whitespace is
> stripped from a program (as sometimes happens in various
> transformations Python code on the web (especially on crap web
> forums)), it is impossible to automatically recover the correct
> code. Opening and closing markers are very annoying, but code
> can't lose its meaning despite borked formatting.

Hmm, I see. But isn't this kind of braindead lossage only likely to
happen to those people using a web-based forum? I've never seen it be
a problem in a mailing list or on usenet.

drj

[JDC]

I don't necessarily want to see the action library rewritten in I7 (for
the same reasons mentioned of size and efficiciency), but it would be
nice to have the functionality available in I7. Namely, some action
routines call I6 library routines for which there is no I7 equivalent
(things like library messages, for instance, and some more substantial
library routines), so to replace these routines in I7 you either need
to use an I6 inclusion or essentially rewrite the functionality in I7.

So I guess my preference would be to make it +possible* to more easily
write functionally equivalent I7 code, but keep the library in I6. It
would also be nice to somewhere have "I7 translations" of the action
routines (and other internal rules), but I could see this being a lot
of work to maintain separately as the library changes.

-JDC

[Adam Thornton]

In article <1169236192.2...@a75g2000cwd.googlegroups.com>,

<d...@pobox.com> wrote:
>Hmm, I see. But isn't this kind of braindead lossage only likely to
>happen to those people using a web-based forum? I've never seen it be
>a problem in a mailing list or on usenet.

Alas, no.

Those mailing lists that are run by web-portal companies have a tendency
to HTMLify what they send out, in which case runs of whitespace get
badly mangled. Many benighted souls consume their Usenet via Google
Groups, with much the same effect.

This, by the way, is why even exporting a tab as four or eight or
whatever number of spaces, when saving or copying (in the GUI) I7 code,
is not going to be sufficient to allow you to meaningfully paste I7 code
into a newsgroup post. It already takes significant hand-editing for me
to put my code in a Usenet post; I would like this to get easier, not
harder.

In fact, come to think of it, this is really what's at the heart of my
objection to semantic whitespace: life in general, and HTML rendering in
particular (well, and other formatters too, like TeX), teaches us that
we can assume that the width of whitespace is semantically null, and
therefore the "presentation layer" feels free to collapse it if it feels
it makes the presentation prettier.

Making the amount of whitespace semantically relevant breaks this
assumption.

Adam

[JDC]

I actually think the bullet pointers would make it harder for me to
keep track of the indentation, since I focus on the first character on
the line. I think I would have no real coding problems with the
syntactic whitespace; my main concern with it would be the portability,
particularly copying and pasting code samples to and from this group.

Then again, I have nothing particularly against the current system,
either.

-JDC

[JDC]

Adam Thornton wrote:
> In article <eor1j5$rh6$1...@aioe.org>, - <x...@x.com> wrote:
> >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.
> >
> >Why? Isn't the I7 IDE the /only/ choice for producing I7 code? In other
> >words, will there be more than one "decent editor"?
>
> That's an interesting question. It would be nice if one could use other
> editors, but I get the strong impression that this does not align with
> Graham's vision.

My ideal here would be to have the editor behave something like
TeXshop. Namely, there's an editor built into the IDE (I generally
dislike the built-in editor there), but there is the option of opening
an external editor. You can still compile within the IDE, but some of
the functionality only works with the built-in editor (jumping to
errors in the source during compilation, PDF synching). So I often use
my favorite editor (vim, for the record) for hardcore lengthy coding,
but use the built-in editor for simple things, editing where I am doing
frequent searching in the document or recompiling, etc.

-JDC

[d...@pobox.com]

On Jan 19, 7:44 pm, Andrew Plotkin <erkyr...@eblong.com> wrote:
> Here, d...@pobox.com wrote:
>
> > On Jan 19, 5:52 pm, "Emily Short" <emsh...@mindspring.com> wrote:
> > > The Mac IDE already has a header-navigation dropdown; this is
> > > definitely in.
>
> > I looked for this after you said it was in and didn't find it. So I
> > looked again. And found it.
>
> > That's a not a dropdrown it's a disclosing tree. In a separate window.
> > It sucks.
> Emily was referring to the "Headings" widget in the main window
> toolbar. Possibly you've removed that; or maybe you customized your
> toolbar months ago and the "Headings" thing appeared after that.

Aha. Thanks.

I had actually wondered if I had something missing on my toolbar. I
don't remember customising my toolbar, but I could easily be wrong.
Even so, I don't remember a release note to the effect that people with
customised toolbars may be missing out on new default toolbar items. I
did look in preferences to see if my toolbar could be customised;
didn't find anything. In my defence (of my lame ability to find out
how to customise my toolbar) I note that Safari, Mail, and Xcode all
have their "Customise toolbar..." menu items on the View menu. Oh, but
Inform 7 doesn't have a View menu.

But even so, the Headings widget doesn't appear in the toolbar's
default set (at least not the default set advertised by the toolbar
editing panel).

I've now got a dropdown headings thingy on my toolbar. And it doesn't
completely suck. It still looks like it was designed by a hamster on
crystal meth, and the required two-click operation (a normal dropdown
has a one-click operation mode) seems like a deliberate snub. Also
notice how it doesn't give a nice indication of the current heading /
chapter / whatever (unlike the BBEdit control).

Pardon me for barking up the wrong tree. But I think the fact that I
knew what the navigation control was that I wanted and I looked for it
twice but failed to find it, must say something about Inform 7.

>
> (You also have to have the window toolbar set to Icons or Icon&Text.
> The thing doesn't work in Text mode.)

Ha ha. Guess which mode isn't used by the "Inform 7 authors".

drj

[Andrew Plotkin]

OSX apps have always discriminated against people who set their
window toolbars to Text. I am not thrilled about this.

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

If the Bush administration hasn't shipped you to Syria for interrogation, it's

[Rioshin an'Harthen]

"Neil Cerutti" <hor...@yahoo.com> wrote:
> On 2007-01-19, ChicagoDave <david.c...@gmail.com> wrote:
>> 2. Parenthesis
>> Not bad. Fits with natural language in the sense that it's used in
>> mathematical and logical expressions.
>> Still suffers from a bit of confusion with squiggly brackets.
>
> Sadly, parenthesis already serve various purposes in Inform 7.

However, parenthesis might be a good choice.

Consider the current proposal where conditional and iterative statements
would get the character ':' after them, with the whitespace at the front of
the lines being significant.

If the dog is held by a woman:
do something;
Otherwise:
do something else;

Compared to the current

If the dog is held by a woman
Begin;
do something;
Otherwise;
do something else;
End if;

As far as I can recall, nowhere in I7 (except when going to I6), can a
parenthesis follow a colon. Thus, this could be written with parenthesis as

If the dog is held by a woman: (
do something;
) otherwise: (
do something else;
)

if we keep the requirement of the colon from the current proposal. Since
going to I6 from I7 requires the use of (-, a parenthesis by itself after a
colon is unambiguous.

[Aaron A. Reed]

"Me too" on syntax coloring getting reversed on long projects on the
Mac. I'm using the latest build of Inform and this seems to happen
every 15 minutes or so; finding where it gets messed up and playing
with line feeds fixes it.

[Emily Short]

Yeah, I know what you're describing here.

Does anyone have an equivalent problem on Windows, or is this strictly
an OS X thing?

[Neil Cerutti]

It would depend on the semantics of the code, but I'm inclined to
the former. Misplaced (more often missing) brackets have similar
issues in C.

while (x++ != y++)
do(x);
do(y);
printf("%s, %s", x, y);

You have to figure out what it's supposed to do to fix it. A lot
of programmers opt for braces everywhere as a result, of course.

--
Neil Cerutti

[mikegentry]

I have not encountered this in the Windows build, with a project that
is over 30,000 words now.

[Neil Cerutti]

This is usually a synchronization issue. Syntax coloring strategy
tries to avoid reading the entire file by looking backward or
forward through the code to find a place where the code context
is unambiguous. This may or may not be easy with Inform 7, but
anyway, the synch code is failing when you see this happen.
Moving around to a place in the code where the synching
assumption holds true, and do whatever causes syntax coloring to
refresh (editing some text), fixes the issue.

--
Neil Cerutti

[Emily Short]

d...@pobox.com wrote:
> On Jan 19, 6:24 pm, "Emily Short" <emsh...@mindspring.com> wrote:
> > d...@pobox.com wrote:
> > > On Jan 19, 5:52 pm, "Emily Short" <emsh...@mindspring.com> wrote:
> > > > The Mac IDE already has a header-navigation dropdown; this is
> > > > definitely in.
> >
> > > I looked for this after you said it was in and didn't find it. So I
> > > looked again. And found it.
> >
> > > That's a not a dropdrown it's a disclosing tree. In a separate window.
> > > It sucks.
> > Ah. Then perhaps I'm failing to envision correctly what you do have in
> > mind.
>
> I guess I was being even more cryptic than is usual for me. Sorry
> about that. Also please be noted that "it sucks" was my inconsidered
> opinion after only a few seconds of using it.
>
> I had kind of hoped that you'd look at Xcode or BBEdit (I don't use
> BBEdit, I just watch over the shoulders of those who enthuse about it)
> to see what I mean. I refer you to the following screenshot:
>
> http://www.barebones.com/images/bbedit/function-menu-large.jpg

I use BBEdit all the time; I was just confused by why the Headings
widget didn't qualify as a dropdown menu, and found myself wondering
whether I was misindentifying the part of the BBEdit interface to which
you referred. But I believe we've now cleared up the source of that
confusion.

Re. ideology: the ideology means that I7 starts from a different place
than "let's emulate current standard practice because it's current
standard practice". It does not mean that current standard practice
can't be observed and used where it seems to fit, or adapted where it
seems almost to fit; the original post also notes that we're concerned
to produce something that will be pragmatically useful, and that we
don't want to cause undue frustration. Pragmatic concerns have already
caused us to rethink various ideology-motivated design decisions and
seek a new approach (though, obviously, we're always happiest when we
can come up with something that addresses the pragmatic concern and
fits consistently with the rest of the program).

Of course, that still doesn't guarantee that any given suggestion will
be accepted, so some measure of grumpiness about the ideology is
probably inevitable.

[Kinsman]

A few days ago, I was considering the same problem with if-blocks in
Inform 7, and mailed a suggestion to Graham Nelson:

if the lawn is green,
1. say "The lawn looks bright and inviting."
2. now the squirrel is in the tree.
say "The house looks dark and foreboding."

Phrasing the then-block as a numbered to-do list keeps the metaphor of
natural English, while getting rid of the 'begin' and 'end if' tags.

Nested ifs might look something like this:

if the lawn is green,
1. say "The lawn looks bright and inviting."
2. if the tree is brown,
2.1. say "The tree looks healthy and strong."
otherwise,
2.2. say "The tree looks sickly and weak."
3. now the squirrel is in the tree.
say "The house looks dark and foreboding."

Having to renumber a list if you edit the code of an if-block would be
annoying; I'd recommend not being strict over the exact numbering of the
list. (For instance, 5. could follow 1. and 2. , or could even follow
6., as long as the rules for nesting are obeyed.)

-Sean Givan

[Adam Thornton]

In article <eor7su$ae5$2...@fileserver.fsf.net>,

Adam Thornton <ad...@fsf.net> wrote:
>Making the amount of whitespace semantically relevant breaks this
>assumption.

In fact, my point exactly:

So I went to reread the ESR article pointed out. It's at:

http://www.linuxjournal.com/article/3882

Now, look at "Listing 4".
( http://www.linuxjournal.com/articles/lj/0073/3882/3882l4.html )

I'm betting that there's supposed to be some indentation there in the
for loops.

Adam

[d...@pobox.com]

Ooh. Just like line numbers in BASIC. And just like basic one would
number them 10, 20, 30, just so you insert extra ones in-between when
you needed them.

drj

[d...@pobox.com]

On Jan 19, 9:17 pm, "Emily Short" <emsh...@mindspring.com> wrote:
> I use BBEdit all the time; I was just confused by why the Headings
> widget didn't qualify as a dropdown menu, and found myself wondering
> whether I was misindentifying the part of the BBEdit interface to which
> you referred. But I believe we've now cleared up the source of that
> confusion.

Indeed we have. I'd just like to repeat: "16 pixels. One
mouse-click".

> Re. ideology: the ideology means that I7 starts from a different place
> than "let's emulate current standard practice because it's current
> standard practice". It does not mean that current standard practice
> can't be observed and used where it seems to fit, or adapted where it
> seems almost to fit; the original post also notes that we're concerned
> to produce something that will be pragmatically useful, and that we
> don't want to cause undue frustration. Pragmatic concerns have already
> caused us to rethink various ideology-motivated design decisions and
> seek a new approach (though, obviously, we're always happiest when we
> can come up with something that addresses the pragmatic concern and
> fits consistently with the rest of the program).

I commend your decision to not blindly emulate. That way lies the
thoroughly dull GTK and Windows XP.

However, I see what you say, but I still seems to me that many standard
practices are deliberately ignored (that is, not even in scope for
consideration). This is not the time for my pragmatic / ideology rant
though.

drj

[-]

Agreed. One must use the browser's "view source" command to see the
correct indentation. For such purposes the <pre> tag should have been
employed.

[Kinsman]

No, as long as there *are* numbers of some sort, things would be fine.
Similar to how chapter headings in the source code don't need any
particular order.

-Sean Givan

[James Jolley]

Hi,

As is already argued in the document that Emily sent out, we need to
have it as an option for the visually impaired user or else this will
make I7 entirely unusable for us.

In article <1169228486.3...@s34g2000cwa.googlegroups.com>,
ems...@mindspring.com says...
>
> 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.)
>
>

--
All the best

-James-

----== Posted via Newsgroups.com - Usenet Access to over 100,000 Newsgroups ==----
Get Anonymous, Uncensored, Access to West and East Coast Server Farms at!
----== Highest Retention and Completion Rates! HTTP://WWW.NEWSGROUPS.COM ==----

[Adam Thornton]

In article <eordnk$lcj$1...@aioe.org>, - <x...@x.com> wrote:

>Adam Thornton wrote:
>> I'm betting that there's supposed to be some indentation there in the
>> for loops.

>Agreed. One must use the browser's "view source" command to see the
>correct indentation. For such purposes the <pre> tag should have been
>employed.

OK.

Now:

Imagine you have some I7, significant-indentation, code that you want to
post to rec.arts.int-fiction so someone smarter than you are can tell
you what's wrong with it.

Putting <pre> and </pre> tags around it is obviously inappropriate: if
you're reading Usenet, as I am, with trn, it's not an HTML renderer.
More generally, there is no support for the theory that a Usenet message
body should be HTML, let alone fragmentary HTML.

But what if you're reading it with Google Groups or some other
Usenet-to-web gateway and I didn't put <pre> and </pre> around it? Why,
then, you're screwed (I say, crossing my fingers; I suppose it's
*possible* that Google has anticipated this problem and coded around it,
but I doubt it). Or what if these gateways do what they can to remove
or escape HTML tags they find, because they believe that there are
annoying or hazardous things you could do with <blink> random HTML tags?

A fundamental problem with syntactic whitespace is that HTML renderers,
which will represent a significant fraction of people's interactions
with these documents, are free to collapse whitespace to meet their
formatting goals, and will in the process not merely make it look ugly,
but change its meaning.

The truly fundamental problem is that it violates the
generally-agreed-upon convention in written language, that whitespace is
a boolean variable, and that if it's present at all, its meaning doesn't
(in almost all cases) depend on its horizontal extent. This is of
course slightly less true about vertical extents of whitespace.

Adam

[Andrew Hunter]

On 2007-01-19 18:16:59 +0000, d...@pobox.com said:

>
>
> On Jan 19, 5:52 pm, "Emily Short" <emsh...@mindspring.com> wrote:
>> For now (as I say elsewhere) I'd like to let people discuss before
>> 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.
>
> I looked for this after you said it was in and didn't find it. So I
> looked again. And found it.
>
> That's a not a dropdrown it's a disclosing tree. In a separate window.
> It sucks.

There are actually two tools in the OS X version for navigating
headings. One of these is via the inspector (available through the
Window menu) and is in a floating window. I think this is what you are
referring to here.

The second is a toolbar control which gives you a drop-down navigation
widget. It can be added via the toolbar customisation palette. This can
be somewhat quicker to use as a navigation tool. It's a bit more than
just a drop-down list, because it allows you to navigate the tree
formed by the headings (the design was chosen because a plain menu
structure deals unbelievably badly with deep trees and long heading
names and can't be opened to show context if more than one level deep)

Andrew.

[Eric Eve]

"Emily Short" <ems...@mindspring.com> wrote in message
news:1169228486.3...@s34g2000cwa.googlegroups.com...

> 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.

Yes; re-reading your paper I can see that it did in fact make this
explicit.

But it's also unfortunate that this is how the relevant section of
the document appears in my newsreader:

<quote>
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."

</quote>

I.e., what I see is four lines of code with no indentation at all,
which doesn't exactly inspire confidence that I7 code posted to this
newsgroup using this kind of syntax is going to be readily
understood. Okay, that may be the fault of my newsreader, and
legibility on RAIF isn't a key design criterion for I7 syntax, and
I'm prepared to accept the experience of all those who say this
works well in Python, but still... well, I can see that using
indentation to indicate code blocks does have a certain elegant
simplicity, but this example does leave me still feeling uneasy --
as does this argument:

> 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.

It's rather tempting to turn that argument on its head and say,
"Using whitespace to be semantically meaningful has already proved a
nuisance with tables under certain circumstances, so let's not
exacerbate the problem by introducing yet more semantically
meaningful white space." That's not intended in any way to be a rant
against tables, where the book metaphor works reasonably well, and
it clearly makes sense to represent the data in this format, but in
the case of a table at least it's usually not too hard to see where
the tabs need to be re-inserted.

So I'm left with the vague fair that there's a danger here of
breaking something by trying to fix something that wasn't really all
that broken in the first place (though I'll post another suggestion
in response to a different post in a moment).

-- Eric

[JDC]

Adam Thornton wrote:
> Imagine you have some I7, significant-indentation, code that you want to
> post to rec.arts.int-fiction so someone smarter than you are can tell
> you what's wrong with it.
>
> Putting <pre> and </pre> tags around it is obviously inappropriate: if
> you're reading Usenet, as I am, with trn, it's not an HTML renderer.
> More generally, there is no support for the theory that a Usenet message
> body should be HTML, let alone fragmentary HTML.
>
> But what if you're reading it with Google Groups or some other
> Usenet-to-web gateway and I didn't put <pre> and </pre> around it?

In fact, putting the tags around it won't help in Google Groups either,
since it replaces the brackets; here is that first sentence when I view
the source from Google:
Putting &lt;pre&gt; and &lt;/pre&gt; tags around it is obviously
inappropriate:

-JDC

[Eric Eve]

"Neil Cerutti" <hor...@yahoo.com> wrote in message
news:8a9sh.1471$G23...@newsreading01.news.tds.net...

> On 2007-01-19, ChicagoDave <david.c...@gmail.com> wrote:

>> 5. Requiring End If, End Instead, etc.
>> I'm not sure why this is such a horrible thing. BASIC has
>> been
>> using it for decades and has always been
>> associated with novice programmers, which is one of the
>> concerns in
>> designing the syntax "nicely". It's
>> verbose, but would get rid of the Begin/End statements
>> entirely.
>
> Basic carefully chose words more meaningful than begin and end,
> though.
>
> This raises another option for Inform 7: require everything to be
> a code block--no more one-sentencers. That way, we could dispense
> with begin.

This looks like a potentially promising approach, but we wouldn't
have to make everything a code block, would we? For example, a
single-sentence IF statement could co-exist with a block IF
statement as now, or as in BASIC, couldn't it? The single-sentence
form would remain as it is, namely:

if fred is in the Attic then say "Fred went upstairs." [or
alternatively with the comma]

And the block form could be:

if Fred is in the Attic:
say "Fred went upstairs.";
now Molly is agitated;
end if.

The fact that one form uses 'then' or a comma and the other a colon
would still suffice to distinguish them, I should have thought,
whereas the colon seems less syntactically kludgy than "begin;".

I'm not sure I'd want to go all the way with requiring "End Instead"
and the like, though (that seems needlessly verbose and doesn't
obviously fix anything that needs fixing, apart from making I7 then
look a bit more consistently BASIC-like, which of itself doesn't
seem to be a desideratum).

-- Eric

[vaporware]

Andrew Plotkin wrote:
> (The nice thing about this topic is that anything Graham chooses to do
> will incur somebody's wrath.)
>
> Here, vaporware <jmc...@gmail.com> wrote:

> > David Fisher wrote:
> > > "Emily Short" <ems...@mindspring.com> wrote in message

> > [...]
> > > > 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.
>
> Would the deeper level look like
>
> if ...
> * do ...
> * if ...
> ** do ...
> ** do ...
>
> Or would it look like
>
> if ...
> * do ...
> * if ...
> * * do ...
> * * do ...

The latter, I'd hope.

> Here's my problem with this idea: it requires just as much editor
> support as whitespace indentation.
[...]
> 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.

Ah, but the end result would be more robust. If the editor exports a
text file full of space-indented code, then you still have to deal with
mail and news agents that won't respect that formatting - many of the
people who read your code will have to reformat it by hand before it'll
compile. If, on the other hand, the editor exports a text file where
inner blocks are marked with asterisks, then you can freely post the
code anywhere you like.

vw

[mikegentry]

Thanks for taking the time to write this.

[JDC]

Eric Eve wrote:
> And the block form could be:
>
> if Fred is in the Attic:
> say "Fred went upstairs.";
> now Molly is agitated;
> end if.

Actually, if you just want to get rid of the "begin" (keeping the "end
if") you can in the current syntax by adding:
To if (C - condition) -- end: (- if ({C}) -).

Then you can say
Every turn:

if Fred is in the Attic;
say "Fred went upstairs.";
now Molly is agitated;
end if.

(indentation is, of course, still not significant).

-JDC

[Warren]

Personally I think it's interesting watching everyone try to figure out how
to write CODE CONSTRUCTS in natural language and then arguing when those
code constructs start looking too much like ... code. That's funny. So far
I've seen nothing that actually attempts to justify why using natural
language is a good idea in the first place. Are there examples of situations
or tools where this has worked really well?

What I think we really get out of this is that Inform 7 is going to change
and change drastically. So much so that I can't imagine anyone actually
doing a full work in Inform 7 for quite some time to come.

[mikegentry]

Warren wrote:
> So far
> I've seen nothing that actually attempts to justify why using natural
> language is a good idea in the first place.

Graham Nelson's white paper attempts to do just this.

http://www.inform-fiction.org/I7Downloads/Documents/WhitePaper.pdf

> What I think we really get out of this is that Inform 7 is going to change
> and change drastically. So much so that I can't imagine anyone actually
> doing a full work in Inform 7 for quite some time to come.

... aside from the half-dozen full works currently available on the
Inform website?

http://www.inform-fiction.org/I7/Worked%20Examples.html

[-]

Adam Thornton wrote:
> In article <eordnk$lcj$1...@aioe.org>, - <x...@x.com> wrote:
>> Adam Thornton wrote:
>>> I'm betting that there's supposed to be some indentation there in the
>>> for loops.
>> Agreed. One must use the browser's "view source" command to see the
>> correct indentation. For such purposes the <pre> tag should have been
>> employed.
>
> OK.
>
> Now:
>
> Imagine you have some I7, significant-indentation, code that you want to
> post to rec.arts.int-fiction so someone smarter than you are can tell
> you what's wrong with it.
>
> Putting <pre> and </pre> tags around it is obviously inappropriate: if
> you're reading Usenet, as I am, with trn, it's not an HTML renderer.
> More generally, there is no support for the theory that a Usenet message
> body should be HTML, let alone fragmentary HTML.

The ESR post was to an HTML-based website, not Usenet. I could have been
clearer in my statement.

Also, I do see the <code> idiom employed on r.a.i.f. It's not clear to
me the conceptual difference between <code> and <pre> when <code> is
employed in this idiomatic style. Nevertheless, <code> is used as
syntactic sugar, you're asserting that <pre> would be required. For
reasons outlined below, I don't agree with that assertion.

> But what if you're reading it with Google Groups or some other
> Usenet-to-web gateway and I didn't put <pre> and </pre> around it? Why,
> then, you're screwed (I say, crossing my fingers; I suppose it's
> *possible* that Google has anticipated this problem and coded around it,
> but I doubt it).

Not to be a Google fanboy, but apparently it does handle tab formatting.
See one of my earlier posts on Google Groups (GG): http://tinyurl.com/3aolj3
The post was formatted w/ tabs; which formatting was preserved. A "view
source" command in a Google Groups window yields some interesting results.

> Or what if these gateways do what they can to remove
> or escape HTML tags they find, because they believe that there are
> annoying or hazardous things you could do with <blink> random HTML tags?

I'm sure that GG does go to some lengths to sanitize tags. The "view
source" command show the results of this action.

> A fundamental problem with syntactic whitespace is that HTML renderers,
> which will represent a significant fraction of people's interactions
> with these documents, are free to collapse whitespace to meet their
> formatting goals, and will in the process not merely make it look ugly,
> but change its meaning.

Honestly, I have yet to see this problem, even on other computer
programming lists. Has source code formatting been a problem on this list?

> The truly fundamental problem is that it violates the
> generally-agreed-upon convention in written language, that whitespace is
> a boolean variable, and that if it's present at all, its meaning doesn't
> (in almost all cases) depend on its horizontal extent. This is of
> course slightly less true about vertical extents of whitespace.

To explicitly list some cases in written language where horizontal
extent is syntactically relevant:
o A paragraph's topic sentence
o One or more of the following:
unnumbered lists
sub-entries that amplify or extend a list entry
plays or other dramatic works
poetry
o Quotations set apart from body text

I7's owners will have to decide to what extent they will implement the
natural language paradigm. It is a worthy goal that block delimiters can
be classified as syntactic sugar and removed as barriers to acceptance
for those who are story tellers but not professional or self-taught
computer programmers. I favor explicit whitespace over tokens because of
the natural language facet of I7.

[Adam Thornton]

In article <eormcn$8m0$1...@aioe.org>, - <x...@x.com> wrote:
>The ESR post was to an HTML-based website, not Usenet. I could have been
>clearer in my statement.

But my actual point was that--even knowing damn well that the language
was indentation-sensitive--_Linux Journal_ screwed up the presentation.
And they're generally on the assiduous side as such things go.

>> A fundamental problem with syntactic whitespace is that HTML renderers,
>> which will represent a significant fraction of people's interactions
>> with these documents, are free to collapse whitespace to meet their
>> formatting goals, and will in the process not merely make it look ugly,
>> but change its meaning.
>
>Honestly, I have yet to see this problem, even on other computer
>programming lists. Has source code formatting been a problem on this list?

Two things:

1) You've seen that problem with ESR's code on the LJ site.
2) Yes. Pasting in my I7 code so that other raifers could read it and
see what I'd done wrong was hard and nasty and I had to do a lot of
by-hand space-and-tab editing.

>To explicitly list some cases in written language where horizontal
>extent is syntactically relevant:
> o A paragraph's topic sentence
> o One or more of the following:
> unnumbered lists
> sub-entries that amplify or extend a list entry
> plays or other dramatic works
> poetry
> o Quotations set apart from body text

Outline form is a very special case, I would argue. The amount of
whitespace at the beginning of the paragraph I will, sort of, give you:
generally more than an em-dash. Although you will note that on Usenet,
in general, a blank line serves the purpose rather than indentation.
Likewise, with block quotations, one certainly *could* choose to set
them off with quotation marks rather than indenting them.

Poetry is also different. See Lewis Carroll's "A Mouse's Tail" for,
perhaps, the clearest example of how the layout of the poem conveys more
meaning than its words. In this case, it is explicitly the format
rather than the text that is of interest.

More generally, yes, I certainly plead guilty to going to absurd lengths
to replicate particular effects of emphasis and spacing in my source
text for some quotations in my work in progress. Nevertheless, these
are very much corner cases.

If you are going to argue that an I7 work is more like an outline than
like natural text, well, I won't necessarily disagree with you, but it
might make Graham cry.

Adam

[David Fisher]

"Kinsman" <kin...@nbnet.nb.ca> wrote in message
news:FBash.2856$1x.4...@ursa-nb00s0.nbnet.nb.ca...

>A few days ago, I was considering the same problem with if-blocks in Inform
>7, and mailed a suggestion to Graham Nelson:
>
> if the lawn is green,
> 1. say "The lawn looks bright and inviting."
> 2. now the squirrel is in the tree.
> say "The house looks dark and foreboding."
>
> Phrasing the then-block as a numbered to-do list keeps the metaphor of
> natural English, while getting rid of the 'begin' and 'end if' tags.
>
> Nested ifs might look something like this:
>
> if the lawn is green,
> 1. say "The lawn looks bright and inviting."
> 2. if the tree is brown,
> 2.1. say "The tree looks healthy and strong."
> otherwise,
> 2.2. say "The tree looks sickly and weak."
> 3. now the squirrel is in the tree.
> say "The house looks dark and foreboding."

This is the kind of thing I was suggesting up thread with using "*", "**",
etc. in the post
http://groups.google.com/group/rec.arts.int-fiction/msg/0469adec98e43ac0

- which doesn't have the problem of getting the numbers right when you want
to add or delete a line.

David Fisher

[Kinsman]

>
> This is the kind of thing I was suggesting up thread with using "*", "**",
> etc. in the post
> http://groups.google.com/group/rec.arts.int-fiction/msg/0469adec98e43ac0
>
> - which doesn't have the problem of getting the numbers right when you want
> to add or delete a line.
>
> David Fisher
>
>

But it does match the sorts of things we see in natural English more
closely - and, as long as there is *a* number of some sort being used,
the order of the numbers wouldn't really matter.

-Sean Givan

[Warren]

"mikegentry" <mi...@edromia.com> wrote in message
news:1169250533.6...@11g2000cwr.googlegroups.com...

>
> ... aside from the half-dozen full works currently available on the
> Inform website?
>
> http://www.inform-fiction.org/I7/Worked%20Examples.html

Right! You mean the ones that never compile between builds and haven't
worked, as is, for quite some time now? Good example. You sure showed me.

[David Fisher]

"Andrew Plotkin" <erky...@eblong.com> wrote in message
news:eoqs1n$9be$1...@reader2.panix.com...

> (The nice thing about this topic is that anything Graham chooses to do
> will incur somebody's wrath.)

Undoubtedly ... :-/

>>> 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."

Here is an example, based on a section of Emily Short's "Glass"
(http://inform-fiction.org/I7Downloads/Examples/glass/source_3.html):

Every turn when the old lady is active
* if Theodora Endgame is happening, rule succeeds
* if Lucinda Endgame is happening, rule succeeds
* let pause be "blank"
* let segue be the next step via the suggestion relation from the current
subject to the target subject
* if segue is a subject
* * while segue is not the target subject and segue is not fruitful
* * * let segue be the next step via the suggestion relation from the segue
to the target subject
* * * let pause be "There's a long, thoughtful sort of pause. "
* * if pause is not "blank", relate the current subject with the segue,
pausing first
* * otherwise relate the current subject with the segue, directly
* * change last subject to current subject
* * change current subject to segue
* otherwise
* * change the current subject to last subject;
* * if Fitting has happened
* * * make no decision
* * say "There's an uncomfortable silence as everyone tries to think of a
sensible direction for the conversation to take from here. "

(I tried it with "***" instead of "* * *", but the latter looks better.
Using "o" instead of "*" also looks quite good. Note that there is no need
for semi-colons at the end of lines).

> Here's my problem with this idea: it requires just as much editor
> support as whitespace indentation.
[...]
> But if you have that level of editor support, most of the objections
> to whitespace indentation are solved anyway.

True, but there are still the objections about importing code from
newsgroups and email that others have raised.

BTW I agree this really would need editor support; it's a little painful
having to type in the "*"s on every line.

David Fisher

[Emily Short]

James Jolley wrote:
> Hi,
>
> As is already argued in the document that Emily sent out, we need to
> have it as an option for the visually impaired user or else this will
> make I7 entirely unusable for us.

Yes, we're very much aware of this. Indeed, for quite a while I was
convinced that an indented approach would be completely unacceptable
for exactly this reason, and it wasn't until we explored the idea of
having optional settings that I began to think that might not be true.
So this is a high priority with us, whatever decision we ultimately
reach.

[mikegentry]

Warren wrote:
>
> Right! You mean the ones that never compile between builds and haven't
> worked, as is, for quite some time now? Good example. You sure showed me.

Er, sorry. I thought you said, "I don't think anyone will ever finish a
game in Inform 7," not, "I think subsequent beta releases of Inform 7
might break existing source code." My bad.

[vaporware]

Well, yeah, he did. Many complete works *have* been written in Inform
7, totaling hundreds of thousands of words. The fact that the language
has changed since then doesn't erase the fact that they were written in
the first place. It does highlight the challenge of working in a
language whose specification is still evolving, but many authors seem
to be up to that challenge: either they update their code for each new
build, or they keep an old build around to maintain their old projects.

vw

[steve....@gmail.com]

Eric Eve wrote:

> I can see that using
> indentation to indicate code blocks does have a certain elegant

> simplicity, but this example does leave me still feeling uneasy[.]

It's a shame that so much of the discussion of Emily's generous post
has been concerned with this rather narrow issue. (This isn't a comment
directed at anyone in particular, least of all you, of course.) But I
understand the controversy: whitespace runs against I7's efforts
towards naturality. It starts to read too much like computer syntax,
which (for better or worse) does not agree with the I7 concept.

So let me add one more idea to the mix. If one of I7's major
contributions has been the retranslation of the computer-ese "else"
back into the more prosaic "otherwise", then both the continuation and
the closure of the 'if' statement could be perfectly well signaled by
additional conjunctions, such as "and" or "and in any case," or
"otherwise." For examples:

if the tree is green:
say "How pleasant the garden is today.";

and now the squirrel is in the tree; (- or better, "and change the
squirrel's location to the tree"; or "move the squirrel into the tree"
etc. -)
and in any case, say "How dark and foreboding is the house."

Or what I would really like to see:

If the tree is green, say "How pleasant the garden is today." and move
the squirrel into the tree. Otherwise, say "How dark and foreboding is
the house."

In other words, this is no time for I7 to have an identity crisis, to
start doing structured formatting badly. Instead, it should accept its
own commitments, and attempt to do well what it has set out to do,
within the genre it's made for itself. It should perfect itself. Yes, I
thought the whole I7 concept was a bad idea in the first place -- and I
still do -- but a bad idea, done well, can be good, even great, even
genius; but a bad idea executed badly is just shite.

[Emily Short]

If your question is, does each new I7 build promise not to break
backward compatibility, then the answer is obviously no. This is a
danger of working in a beta language. We try to minimize the negative
effects where we can, but not when we think there's a substantial
improvement to the language that could be made at the cost of breaking
some older code. The proposed change to code blocks would do this in
dramatic fashion, which is one of several strong reasons to offer a
per-file option allowing people to continue using the older syntax.

That said: I apologize for the fact that some of the Worked Examples on
the website are currently noncompiling. Bronze, Glass, and DM all *do*
compile in the current version -- I reuploaded them after the last
build that broke them, and they are subject to automated testing that
always indicates this to us when it happens; so when they're not
updated it is usually because I haven't gotten around to rebuilding the
webpages for each project and uploading them again. I try to do this
shortly after each new build is posted, but it doesn't always happen as
fast as it could.

RoTA is auto-tested as well, but it looks like the version on the
website is not the latest compilation; this is a similar oversight,
because a compiling version does exist. The code currently on the
website can be made to compile again if you

-- comment out the release statement as usual;
-- search for and replace "something held" with "something preferably
held"; and
-- create action stubs for swimming, filling, digging, blowing, and
praying.

It would be good to upload the better version, but (for whatever it's
worth), that's all one needs to do to repair the existing code, and all
the repairs correspond to deliberate, documented language changes.

The situation with the two When in Rome examples is rather different:
they are failing compilation for minor reasons, but because of recent
changes to rule ordering and randomization they will also need to have
their regression scripts revised a bit so that I can confirm that they
still play properly; and while I'm at it, they need some other updating
than just a fix-to-compile. I have reports of a few bugs I'd like to
fix; I also would like to go back and streamline their code, because
recent improvements to the language have made it possible to do a much
better job on several fronts, providing a better example of style and
making it easier for the novice programmer to follow what is happening
and why. I believe this would be useful, but it's not a fast change,
and it is lower on the priority list than a bunch of other things; it's
also likely that if I wait another build or two I'll be able to take
advantage of yet further improvements to action handling, which would
be useful given how heavily WiR2 uses such rules.

A plausible argument at this point is that the WiR examples should in
that case be withdrawn from the website so as not to waste anyone's
time on futile compilation attempts; I sympathize with that, and also
with the counter-counter-argument that they still do contain a lot of
perfectly functional code that someone might find interesting to read.
Probably the best solution would be to annotate the website to indicate
the last build on which they can be compiled, until such time as I can
offer a current rendition. I just now thought of this solution, though;
I'm afraid this specific problem hasn't been at the front of my mind.

All that said: the only time a new build has broken a
previously-working feature in one of the worked examples is when we
withdrew a few actions from the standard library. Once or twice they've
ceased to compile because of a deliberate syntax modification, but most
of the time the compilation failure is due to Inform becoming stricter
and succeeding in catching at compile-time things that are in fact bad
or unreliable code. Both syntax modifications and added problem
messages are listed in the change log, to give authors some idea of
what they're up against. Now, to some extent I've had relatively little
trouble exactly because the examples *are* used for regression testing;
we'd notice if any of their features became nonfunctional. Still, I
think for the most part I7 has done a reasonable job of not making code
stop compiling for reasons that the change log doesn't explain.
(Reasonable, but not perfect. There is one obvious unfortunate example
that turned up just this last build to do with formerly-valid Check ...
when ... rules ceasing to compile; this looks to be a bug and we have
made it a priority 1 fix.)

Still: yep, if you want a stable language unlikely to change much, I
recommend picking one of the ones that's out of beta.

[Adam Thornton]

In article <1169265213.2...@v45g2000cwv.googlegroups.com>,

Emily Short <ems...@mindspring.com> wrote:
>Still: yep, if you want a stable language unlikely to change much, I
>recommend picking one of the ones that's out of beta.

...and hey, could we all stop picking on the whitespace issue for a bit
and address my post on Section 4, which makes, honestly, makes
poo-flinging crack-monkeys look like milk and cookies in comparison to
its tone?

Adam

[Emily Short]

Did I miss the part where you actually posted your post on Section 4? I
thought you'd merely threatened to do so, which I interpreted as an
invitation to wait in silent trepidation.

[Andrew Plotkin]

No doubt we are all chortling about the fact that the whitespace
proposal, at least, comes with an explicit backwards-compatibility
plan.

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Just because you vote for the Republicans, doesn't mean they let you be one.

[James Jolley]

In article <1169259012....@51g2000cwl.googlegroups.com>,
ems...@mindspring.com says...

Thanks. I suppose your wanting to just have a use claws built-in perhaps
something like:
Use no indentation>

[John Roth]

I suspect that's a workable solution. I've come around to the
viewpoint that it's the editor's job to present the work in a way
that the developer finds useable. It's not its job to present the
source in a literal one for one fashion as long as it doesn't
obfuscate something that's actually significant. If that means
using a special character for indentation, then so be it.

John Roth
character to indicate indentation in the source.

[John Roth]

Emily Short wrote:
> d...@pobox.com wrote:
> > On Jan 19, 6:24 pm, "Emily Short" <emsh...@mindspring.com> wrote:

> > > d...@pobox.com wrote:
> > > > On Jan 19, 5:52 pm, "Emily Short" <emsh...@mindspring.com> wrote:
> > > > > The Mac IDE already has a header-navigation dropdown; this is
> > > > > definitely in.
> > >
> > > > I looked for this after you said it was in and didn't find it. So I
> > > > looked again. And found it.
> > >
> > > > That's a not a dropdrown it's a disclosing tree. In a separate window.
> > > > It sucks.

> > > Ah. Then perhaps I'm failing to envision correctly what you do have in
> > > mind.
> >
> > I guess I was being even more cryptic than is usual for me. Sorry
> > about that. Also please be noted that "it sucks" was my inconsidered
> > opinion after only a few seconds of using it.
> >
> > I had kind of hoped that you'd look at Xcode or BBEdit (I don't use
> > BBEdit, I just watch over the shoulders of those who enthuse about it)
> > to see what I mean. I refer you to the following screenshot:
> >
> > http://www.barebones.com/images/bbedit/function-menu-large.jpg
>
> I use BBEdit all the time; I was just confused by why the Headings
> widget didn't qualify as a dropdown menu, and found myself wondering
> whether I was misindentifying the part of the BBEdit interface to which
> you referred. But I believe we've now cleared up the source of that
> confusion.
>
> Re. ideology: the ideology means that I7 starts from a different place
> than "let's emulate current standard practice because it's current
> standard practice". It does not mean that current standard practice
> can't be observed and used where it seems to fit, or adapted where it
> seems almost to fit; the original post also notes that we're concerned
> to produce something that will be pragmatically useful, and that we
> don't want to cause undue frustration. Pragmatic concerns have already
> caused us to rethink various ideology-motivated design decisions and
> seek a new approach (though, obviously, we're always happiest when we
> can come up with something that addresses the pragmatic concern and
> fits consistently with the rest of the program).
>
> Of course, that still doesn't guarantee that any given suggestion will
> be accepted, so some measure of grumpiness about the ideology is
> probably inevitable.

Even if you want to distance yourself a bit from standard practice
among software developers (which I think is a good thing - progress
is made by people who depart from the current consensus), I suspect
there's some standard practice among writers that might be useful to
look at.

John Roth