mirror of
https://github.com/ganelson/inform.git
synced 2024-06-01 07:48:35 +03:00
Added licence
This commit is contained in:
Graham Nelson
parent
3191ccada0
commit
650caa58d1
23
README.md
23
README.md
|
|
@ -11,6 +11,23 @@ Inform is often assigned material for courses on digital narrative).
|
|||
It has twice ranked in the top 100 most influential programming languages
|
||||
according to the TIOBE index.
|
||||
|
||||
## Licence
|
||||
|
||||
Except as noted, copyright in material in this repository (the "Package") is
|
||||
held by Graham Nelson (the "Author"), who retains copyright so that there is
|
||||
a single point of reference. As from the first date of this repository
|
||||
becoming public, the Package is placed under the [Artistic License 2.0](https://opensource.org/licenses/Artistic-2.0).
|
||||
This is a highly permissive licence, used by Perl among other notable projects,
|
||||
recognised by the Open Source Initiative as open and by the Free Software
|
||||
Foundation as free in both senses.
|
||||
|
||||
For the avoidance of doubt, the Author makes the further grant that users of
|
||||
the Package may make unlimited use of story files produced by the Package:
|
||||
such story files are not derivative works of Inform and do not inherit the
|
||||
Artistic License 2.0 as an obligation. (This further grant follows the
|
||||
practice of projects like bison, which also copy substantial code into
|
||||
their outputs.)
|
||||
|
||||
## Repositories
|
||||
|
||||
This is the "core repository", holding source code for the compiler, and
|
||||
|
|
@ -51,6 +68,12 @@ sounds like a helicopter taking off.
|
|||
|
||||
## Inventory
|
||||
|
||||
"I can't help feeling that if someone had asked me before the universe began
|
||||
how it would turn out, I should have guessed something a bit less like an old
|
||||
curiosity shop and a bit more like a formal French garden — an orderly
|
||||
arrangement of straight avenues, circular walks, and geometrically shaped
|
||||
trees and hedges." (Michael Frayn)
|
||||
|
||||
Inform is not a single program: while the Inform 7 compiler builds to a single
|
||||
executable file, this is only useful in concert with other tools (notably the
|
||||
Inform 6 compiler and the Inblorb packager), with standard libraries of code
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
# This makefile was automatically written by inweb -makefile
|
||||
# and is not intended for human editing
|
||||
|
||||
INTEST = intest/Tangled/intest
|
||||
INWEB = inweb/Tangled/inweb
|
||||
|
||||
CC = clang -std=c99 -c $(MANYWARNINGS) $(CCOPTS) -g
|
||||
INDULGENTCC = clang -std=c99 -c $(FEWERWARNINGS) $(CCOPTS) -g
|
||||
|
||||
|
|
|
|||
|
|
@ -12,10 +12,7 @@ Web Syntax Version: 2
|
|||
Licence: Artistic License 2.0
|
||||
|
||||
Preliminaries
|
||||
Preface
|
||||
Licence and Copyright Declaration
|
||||
Introduction to Syntax ^"Preform"
|
||||
The Champollion Project
|
||||
Command-Line Usage
|
||||
|
||||
Import: foundation
|
||||
Import: words
|
||||
|
|
|
|||
10
inform7/Preliminaries/Command-Line Usage.w
Normal file
10
inform7/Preliminaries/Command-Line Usage.w
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
Command-Line Usage.
|
||||
|
||||
A brief note on using Inform 7 at the command line.
|
||||
|
||||
@h Introduction.
|
||||
|
||||
|
||||
|
||||
@ Inform returns an exit code of 0 if successful, or else it throws errors
|
||||
to |stderr| and returns 1 if unsuccessful.
|
||||
|
|
@ -1,441 +0,0 @@
|
|||
P/syn: Introduction to Syntax.
|
||||
|
||||
This is the introduction to the stand-alone document of the English
|
||||
syntax of Inform.
|
||||
|
||||
@h Preface.
|
||||
"From an engineering perspective, language is kind of a disaster" (Arika
|
||||
Okrent). Welcome to the scene of a disaster.
|
||||
|
||||
The syntax of a language is the collection of rules for how complicated
|
||||
structures -- sentences, for example -- are built up from simpler ones. These
|
||||
rules can work in many different ways: they may require us to use punctuation,
|
||||
word ordering, word modification, or verbal formulae to hold a sentence
|
||||
together. Every natural language has its own distinctive syntax.
|
||||
|
||||
Syntax is not a precise term, even in computing. English sentences really
|
||||
can't be formed properly without some idea of what the words mean, and
|
||||
different linguists put the boundary of syntax and semantics in different
|
||||
places. For Inform purposes, we will use "syntax" to mean the rules of
|
||||
natural language enforced by its lexical rules (spaces, punctuation, quotation
|
||||
marks and so on) together with its Preform grammar.
|
||||
|
||||
Preform is the name given to both a notation for syntax, and a subsystem of
|
||||
Inform which parses text against definitions written in that notation.
|
||||
The purpose of Preform, introduced in early 2011, is to separate
|
||||
the compiler as far as possible from the definition of the natural language
|
||||
it reads. Eventually, we would like Inform to read all major European
|
||||
languages on an equal basis, though this is a very ambitious goal.
|
||||
|
||||
@ If you're reading this as part of the {\it English Syntax of Inform}
|
||||
document, you might like to know how the document is made. Inform is a
|
||||
"web" according to the "literate programming" doctrine of Donald Knuth:
|
||||
in fact, at about 160,000 lines of code, it's one of the largest webs ever
|
||||
written. A literate program is written in a narrative style, laying out
|
||||
code in as legible a style as possible, and with sketch-proofs and
|
||||
explanations to justify the choices made, or simply to give the reader
|
||||
some idea of what is going on.
|
||||
|
||||
To use a literate program, you need two preprocessors -- a "weaver" and a
|
||||
"tangler". The weaver makes a typeset document intended only for human
|
||||
eyes: an ebook, in effect. If you're reading this as a PDF document, you're
|
||||
looking at the output from Inform's weaver. The tangler, on the other hand,
|
||||
makes a traditional computer program which can be fed into a compiler and
|
||||
eventually run, but which is an illegible mess to the human eye. In Inform's
|
||||
case, the weaver and tangler are actually both the same program (called
|
||||
|inweb|), which weaves to \TeX\ and tangles to ANSI C.
|
||||
|
||||
Literate programs are subdivided into paragraphs. Knuth, who called these
|
||||
"sections", traditionally wrote them as $\S 1$, $\S 2$, ..., and so on; up
|
||||
to $\S 1380$ for \TeX\ and $\S 1215$ for Metafont. That was already quite hard
|
||||
to navigate, and Inform has about 7000 paragraphs, so I have used a more
|
||||
hierarchical system. The notation "6/vp.$\S$14" means paragraph 14 in the
|
||||
section "Verb Phrases" of Chapter 6; it's a sort of postcode to a single
|
||||
piece of code in the program. The current paragraph belongs to a special
|
||||
chapter identified as P for "preliminaries", which contains material like
|
||||
the preliminary pages of a book.
|
||||
|
||||
@ The business of weaving and tangling is relevant because of the way the
|
||||
Preform notations are written. Individual pieces of the syntax are scattered
|
||||
all over the vast Inform web, in order to keep them close to the code which
|
||||
uses them. However:
|
||||
|
||||
(a) The weaver has a mode in which it weaves together only the paragraphs
|
||||
which define or talk about Preform grammar, skipping the rest of the program
|
||||
entirely. This is how the {\it English Syntax of Inform} document is made.
|
||||
|
||||
(b) The tangler also treats the Preform definitions in a special way. It
|
||||
extracts them into a standalone file called |English.preform|, a built-in
|
||||
resource which Inform; alter this file, and you alter Inform's syntax, though
|
||||
there are better ways.
|
||||
|
||||
Thus, for example, the familiar Inform wording "in the presence of" doesn't
|
||||
occur anywhere in the Inform compiler; it's part of a Preform definition which
|
||||
is read in by the compiler. When Inform is reading French, it will use a
|
||||
different Preform definition ("dans la pr\'esence de", say).
|
||||
|
||||
@ Because of all this, the {\it English Syntax of Inform} document is not
|
||||
somebody's approximate sketch of what Inform is supposed to do. It's the
|
||||
actual code Inform executes, current to the build code and date on the cover.
|
||||
|
||||
That makes it fairly precise, though it's not always laid out in the order you
|
||||
might choose if you were (say) sitting down to write a BNF definition of the
|
||||
Inform language. It also comes out as quite a long description. Inform uses
|
||||
more than 500 Preform nonterminals, which seems an awful lot. Jeff Lee's
|
||||
elegant Yacc grammar for ANSI C (1985) needed only about 60; C, of course,
|
||||
is a famously small language, and actual compilers of it generally use a
|
||||
more extensive grammar -- |gcc| 3.3 used 159 nonterminals, back in the days
|
||||
when |gcc| still used Yacc instead of a hand-coded parser -- but still: this
|
||||
makes Inform look maybe twice the size of a typical programming language.
|
||||
|
||||
I think that's misleading, though:
|
||||
|
||||
(a) Firstly, Inform generally uses different wording for different meanings,
|
||||
rather than using the same punctuation syntax over and over but with
|
||||
complicated semantic rules for what it does. (Consider brackets in C++.)
|
||||
This means syntax is more expressive.
|
||||
|
||||
(b) Secondly, real compilers always contain semi-secret syntaxes of one kind
|
||||
or another -- additional data types for oddball processors, keywords giving
|
||||
optimisation hints, debugging features, and so on -- which always make what a
|
||||
compiler actually parses more extensive than the theoretical definition of the
|
||||
language it compiles. Inform is no exception. For example, it contains several
|
||||
syntaxes undocumented in the public manual and provided only for the
|
||||
bootstrapping process which the Standard Rules goes through; these are not for
|
||||
public use and may change without notice.
|
||||
|
||||
(c) Inform uses Preform not only to parse correct syntax, but also to
|
||||
take a guess at what incorrect syntax was aiming to do, in order to help it
|
||||
to produce better problem messages. Once again, that means that there is
|
||||
Preform syntax which isn't part of the public language definition.
|
||||
|
||||
(d) Preform notation provides a convenient way to name some of the standard
|
||||
constructions made by the Standard Rules; this, again, isn't part of the
|
||||
syntax definition of Inform -- it's a convenience helping the compiler
|
||||
to implement its semantics.
|
||||
|
||||
(e) Preform notation encourages many small definitions rather than a few
|
||||
large ones.
|
||||
|
||||
@ Preform looks like BNF (Backus-Naur form), which has been the traditional
|
||||
notation for syntax in computer science since 1960. It's actually a very
|
||||
simple form of BNF, lacking extensions for optional or repeated elements.
|
||||
BNF is where the jargon words "nonterminal" and "production" come from.
|
||||
|
||||
Our language is composed of "nonterminals", each of which is either
|
||||
"internal" or defined with a list of "productions". A nonterminal is used
|
||||
to parse a given excerpt of text to see if it matches some pattern, and
|
||||
well-chosen nonterminals will correspond to traditional linguistic ideas --
|
||||
<accusative-pronoun> or <s-noun-phrase>, for example. An "internal"
|
||||
nonterminal tests for a match using a routine hardwired into the compiler,
|
||||
which means no user of Inform can easily alter it.
|
||||
|
||||
For example, here is an imaginary example: a nonterminal with two productions,
|
||||
which can match text such as "4th runner" or "runner no 17". The |::=|
|
||||
symbol can be read as "is defined by", and the vertical stroke means "or".
|
||||
Each of the two productions sits on a single line, though that's good style,
|
||||
rather than being compulsory.
|
||||
|
||||
= (not code)
|
||||
<competitor> ::=
|
||||
<ordinal-number> runner |
|
||||
runner no <cardinal-number>
|
||||
|
||||
@ When Inform successfully matches some text against a production, it usually
|
||||
means that one or more nonterminals have made matches as part of this effort.
|
||||
For example, a match against "4th runner" means <ordinal-number> has
|
||||
matched against "4th". Inform usually needs to know the "results" of
|
||||
each such intermediate match. Results are numbered along the production,
|
||||
counting upwards from 1. Here's a more interesting example:
|
||||
|
||||
|runner from <town> numbered <cardinal-number>|
|
||||
|
||||
This has two results, numbered 1 and 2. Suppose we are translating this into
|
||||
French, and French word ordering means that these need to occur back to front.
|
||||
(It doesn't, but just suppose.) If we write
|
||||
|
||||
|coureur no <cardinal-number> de <town>|
|
||||
|
||||
This won't work, because Inform will think the town should be result 1 and
|
||||
the number result 2. So to do this we need a new syntax:
|
||||
|
||||
|coureur no <cardinal-number>?2 de <town>?1|
|
||||
|
||||
The |?| suffix followed by a number declares the result number explicitly.
|
||||
So the original production could equivalently have been written
|
||||
|
||||
|runner from <town>?1 numbered <cardinal-number>?2|
|
||||
|
||||
If one of the nonterminals is numbered, then they all must be.
|
||||
|
||||
@ Translators giving equivalent definitions for languages other than English
|
||||
need to match the order of the productions exactly. If the English looks
|
||||
like so:
|
||||
|
||||
= (not code)
|
||||
language English
|
||||
|
||||
<competitor> ::=
|
||||
<ordinal-number> runner from <origin> |
|
||||
runner no <cardinal-number>
|
||||
|
||||
@ Then the French will look like so:
|
||||
|
||||
= (not code)
|
||||
language French
|
||||
|
||||
<competitor> ::=
|
||||
<ordinal-number> coureur de <origin> |
|
||||
coureur avec numero <cardinal-number>
|
||||
|
||||
@ This is sometimes problematic: maybe the productions need to be given in a
|
||||
different order to parse properly, or maybe two different versions need to be
|
||||
given. To get around this, a translator can optionally begin a production
|
||||
with a match number in the form |/a/| to |/z/|. For example, a translator
|
||||
might supply three French productions to match the two English ones:
|
||||
|
||||
|/a/ <ordinal-number> coureur de la <origin>|
|
||||
|/a/ <ordinal-number> coureur du <origin>|
|
||||
|/b/ coureur no <cardinal-number>|
|
||||
|
||||
If any of the productions are numbered, they all should be. In the English
|
||||
originals, numbering is always in standard alphabet order; in the Preform
|
||||
grammar document extracted from the Inform source code, italicised letters
|
||||
are printed next to each production for convenience.
|
||||
|
||||
When 26 productions isn't enough, use |/aa/| to |/zz/|. English never uses more
|
||||
than 52 productions in any nonterminal, so we never need more than that.
|
||||
|
||||
@ It looks as if each production is made up either of nonterminals or fixed
|
||||
words, but in fact there are other possibilities too.
|
||||
|
||||
(a) We can save typing and also speed up the parsing by using a forward
|
||||
slash |/| to give alternative single fixed words. Thus |wheel/spoke/pedal|
|
||||
is a single token matching any one of these three words. |/| can only be
|
||||
used with fixed-word tokens.
|
||||
|
||||
Next, there are three wildcards:
|
||||
|
||||
(b) The token |###| matches any single word.
|
||||
|
||||
(c) The token |***| matches any stretch of one or more words.
|
||||
|
||||
(d) The token |...| matches any stretch of one or more words. If it is written
|
||||
with six dots instead of three, |......|, brackets (round or brace) inside the
|
||||
word range are required to pair correctly, or there's no match.
|
||||
|
||||
There are also three modifiers, which affect how Inform reads the immediately
|
||||
following token:
|
||||
|
||||
(e) An underscore |_| coming before a fixed-word token means informally that
|
||||
a match has to be made in lower case; more precisely, the word cannot
|
||||
unexpectedly be in upper case. Thus |_in| matches in the sentences
|
||||
"A ball is in the bag." and "In the bag is a ball.", but not "On the
|
||||
shelf is In The Budding Grove." |_in/on| matches either "in" or "on",
|
||||
but in both cases they would have to be in lower case.
|
||||
|
||||
(f) A caret |^| coming before a nonterminal or a fixed-word token negates its
|
||||
meaning. For instance, |^<competitor>| matches any text which <competitor>
|
||||
doesn't match; there are no meaningful results from this. |^blancmange|
|
||||
matches any {\it single} word which is not "blancmange", so it matches
|
||||
"jelly", but not "confectioner's custard". |^fish/fowl| matches any
|
||||
single word which is neither "fish" nor "fowl".
|
||||
|
||||
(g) A backslash tells Inform to read the next word as its literal textual
|
||||
contents, regardless of the above rules. So |\***| means the word consisting
|
||||
of three asterisks, and |\<competitor>| means the word consisting of open
|
||||
angle, c, o, m, ..., r, close angle. |\ac/dc| means the literal text "ac/dc",
|
||||
and isn't a choice of two. And, of course, |\\| means an actual backslash.
|
||||
|
||||
Material in square brackets, [like this], is comment and is ignored.
|
||||
|
||||
@ There is one more syntax, but it takes some explaining. When wildcards
|
||||
match, Inform can access the words they represent. For instance,
|
||||
|
||||
|man with ... on his shirt|
|
||||
|
||||
would match "man with Race Organiser on his shirt" and generate the word
|
||||
range "Race Organiser" in the process. Wildcards are numbered from 1 in order
|
||||
of their generation. But braces can be used to affect this, and in effect
|
||||
to spread or consolidate word ranges. Thus:
|
||||
|
||||
|man with {... sash} on his shirt|
|
||||
|
||||
would match "man with marshall's sash on his shirt" while making the word
|
||||
range "marshall's sash" instead of just "marshall's". This notation is
|
||||
especially helpful when we need both to check that something matches, and
|
||||
also record its wording for later:
|
||||
|
||||
|man with {<messy-set-of-official-logos>} on his shirt|
|
||||
|
||||
Braces can't be nested; an inner pair of braces would in any case have no
|
||||
effect, because the outer pair would wipe them out.
|
||||
|
||||
@ Ranges raise the same what-if-we-want-them-back-to-front issue as results
|
||||
do, and we solve the problem the same way. The ranges in:
|
||||
|
||||
|man with ... on his ...|
|
||||
|
||||
are numbered 1 and 2 respectively; and the following:
|
||||
|
||||
|homme dont {...}?2 est {...}?1|
|
||||
|
||||
tells Preform that when this text is matched, the word ranges are the other
|
||||
way round compared with the English version.
|
||||
|
||||
@ Other punctuation characters have no special meaning -- dashes, round brackets,
|
||||
full stops, commas, semicolons, colons, asterisks, question marks and so on
|
||||
are just characters like any other in Preform. So
|
||||
|
||||
|making ( . ) !|
|
||||
|
||||
is just a sequence of five fixed-word tokens, and is read in the same literal
|
||||
way as:
|
||||
|
||||
|making the best of it|
|
||||
|
||||
Round brackets do not automatically break words in Preform, so |(c)| is not
|
||||
the same as |( c )|, even though it would be in Inform.
|
||||
|
||||
@ In fact, though, Preform does know that there is something special about
|
||||
round brackets |(| and |)|. If a production contains a pair of these, and the
|
||||
position of the |(| is uncertain, then Preform will only match them if they are
|
||||
correctly paired in the source text being looked at. Thus,
|
||||
|
||||
|friday ... ( ... )|
|
||||
|
||||
would match "Friday afternoon (but not Tuesday)", generating word ranges
|
||||
"afternoon" and "but not Tuesday"; applied to "Friday afternoon (not
|
||||
(Saturday)" it would generate "afternoon ( not" and "Saturday". This
|
||||
saves a great deal of time chasing useless possible matches.
|
||||
|
||||
@ There are a number of restrictions on what can be written in productions.
|
||||
We've decided to live with this, since Preform is hardly intended for
|
||||
general-purpose programming. Among the things which can't be done:
|
||||
|
||||
(a) There's no way to make a literal vertical stroke, arrow |==>|, or
|
||||
open or close squares |[| or |]|; though we can make literal braces
|
||||
using |\{| and |\}|.
|
||||
|
||||
(b) There's no way to make a literal double-quoted piece of text |"thus"|.
|
||||
This actually causes us a small amount of nuisance and is the reason there's
|
||||
an internal nonterminal <empty-text> rather than simply writing |""|.
|
||||
|
||||
(c) There's no way to make a literal word which contains one of the
|
||||
characters |_|, |^|, |{|, |}|, |\| but is longer than just that one
|
||||
character. For instance, you can't make |3^6| or |bat_man|, and |\{robin}|
|
||||
doesn't work.
|
||||
|
||||
The nuisance is worth it to enable us to use Inform's regular lexer to read
|
||||
Preform text.
|
||||
|
||||
@ This seems a good point to go into the names of nonterminals. Each name
|
||||
must be a single word in angle brackets, and can only include lower case
|
||||
letters "a" to "z", the digits 0 to 9, and hyphens; it must be at least
|
||||
three characters long, not counting the brackets; the first of those characters
|
||||
must be a lower-case letter, and the last must not be a hyphen. In other words,
|
||||
it must match the regular expression
|
||||
|
||||
|\<[a-z][a-z0-9-]+[a-z0-9]\>|
|
||||
|
||||
But those are only the rules; they wouldn't stop us naming the nonterminal for
|
||||
a description <julie-75>, say. In an attempt to bring order to what
|
||||
could easily be a confusion of names, the Inform source text follows these
|
||||
conventions:
|
||||
|
||||
(a) There are three subsets of the grammar which handle complicated tasks
|
||||
mostly isolated from the rest:
|
||||
|
||||
(-i) The K-grammar parses kind names, such as "list of relations of numbers".
|
||||
All nonterminals in the K-grammar begin with <k-...>.
|
||||
|
||||
(-ii) The NP-grammar parses noun phrases in assertion sentences, such as
|
||||
"a container on the table" as it occurs in the sentence "The tupperware
|
||||
box is a container on the table". All nonterminals in the NP-grammar begin
|
||||
with <np-...>.
|
||||
|
||||
(-iii) The S-grammar parses sentences as they occur in conditions, such as
|
||||
"an animal has been in the cage" as if occurs in the phrase "if an animal
|
||||
has been in the cage, ...". All nonterminals in the NP-grammar begin
|
||||
with <s-...>.
|
||||
|
||||
(b) Nonterminals used only to choose which problem message to issue -- used,
|
||||
that is, to parse text which is already known to be wrong -- have names
|
||||
ending <...-diagnosis>.
|
||||
|
||||
(c) Nonterminals which define names of constructions Inform needs to recognise
|
||||
in the Standard Rules have named which begin <notable-...>. For example,
|
||||
Inform needs to recognise the property "description" when it's defined,
|
||||
because the compiler needs to give this property special handling. Because
|
||||
the property is only ever created once, and only in English (since the Standard
|
||||
Rules are in English), nonterminals of the <notable-...> set never need
|
||||
to be translated into other languages.
|
||||
|
||||
(d) Similarly for nonterminals ending in <...-names>, which give
|
||||
names to (for instance) the built-in relations -- those not defined in the
|
||||
Standard Rules.
|
||||
|
||||
(e) As we shall see, there are about 20 sentence forms which have a special
|
||||
grammar to them: for example, "Understand ... as ..." sentences. The subject
|
||||
and object noun phrases for these sentences are parsed with nonterminals
|
||||
whose names end in <...-sentence-subject> and
|
||||
<...-sentence-object> respectively; for example,
|
||||
<understand-sentence-subject>.
|
||||
|
||||
(f) A nonterminal ending in <...-construction> is used not to
|
||||
parse text but to create it; these will be explained as they come up.
|
||||
|
||||
(g) A few nonterminals beginning <if-...> exist to test the
|
||||
current situation; they match if what they're testing is currently true,
|
||||
and fail otherwise, but they never match any words of the source text.
|
||||
|
||||
@ Finally, some notes on how Preform grammar is typeset in the PDF form of
|
||||
this source code:
|
||||
|
||||
(a) For visual clarity, nonterminal names such as |<ordinal-number>| are
|
||||
typeset as <ordinal-number>, as you've probably guessed.
|
||||
|
||||
(b) Italic letters {\it a}, {\it b}, {\it c}, ..., down the columns of
|
||||
productions are a form of line-numbering. They are provided for the benefit
|
||||
of anybody needing to refer to the productions individually (see above);
|
||||
non-translators can ignore them.
|
||||
|
||||
(c) Preform is a little more powerful than the description of it given
|
||||
above. For each production, it also has instructions on what to do if a
|
||||
successful match is made. These instructions usually just do something
|
||||
constructive with whatever information was found, but they can be more
|
||||
flexible. Those instructions are invisible in the {\it English
|
||||
Syntax of Inform} document, since they concern semantics rather than
|
||||
syntax, but in some cases there's some explanatory commentary in the
|
||||
right-hand margin:
|
||||
|
||||
(-c1) If a successful match to a production results in a Problem message
|
||||
being issued, then an arrow and the sigil for the Problem is given in
|
||||
the right margin. Inform has over 750 problems, each of which is identified
|
||||
with a unique sigil; for example, |PM_NoSuchPublicRelease|. (You can see
|
||||
these sigils in the debugging log if you cause a problem.)
|
||||
|
||||
(-c2) In a few cases -- mainly when parsing lists, where the computational
|
||||
complexity of the parser could make longer lists unacceptable slow -- there
|
||||
are bogus productions which appear to match any text at all. In the margin
|
||||
next to these is the text {\it match only when looking ahead}. This is a
|
||||
technicality to do with how the Preform parser works; productions like this
|
||||
can simply be ignored as far as syntax is concerned.
|
||||
|
||||
(-c3) A few productions are marked with a mysterious note such as
|
||||
{\it actions_plugin}. This means they are to be used only when that part
|
||||
of the Inform language definition is enabled; see "Plugins" for details.
|
||||
|
||||
(-c4) Some productions, when matched, do the reverse of what might be
|
||||
expected: instead of passing their nonterminal immediately, they fail it
|
||||
immediately. This is a convenient device to allow certain pieces of text
|
||||
to be parsed twice -- once to make sure it has a given form (failing the
|
||||
nonterminal if it doesn't), once to extract information from it.
|
||||
Productions like this are marked "fail" in the righthand margin.
|
||||
|
||||
(-c5) Moreover, some are marked "fail and skip". These are used when
|
||||
scanning text for certain configurations of words. If there's a match,
|
||||
not only does the current nonterminal fail, but Preform knows not to
|
||||
try again from the very next word: instead it advances to the wildcard
|
||||
text at the end of the production. (This is easier to follow in practical
|
||||
cases than in general explanations.)
|
||||
|
|
@ -1,269 +0,0 @@
|
|||
P/legal: Licence and Copyright Declaration.
|
||||
|
||||
A verbatim copy of the Artistic License 2.0, which governs the
|
||||
use and distribution of Inform 7 materials.
|
||||
|
||||
@h Declaration of copyright.
|
||||
The Inform 6 compiler and its associated library are copyright (c) Graham
|
||||
Nelson 1993-2007. The following materials associated with the Inform 7
|
||||
project are copyright (c) Graham Nelson 2003-2007: the source code to the
|
||||
NI compiler; the I6T template files; the "natural" version of the I6 library;
|
||||
the icons, images and other non-executable resources supplied for use
|
||||
within Inform user interfaces; the Inform 7 documentation and website,
|
||||
including the Examples; the Inform Tools Suite; and the test cases used for
|
||||
regression-testing with |intest|, their associated material and ideal
|
||||
results. The {\it Inform [6] Designer's Manual, Fourth Edition} (DM4) is
|
||||
copyright (c) Graham Nelson 2001. We will call this whole body of
|
||||
intellectual property, with the exception of the typeset and printed form
|
||||
of the DM4, "the Package".
|
||||
|
||||
GN is the primary author of the Package, but not the only one: indeed the
|
||||
examples were very largely written by Emily Short, and others have also
|
||||
made modest contributions. However, GN holds the copyright to all of it so
|
||||
that there is a single point of reference for licencing of Inform.
|
||||
|
||||
Note that this does {\it not} include the officially recognised Inform user
|
||||
interface applications: the authors of these programs retain their own
|
||||
copyrights and are responsible for their own licencing. (It is a condition
|
||||
to be officially recognised by the Inform project that some form of free
|
||||
licence be used: in practice, most have chosen the GPL version 2.)
|
||||
|
||||
@h The former Inform licence, 1993-2007.
|
||||
The Package was previously governed by a short, largely free but in some
|
||||
ways restrictive licence. (The text of this was published in the DM4, which
|
||||
is freely browsable online.)
|
||||
|
||||
The new licence is both more explicit and more liberal. The change was made
|
||||
for cultural reasons: over those years the Internet became a highly
|
||||
litigious domain, where even those who espouse freedoms are obsessed with
|
||||
the terms of licenses. Some users are now frightened off by any retention
|
||||
of rights by the author of software, worrying that the rug might be pulled
|
||||
at any moment. Some institutions enforce their ideological position by
|
||||
refusing to distribute software under a licence which they deem impure: for
|
||||
instance, under the old licence Inform could not be aggregated with Debian
|
||||
Linux, even though it had been completely free and open for 15 years. Also,
|
||||
there are some possible complications about the way NI and other components
|
||||
combine with GPL-licensed software for the user interfaces, and I feel
|
||||
reluctantly compelled to finally include a disclaimer of warranty, some
|
||||
degree of anti-patent-troll protection, and so forth -- something I dislike
|
||||
doing since it implicitly acknowledges some validity in such distasteful
|
||||
legal claims.
|
||||
|
||||
There are two practical differences between the old and new licences. First,
|
||||
the new licence removes the requirement that any work of IF compiled by Inform
|
||||
should name "Inform" in its banner text. Authors are now legally free to
|
||||
suppress the banner text altogether, though I hope they won't: it's only a
|
||||
small gesture of respect to all those who have worked on Inform, and costs
|
||||
nothing. Second, the old licence forbade (at any rate did not permit) the
|
||||
making of a modified version of Inform, whereas the new licence largely permits
|
||||
this (see below).
|
||||
|
||||
@h The current licence, 2008-.
|
||||
As from the first publication on the Inform website of the source code to
|
||||
Inform 7, in 2008:
|
||||
|
||||
(a) The Package is hereby placed under the Artistic License 2.0.
|
||||
(b) For the avoidance of doubt, the Author additionally grants the right
|
||||
for all users of the Package to make unlimited use of story files produced
|
||||
by the Package.
|
||||
|
||||
To clarify (b): the structure of Inform means that it copies large pieces
|
||||
of the I6 library and the I6T template files almost verbatim into the I6
|
||||
source code used to make a story file. Someone might then worry that any
|
||||
resulting story file is therefore a derivative work of the Package itself,
|
||||
and so inherits the Artistic License 2.0. The Author wishes to clarify that
|
||||
this is not the case, and that {\it people using Inform to make a story
|
||||
file can sell, distribute, modify or otherwise use it exactly as they
|
||||
please, and under any licence(s) they choose}. (The same issue arises with
|
||||
the Free Software Foundation's |bison|, and they solve it in the same way,
|
||||
by making an additional grant of rights on top of the licence for |bison|
|
||||
itself.)
|
||||
|
||||
@ The Artistic License 2.0, used by Perl among other notable projects, is
|
||||
widely considered to be one offering generous permissions for the user, and
|
||||
was chosen because:
|
||||
|
||||
(a) it is recognised by the Open Source Initiative as an open source licence;
|
||||
(b) it is recognised by the Free Software Foundation as a guarantee that the
|
||||
software is free not only in the economic way, but also in a more libertarian
|
||||
sense;
|
||||
(c) by freely allowing modifications and derivative works, but requiring any
|
||||
such to be issued under different names, it allows the authors to retain
|
||||
the moral right of authorship: the ability to decide what is, and is not,
|
||||
the Inform design.
|
||||
|
||||
The licence is the sole legal document governing these matters, of course,
|
||||
but our interpretation of clause (9) is that, in particular, it is legal to
|
||||
distribute an aggregation of the Package along with any of the recognised
|
||||
user interface application(s) and also with Extensions by third parties
|
||||
which are subject to the Creative Commons Attribution licence (such as
|
||||
those published on the Inform website), and to call the result "Inform".
|
||||
|
||||
The verbatim text of the licence now follows. It is copyrighted by the Perl
|
||||
Foundation, 2006, whose work in creating it we acknowledge with thanks.
|
||||
(The boldface section numbers in the typeset form of this preface are just
|
||||
typography, and not a part of the licence: but the clause numbers, "(10)"
|
||||
and so forth, are. The American spelling "license" is used, since that's
|
||||
how the Foundation wrote it.)
|
||||
|
||||
@h Preamble.
|
||||
This license establishes the terms under which a given free software
|
||||
Package may be copied, modified, distributed, and/or redistributed. The
|
||||
intent is that the Copyright Holder maintains some artistic control over
|
||||
the development of that Package while still keeping the Package available
|
||||
as open source and free software.
|
||||
|
||||
You are always permitted to make arrangements wholly outside of this
|
||||
license directly with the Copyright Holder of a given Package. If the terms
|
||||
of this license do not permit the full use that you propose to make of the
|
||||
Package, you should contact the Copyright Holder and seek a different
|
||||
licensing arrangement.
|
||||
|
||||
@h Definitions.
|
||||
{\it Copyright Holder} means the individual(s) or organization(s) named in
|
||||
the copyright notice for the entire Package. {\it Contributor} means any
|
||||
party that has contributed code or other material to the Package, in
|
||||
accordance with the Copyright Holder's procedures. {\it You} and {\it your}
|
||||
means any person who would like to copy, distribute, or modify the Package.
|
||||
{\it Package} means the collection of files distributed by the Copyright
|
||||
Holder, and derivatives of that collection and/or of those files. A given
|
||||
Package may consist of either the Standard Version, or a Modified Version.
|
||||
{\it Distribute} means providing a copy of the Package or making it
|
||||
accessible to anyone else, or in the case of a company or organization, to
|
||||
others outside of your company or organization. {\it Distributor Fee} means
|
||||
any fee that you charge for Distributing this Package or providing support
|
||||
for this Package to another party. It does not mean licensing fees. {\it
|
||||
Standard Version} refers to the Package if it has not been modified, or has
|
||||
been modified only in ways explicitly requested by the Copyright Holder.
|
||||
{\it Modified Version} means the Package, if it has been changed, and such
|
||||
changes were not explicitly requested by the Copyright Holder. {\it
|
||||
Original License} means this Artistic License as Distributed with the
|
||||
Standard Version of the Package, in its current version or as it may be
|
||||
modified by The Perl Foundation in the future. {\it Source} form means the
|
||||
source code, documentation source, and configuration files for the Package.
|
||||
{\it Compiled} form means the compiled bytecode, object code, binary, or
|
||||
any other form resulting from mechanical transformation or translation of
|
||||
the Source form.
|
||||
|
||||
@h Permission for Use and Modification Without Distribution.
|
||||
|
||||
(1) You are permitted to use the Standard Version and create and use
|
||||
Modified Versions for any purpose without restriction, provided that you do
|
||||
not Distribute the Modified Version.
|
||||
|
||||
@h Permissions for Redistribution of the Standard Version.
|
||||
|
||||
(2) You may Distribute verbatim copies of the Source form of the Standard
|
||||
Version of this Package in any medium without restriction, either gratis or
|
||||
for a Distributor Fee, provided that you duplicate all of the original
|
||||
copyright notices and associated disclaimers. At your discretion, such
|
||||
verbatim copies may or may not include a Compiled form of the Package.
|
||||
|
||||
(3) You may apply any bug fixes, portability changes, and other
|
||||
modifications made available from the Copyright Holder. The resulting
|
||||
Package will still be considered the Standard Version, and as such will be
|
||||
subject to the Original License.
|
||||
|
||||
@h Distribution of Modified Versions of the Package as Source.
|
||||
|
||||
(4) You may Distribute your Modified Version as Source (either gratis or
|
||||
for a Distributor Fee, and with or without a Compiled form of the Modified
|
||||
Version) provided that you clearly document how it differs from the
|
||||
Standard Version, including, but not limited to, documenting any
|
||||
non-standard features, executables, or modules, and provided that you do at
|
||||
least ONE of the following:
|
||||
|
||||
(a) make the Modified Version available to the Copyright Holder of the
|
||||
Standard Version, under the Original License, so that the Copyright Holder
|
||||
may include your modifications in the Standard Version.
|
||||
|
||||
(b) ensure that installation of your Modified Version does not prevent the
|
||||
user installing or running the Standard Version. In addition, the Modified
|
||||
Version must bear a name that is different from the name of the Standard
|
||||
Version.
|
||||
|
||||
(c) allow anyone who receives a copy of the Modified Version to make the
|
||||
Source form of the Modified Version available to others under
|
||||
|
||||
(i) the Original License or
|
||||
|
||||
(ii) a license that permits the licensee to freely copy, modify and
|
||||
redistribute the Modified Version using the same licensing terms that apply
|
||||
to the copy that the licensee received, and requires that the Source form
|
||||
of the Modified Version, and of any works derived from it, be made freely
|
||||
available in that license fees are prohibited but Distributor Fees are
|
||||
allowed.
|
||||
|
||||
@h Distribution of Compiled Forms of the Standard Version or Modified Versions without the Source.
|
||||
|
||||
(5) You may Distribute Compiled forms of the Standard Version without the
|
||||
Source, provided that you include complete instructions on how to get the
|
||||
Source of the Standard Version. Such instructions must be valid at the time
|
||||
of your distribution. If these instructions, at any time while you are
|
||||
carrying out such distribution, become invalid, you must provide new
|
||||
instructions on demand or cease further distribution. If you provide valid
|
||||
instructions or cease distribution within thirty days after you become
|
||||
aware that the instructions are invalid, then you do not forfeit any of
|
||||
your rights under this license.
|
||||
|
||||
(6) You may Distribute a Modified Version in Compiled form without the
|
||||
Source, provided that you comply with Section 4 with respect to the Source
|
||||
of the Modified Version.
|
||||
|
||||
@h Aggregating or Linking the Package.
|
||||
|
||||
(7) You may aggregate the Package (either the Standard Version or Modified
|
||||
Version) with other packages and Distribute the resulting aggregation
|
||||
provided that you do not charge a licensing fee for the Package.
|
||||
Distributor Fees are permitted, and licensing fees for other components in
|
||||
the aggregation are permitted. The terms of this license apply to the use
|
||||
and Distribution of the Standard or Modified Versions as included in the
|
||||
aggregation.
|
||||
|
||||
(8) You are permitted to link Modified and Standard Versions with other
|
||||
works, to embed the Package in a larger work of your own, or to build
|
||||
stand-alone binary or bytecode versions of applications that include the
|
||||
Package, and Distribute the result without restriction, provided the result
|
||||
does not expose a direct interface to the Package.
|
||||
|
||||
@h Items That are Not Considered Part of a Modified Version.
|
||||
|
||||
(9) Works (including, but not limited to, modules and scripts) that merely
|
||||
extend or make use of the Package, do not, by themselves, cause the Package
|
||||
to be a Modified Version. In addition, such works are not considered parts
|
||||
of the Package itself, and are not subject to the terms of this license.
|
||||
|
||||
@h General Provisions.
|
||||
|
||||
(10) Any use, modification, and distribution of the Standard or Modified
|
||||
Versions is governed by this Artistic License. By using, modifying or
|
||||
distributing the Package, you accept this license. Do not use, modify, or
|
||||
distribute the Package, if you do not accept this license.
|
||||
|
||||
(11) If your Modified Version has been derived from a Modified Version made
|
||||
by someone other than you, you are nevertheless required to ensure that
|
||||
your Modified Version complies with the requirements of this license.
|
||||
|
||||
(12) This license does not grant you the right to use any trademark,
|
||||
service mark, tradename, or logo of the Copyright Holder.
|
||||
|
||||
(13) This license includes the non-exclusive, worldwide, free-of-charge
|
||||
patent license to make, have made, use, offer to sell, sell, import and
|
||||
otherwise transfer the Package with respect to any patent claims licensable
|
||||
by the Copyright Holder that are necessarily infringed by the Package. If
|
||||
you institute patent litigation (including a cross-claim or counterclaim)
|
||||
against any party alleging that the Package constitutes direct or
|
||||
contributory patent infringement, then this Artistic License to you shall
|
||||
terminate on the date that such litigation is filed.
|
||||
|
||||
(14) Disclaimer of Warranty: THE PACKAGE IS PROVIDED BY THE COPYRIGHT
|
||||
HOLDER AND CONTRIBUTORS "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED
|
||||
WARRANTIES. THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
|
||||
PARTICULAR PURPOSE, OR NON-INFRINGEMENT ARE DISCLAIMED TO THE EXTENT
|
||||
PERMITTED BY YOUR LOCAL LAW. UNLESS REQUIRED BY LAW, NO COPYRIGHT HOLDER OR
|
||||
CONTRIBUTOR WILL BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, OR
|
||||
CONSEQUENTIAL DAMAGES ARISING IN ANY WAY OUT OF THE USE OF THE PACKAGE,
|
||||
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
@ That final burst of shouting concludes the verbatim text of the
|
||||
Artistic License 2.0, and we can now return to your scheduled program.
|
||||
|
|
@ -1,137 +0,0 @@
|
|||
P/pref: Preface.
|
||||
|
||||
An introduction to the reader.
|
||||
|
||||
@ Inform 7 is a free open-source system for the design of interactive fiction.
|
||||
This is the source code to NI, which is the component of I7 used for turning a
|
||||
natural language description of a model world into a valid implementation
|
||||
in Inform 6 (I6). This is one of the two uninteractive steps on the
|
||||
assembly line:
|
||||
$$ {\it Natural~language} \longrightarrow
|
||||
{\bf NI} \longrightarrow {\bf I6}
|
||||
\longrightarrow \cases{\hbox{\it Z-machine~story~file}&\cr
|
||||
\hbox{\it Glulx~story~file}&\cr} $$
|
||||
The Inform user interface automates this process and also supplies both
|
||||
ends: editing the natural language source and running the appropriate
|
||||
interpreter to play the resulting story file. The three user interfaces,
|
||||
by Andrew Hunter for Mac OS X, by David Kinder for Windows, and by
|
||||
Philip Chimento and Adam Thornton for Linux, are not documented here.
|
||||
|
||||
There are a further three substantial software layers needed to use I7:
|
||||
|
||||
(i) the Standard Rules file, written in I7 source text but with certain
|
||||
permitted additional syntaxes: this is formally an Extension, though its
|
||||
presence is essential;
|
||||
|
||||
(ii) the |.i6| files, written in a metalanguage resembling that of I6,
|
||||
which serves both as a repository of useful I6 routines for NI-compiled
|
||||
programs, and also as a description at the top level of what NI should
|
||||
do and in what order;
|
||||
|
||||
(iii) the "natural" variant of the I6 library, which is fundamentally
|
||||
the standard I6 library but with large parts of the action verb subroutines
|
||||
removed, and with numerous minor modifications and hooks added to the parser
|
||||
and the actions engine.
|
||||
|
||||
Any reader who has used I6 can take (iii) for granted, but a reading of (i)
|
||||
and (ii) might well be more useful in giving an appreciation of I7's internals
|
||||
than reading the NI source would be.
|
||||
|
||||
This is not intended as a manual for Inform 7: {\it Writing with Inform}
|
||||
and {\it The Inform Recipe Book}, the interleaved volumes of documentation
|
||||
included in the application and also published online, are the user guide.
|
||||
Nor is there much comment here on how the design was made: for some of the
|
||||
early history, see the "white paper" for the Inform 7 project, {\it Natural
|
||||
Language, Semantic Analysis and Interactive Fiction}, which covers the basic
|
||||
decisions made. The commentary in the source code assumes that the overall
|
||||
strategy is wise and gets on with its practical implementation.
|
||||
|
||||
@h Basic method.
|
||||
NI is a large but simple program. First, it reads the source text and
|
||||
breaks it up lexically into words, quoted matter and punctuation. Then
|
||||
it divides this stream of words into sentences, marking some out as
|
||||
headings and others as requests to include extensions, requests which
|
||||
are immediately carried out. When there is nothing further to input,
|
||||
sentences are sorted into assertions (statements about the initial state
|
||||
of the world) and rules (instructions concerning play). Assertions are
|
||||
generally copular sentences relating things together, such as "two
|
||||
coins are in a closed box", and these are parsed first into "meaning
|
||||
list" tree structures and thence into propositions in predicate calculus
|
||||
which are declared to be true at the start of play. Each such proposition
|
||||
is then interpreted to extract single facts called "inferences", and
|
||||
reasonable "common sense" guesses are made to add further facts, which
|
||||
have a lower level of certainty. When all assertions have been processed,
|
||||
the many inferences are reconciled to construct a spatial model of the
|
||||
world which, following Occam's razor, is as simple as it can be,
|
||||
consistent with the inferences. Only if this can be done without
|
||||
inconsistency are the remaining data structures built: tables defined in
|
||||
the source, and the parsing grammar. At last the rules are identified,
|
||||
placed into relevant rulebooks, sorted by scope of applicability, and
|
||||
compiled into I6 routines. The final task is to produce a report and an
|
||||
index.
|
||||
|
||||
Though Inform uses propositions in predicate calculus as an intermediate
|
||||
state to hold the meaning of sentences, it does not store knowledge that
|
||||
way; though it makes elementary deductions and substitutions, it does not
|
||||
contain a theorem-prover by unification. In the 1960s divide between the
|
||||
"scruffy" school of storing domain-specific knowledge (McCarthy, Minksy,
|
||||
Papert, et al.) versus the "neat" school of purely propositional logic
|
||||
(Robinson, Kowalski, Colmerauer, et al.), Inform is scruffy. McCarthy
|
||||
thought that a program with "common sense" is one which "automatically
|
||||
deduces for itself a sufficiently wide class of immediate consequences of
|
||||
anything it is told and what it already knows". He wrote that back in 1959
|
||||
and the "neat" methods have become astonishingly powerful since then --
|
||||
verifying the proof of the Prime Number Theorem via contour integration,
|
||||
for instance -- but where the programmer knows in advance what sort of
|
||||
knowledge the program will be dealing with, I think the scruffy methods
|
||||
still have it. At any rate, Inform is a working program for its end users,
|
||||
not an experiment in AI.
|
||||
|
||||
@h Organization into chapters.
|
||||
"I can't help feeling," wrote Michael Frayn recently, "that if someone
|
||||
had asked me before the universe began how it would turn out, I should have
|
||||
guessed something a bit less like an old curiosity shop and a bit more like
|
||||
a formal French garden -- an orderly arrangement of straight avenues,
|
||||
circular walks, and geometrically shaped trees and hedges." I have an
|
||||
uneasy feeling that the same might be said about Inform, but at its
|
||||
most basic level, it is organised in six layers:
|
||||
|
||||
(L1) services for memory management, output streams, file input/output, and the
|
||||
handling of text as a sequence of words;
|
||||
|
||||
(L2) the A-parser, which gathers the source text from its various locations
|
||||
and divides it into sentences whose basic form can be recognised;
|
||||
|
||||
(L3) the S-parser, which resolves smaller excerpts of text into meanings, and
|
||||
the necessary apparatus to describe, manipulate and compile these meanings;
|
||||
|
||||
(L4) the world-builder, which uses the A-parser and S-parser in combination
|
||||
to break down the assertions in the source text to see what facts can be
|
||||
inferred about the initial state of the world, and then assembles those into
|
||||
a model, compiling it to a suitable Inform 6 description;
|
||||
|
||||
(L5) the change agent, compiling the phrases which are the means by which
|
||||
the state of the model world changes at run-time; and organising the rules
|
||||
which use those phrases, and the rulebooks holding those rules; and the
|
||||
actions and activities which structure those rulebooks, and the run-time
|
||||
grammar of commands which invoke those actions;
|
||||
|
||||
(L6) a thin control layer on top, following instructions from the
|
||||
command line parameters and from the "template" which lays out Inform's
|
||||
sequence of operation.
|
||||
|
||||
@h Choice of language.
|
||||
NI is written in a literate programming extension of C called |inweb|.
|
||||
Besides interspersing documentation, this also provides concise syntax
|
||||
for parsing natural language; further apparent extensions, for logging
|
||||
to the debugging log and for automated memory allocation, are in fact
|
||||
provided by macros which are defined in the NI source.
|
||||
|
||||
To compile NI requires use of the Inform Tools, and in particular of
|
||||
|inweb|. A manual for each of the tools is included in the NI source
|
||||
(as documentation without code). Having compiled NI, it is important
|
||||
to check the result with |intest|: testing of bug fixes requires each
|
||||
change to be checked against a corpus of about 1200 test source texts.
|
||||
As of November 2008, this takes more than 3 minutes even using all four
|
||||
processors of a quad-3 GHz Mac Pro: it takes up to an hour on a Power
|
||||
PC-equipped iMac G4.
|
||||
|
|
@ -1,681 +0,0 @@
|
|||
P/champ: The Champollion Project.
|
||||
|
||||
This is a manifesto for the translation of Inform.
|
||||
|
||||
@h Preface.
|
||||
Inform is one of the hardest programs in the world to internationalise, that
|
||||
is, to adapt so that it can be used by speakers of many different languages.
|
||||
Until February 2011, Inform could read only English natural language, and
|
||||
the compiler was riddled with English-only assumptions. It contained nearly
|
||||
1000 words of hard-coded English vocabulary, for instance, which the user
|
||||
could do nothing to change. But that's no longer true, and it is time to
|
||||
begin looking forward to a multilingual Inform.
|
||||
|
||||
It will be a big task to reach this goal, and will need a lot of help from
|
||||
volunteers. A project as ambitious as this might as well have a name, so
|
||||
let's call it Champollion, after Jean-Fran\c cois Champollion (1790-1832),
|
||||
the decipherer of the Rosetta stone. (We shouldn't call it Rosetta since
|
||||
there's already a technology of that name, to do with processor architectures
|
||||
on Apple Macintosh computers.)
|
||||
|
||||
Saying "Inform runs in English" is too ambiguous. We need some definitions:
|
||||
|
||||
(a) The language of play is the natural language which an eventual player of a
|
||||
story file will read and type.
|
||||
|
||||
(b) The source language is the natural language in which a source text is
|
||||
written.
|
||||
|
||||
(c) The presentation language is the natural language used in Problem
|
||||
messages, in the Index, and so on.
|
||||
|
||||
(d) The documentation language is the natural language in which the two
|
||||
built-in manuals, {\it Writing with Inform} and {\it The Inform Recipe Book},
|
||||
are written.
|
||||
|
||||
(e) The interface language is the natural language used by the Inform user
|
||||
interface applications -- for menu items, window title bars, dialogue boxes
|
||||
and such.
|
||||
|
||||
@ The situation at the end of 2010 was as follows:
|
||||
|
||||
(a) The language of play can be any of English, French, German, Italian, and
|
||||
Spanish. An Inform author chooses this by including a suitable extension --
|
||||
for example, "Include Italian by Massimo Stella". The low-level Inform 6
|
||||
basis for run-time code has quite a good understanding of language, but
|
||||
Inform 7 doesn't.
|
||||
|
||||
(b) English only.
|
||||
|
||||
(c) English only.
|
||||
|
||||
(d) English only, though people have occasionally written to the authors
|
||||
to ask permission to translate parts of the documentation, so some work
|
||||
may have been done on this.
|
||||
|
||||
(e) English only.
|
||||
|
||||
Internationalising Inform 7 has always been a long-term goal, and work has
|
||||
quietly been going on towards this since 2006; but the next public build
|
||||
will make a big move in this direction. We're circulating a draft of this
|
||||
build to the current Inform translators well in advance, because it will
|
||||
be a big and disruptive change. Existing language extensions will need to
|
||||
be considerably extended, rearranged, and renamed. On the other hand,
|
||||
Inform's much better understanding of linguistics will make the new language
|
||||
extensions more powerful and flexible.
|
||||
|
||||
@ First of all, Inform now understands the concept of "natural language".
|
||||
When it starts up, it looks for folders called "language bundles" in the
|
||||
following places:
|
||||
|
||||
|X.materials -> Languages|
|
||||
|Library -> Inform -> Languages|
|
||||
|and a folder built in to Inform|
|
||||
|
||||
where "X" is the name of the project being compiled. (In other words, the
|
||||
rules for finding languages are exactly like those for finding extensions
|
||||
or website templates; if you create a language bundle called "French" in
|
||||
your materials folder, that takes precedence over a built-in one, and so on.)
|
||||
|
||||
Each language bundle is a single folder whose name must be the English name
|
||||
for the language: for example, "French", not "Fran\c cais".
|
||||
|
||||
The language bundle {\it does not replace} the language extensions we already
|
||||
have; Inform needs both. Bundles contain only a minimum amount of information,
|
||||
and copies for the existing translations will all be built in to Inform.
|
||||
Since the bundles will be part of core Inform, not in Extensions, translators
|
||||
who want to make changes will have to submit them to the Inform team. My
|
||||
hope is that (once we get them working) we will change these bundles very
|
||||
little.
|
||||
|
||||
At present, each bundle folder contains:
|
||||
|
||||
(a) A 16 by 11 pixel PNG flag icon called |flag.png|.
|
||||
|
||||
(b) A very small file of metadata about the language, called |about.txt|. This
|
||||
is a Unicode file, and contains at present just five pieces of information: (1)
|
||||
the language's name in English; (2) its native name, in its own language; (3) how
|
||||
the language would describe text written in itself; (4) the standard ISO 639-1
|
||||
two-letter language code; and (5) the name of the translator, that is, the
|
||||
author of the language extension. For example, for German:
|
||||
|
||||
|1 German|
|
||||
|2 Deutsch|
|
||||
|3 in deutscher Sprache|
|
||||
|4 de|
|
||||
|5 Team GerX|
|
||||
|
||||
Standard flag icons are from:
|
||||
|
||||
|http://www.famfamfam.com/lab/icons/flags/|
|
||||
|
||||
Standard language codes are from:
|
||||
|
||||
|http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes|
|
||||
|
||||
The language code is written to a new |<language>| field in the iFiction
|
||||
record of any game released; this enables IFDB to detect the language
|
||||
automatically.
|
||||
|
||||
In future the bundle folder will be able to hold other useful resources:
|
||||
translations of problem messages, for example.
|
||||
|
||||
The draft build for Inform has English, French, German, Italian and Spanish
|
||||
bundles already included, so you don't need to make these.
|
||||
|
||||
@ The way that the source text chooses a language has changed. Up to now,
|
||||
the user typed something like this:
|
||||
|
||||
>> Include French by Eric Forgeot.
|
||||
|
||||
With this draft build, the user doesn't type an inclusion sentence. Instead,
|
||||
the language is indicated in the titling line. There are two alternatives:
|
||||
either
|
||||
|
||||
>> "Les Filles du Calvaire" by Pierre Combescot (in French)
|
||||
|
||||
or
|
||||
|
||||
>> "Les Filles du Calvaire" par Pierre Combescot (en fran\c cais)
|
||||
|
||||
The first version says that the source text is in English, but that the
|
||||
language of play will be French. The second version says that both are
|
||||
in French. (This second version doesn't work yet, of course; but it's how
|
||||
we will do things when we get there.)
|
||||
|
||||
@ Language extensions are extensions like any others, except that they have
|
||||
to be named in a special way:
|
||||
|
||||
>> French Language by Eric Fourgeot
|
||||
>> Italian Language by Massimo Stella
|
||||
|
||||
and so on. Thus the first change translators will need to make is to rename
|
||||
the extension with "Language" added. Inform now has a built-in extension
|
||||
called
|
||||
|
||||
>> English Language by Graham Nelson
|
||||
|
||||
and the previous attempt at this (English by David Fisher) has been withdrawn.
|
||||
Note that all Inform projects automatically include English Language, even
|
||||
projects which play in other languages.
|
||||
|
||||
When Inform reads this:
|
||||
|
||||
>> "Les Filles du Calvaire" by Pierre Combescot (in French)
|
||||
|
||||
it still automatically loads the Standard Rules and English Language, but
|
||||
it also looks for an extension called French Language; if it finds this, it
|
||||
will include it.
|
||||
|
||||
The English Language extension is not like other language extensions, so
|
||||
don't use it as a model: instead, see the draft of French Language circulated
|
||||
with this document.
|
||||
|
||||
@ New-style language extensions are more complicated than existing ones, and
|
||||
they need to do more work. Inform aims to be able to tell stories in any
|
||||
tense, and from any viewpoint, and in any language -- this is quite an
|
||||
ambitious goal. It now has several kinds used for linguistics:
|
||||
|
||||
(a) "Natural language". An instance of this kind is created automatically
|
||||
for each language bundle Inform can see. The default value is "English
|
||||
language" (which Inform creates even if it can't find any bundles at all).
|
||||
The variable "language of play" has this kind, and is set to the language
|
||||
read and typed by the eventual player. It cannot be changed during play.
|
||||
|
||||
(b) "Grammatical gender". This is a kind with three instances: neuter gender,
|
||||
masculine gender, feminine gender. The default value is neuter gender. For a
|
||||
language like Danish where masc. and fem. have amalgamated into a "common"
|
||||
gender, use masculine for this. Don't define extra genders; they won't work.
|
||||
In a language with genders, every object has a grammatical gender as a property.
|
||||
(Inform also automatically gives it the Inform 6 |female| or |neuter| attribute
|
||||
to match, just as in previous builds.)
|
||||
|
||||
(c) "Grammatical tense". This has five instances by default: present tense,
|
||||
past tense, perfect tense, past perfect tense, future tense. Language
|
||||
extensions are allowed to create up to two additional tenses, but of course
|
||||
they then have to go to extra work to show Inform how to use them. French
|
||||
Language creates one extra, the past historic tense, as an example of this.
|
||||
The variable "story tense" is set to the tense in which the story is
|
||||
currently being printed: by default, the present tense, but this can be
|
||||
changed during play -- for instance, there could be a dream sequence in the
|
||||
future tense, or a memory of previous events told in the past tense.
|
||||
|
||||
(d) "Grammatical case". This is for noun cases such as nominative, dative,
|
||||
and so on, for languages which use them. Inform's support for this is mostly
|
||||
incomplete at present: the only cases are "nominative" and "accusative".
|
||||
But you can add more.
|
||||
|
||||
(e) "Narrative viewpoint". The narrative viewpoints are first person singular,
|
||||
second person singular, third person singular, first person plural, second
|
||||
person plural, and third person plural. The variable "story viewpoint" holds
|
||||
the one currently used, and can change during play.
|
||||
|
||||
For example, in English, the text
|
||||
|
||||
>> "[We] [open] [the noun], which [are] unlocked."
|
||||
|
||||
adapts itself automatically to story tense and story viewpoint as well as to
|
||||
the gender and number of the noun:
|
||||
|
||||
>> You open the cupboard, which is unlocked.
|
||||
>> He opened the cupboard, which was unlocked.
|
||||
>> We have opened the boxes, which have been unlocked.
|
||||
|
||||
In languages with genders, a list of objects with mixed genders is masculine.
|
||||
So, for example,
|
||||
|
||||
>> "[The list of things in the coffret]: [grand]."
|
||||
|
||||
could produce any of:
|
||||
|
||||
>> Le chien: grand.
|
||||
>> La baguette: grande.
|
||||
>> La baguette et la plume: grandes.
|
||||
>> Le complet et la cravate: grands.
|
||||
|
||||
@ Once a language extension is in place, Inform also makes it possible to
|
||||
write assertion sentences in the language of play. For example, here is part
|
||||
of one of Eric Forgeot's examples of French Inform:
|
||||
|
||||
>> The Grand Hall de Fihnargaia is a room. Some gardes are men in Grand Hall de Fihnargaia.
|
||||
|
||||
This can now be written like so:
|
||||
|
||||
>> Le Grand Hall de Fihnargaia est une place. Des gardes sont hommes dans le Grand Hall.
|
||||
|
||||
Note that Inform works out the genders and numbers from the articles and
|
||||
kinds (it knows that "hommes", men, are masculine in gender; it knows that
|
||||
"des" means a plural, and "une" means feminine singular, and so on).
|
||||
Eric's example continues:
|
||||
|
||||
>> Some lampes are female device in Petit Couloir.
|
||||
|
||||
We can now write this as:
|
||||
|
||||
>> Des lampes (f) sont m\'ecanismes dans Petit Couloir.
|
||||
|
||||
"Des" doesn't tell Inform the gender of what it refers to, and Inform
|
||||
doesn't know the word "lampe", so it doesn't know whether "Des lampes" is
|
||||
a masculine plural or a feminine plural. To help with this, Inform has a new
|
||||
feature: when an object is created, if its name ends (n), (f) or (m) then
|
||||
Inform will give it neuter, female or male gender.
|
||||
|
||||
Inform also allows us to use numbers from the language of play. For example:
|
||||
|
||||
>> Un gateau is a kind of thing. Quatre gateaux sont dans Petit Couloir.
|
||||
|
||||
As this example shows, we still aren't ready to write everything in French,
|
||||
but we get steadily closer. Here Inform does know that "gateau" is masculine,
|
||||
so four objects will be created, each with the name "gateau" and the masculine
|
||||
gender.
|
||||
|
||||
Finally, we can say that things are here, carried, or worn:
|
||||
|
||||
>> Des soldats (m) sont ici. Le ch\^apeau est port\'e. Le gadget est r\'ealis\'e.
|
||||
|
||||
@ To handle all of this, language extensions will now need to give Inform much
|
||||
more information than in past builds. English is actually quite a simple case,
|
||||
since it's not very inflected. In French, for example, "unlocked" would
|
||||
also need to adapt, in order to agree with the gender and number of the
|
||||
thing being opened. To do all of this, Inform needs much more help from
|
||||
language extensions.
|
||||
|
||||
Firstly, they will need some rearrangement, and I suggest the following
|
||||
heading structure.
|
||||
|
||||
@h Volume 1 - Settings.
|
||||
This is a single short section, of new material. Some basic choices are made
|
||||
here -- does the language have genders, does it have unusual tenses, and so
|
||||
on.
|
||||
|
||||
@h Volume 2 - Language.
|
||||
This contains the real linguistic work.
|
||||
|
||||
@h Part 2-1 - Determiners.
|
||||
|
||||
@h Chapter 2-1-1 - Articles.
|
||||
There are three tasks here:
|
||||
|
||||
(a) We provide equivalents to the text substitutions "[The ...]", since it makes
|
||||
text much more readable for very little work.
|
||||
|
||||
(b) We provide Preform grammar for definite and indefinite articles, and also
|
||||
for a few useful words like "ici" (French for "here"). Preform grammar is
|
||||
a new metalanguage inside Inform which expresses its syntax. This will
|
||||
eventually be used so that language bundles can completely replace English as
|
||||
the source text language, but that's for the future. Preform will not be
|
||||
explained here: see the document {\it The English Syntax of Inform} for more
|
||||
details.
|
||||
|
||||
(c) We provide the following Inform 6 constants, arrays, and routines, exactly
|
||||
as in past builds:
|
||||
|
||||
|LanguageAnimateGender|
|
||||
|LanguageInanimateGender|
|
||||
|LanguageContractionForms|
|
||||
|LanguageContraction|
|
||||
|LanguageArticles|
|
||||
|LanguageGNAsToArticles|
|
||||
|
||||
@h Chapter 2-1-2 - Numbers.
|
||||
We include the I6 array |LanguageNumbers| and routine |LanguageNumber|, which
|
||||
have not changed, but we also do something new: we include Preform grammar
|
||||
for the names of the small ordinal and cardinal numbers.
|
||||
|
||||
@h Part 2-2 - Nouns.
|
||||
|
||||
@h Chapter 2-2-2 - Pronouns and possessives for the player.
|
||||
English Language defines the following text substitutions:
|
||||
|
||||
|"[We]" or "[we]"|
|
||||
|"[Us]" or "[us]"|
|
||||
|"[Our]" or "[our]"|
|
||||
|"[Ours]" or "[ours]"|
|
||||
|"[Ourselves]" or "[ourselves]"|
|
||||
|
||||
In this section we define equivalents. Note that the style has changed; we
|
||||
are trying to avoid hyphenations, or names like |Him-or-Them|. (It isn't always
|
||||
possible.) In French, they come out to:
|
||||
|
||||
|"[Tu]" or "[tu]"|
|
||||
|"[Te]" or "[te]"|
|
||||
|"[Ton]" or "[ton]"|
|
||||
|"[Le tien]" or "[le tien]"|
|
||||
|
||||
and so on. A variable called "adaptive text viewpoint" tells Inform what
|
||||
person these are written from -- in this case, second person singular; whereas
|
||||
English uses second person plural.
|
||||
|
||||
@h Chapter 2-2-3 - Pronouns and possessives for other objects.
|
||||
These are similar, but easier. They are named from the third-person viewpoint
|
||||
with the same number as the adaptive text viewpoint; so in the case of French,
|
||||
we'll go with third person singular. We define:
|
||||
|
||||
|[celui] = that|
|
||||
|[il] = it as subject|
|
||||
|[le] = it as object|
|
||||
|[lui] = it as indirect object|
|
||||
|[son] = its as adjective, e.g., "its temperature"|
|
||||
|[le sien] = its as possessive pronoun, e.g., "that label is its"|
|
||||
|
||||
and similarly for its capitalised forms.
|
||||
|
||||
@h Chapter 2-2-4 - Directions.
|
||||
Here we use a new feature of Inform:
|
||||
|
||||
>> North translates into French as le nord.
|
||||
|
||||
This allows a language extension to give a French name to a kind or instance
|
||||
which already has an English name: in this case, the direction "north",
|
||||
which is created by the Standard Rules. The French name is the one used in
|
||||
play, both for printing and for command parsing. Note the article "le",
|
||||
which tells Inform the gender and number of the name (singular, masculine).
|
||||
This is all much easier than writing:
|
||||
|
||||
>> The printed name of north is "nord". North is male. Understand "nord" as north.
|
||||
|
||||
If there are abbreviated names for directions, this is where to put them:
|
||||
|
||||
>> Understand "nord-est/nordest" or "ne" as northeast.
|
||||
|
||||
@h Chapter 2-2-5 - Kinds.
|
||||
This is new material. We give translations of the names of all kinds of
|
||||
objects created in the Standard Rules or other built-in extensions.
|
||||
For example,
|
||||
|
||||
>> A player's holdall translates into French as un fourre-tout.
|
||||
|
||||
Note an important change: language extensions are now expected to translate
|
||||
for every extension built in to Inform, not just the Standard Rules. I've
|
||||
given each such extension a section number (2-2-5-1, and so on).
|
||||
|
||||
@h Chapter 2-2-6 - Plurals.
|
||||
This is new material. We must give Inform instructions on how to form the
|
||||
plural of a noun, and we do this by writing a "trie" using Preform grammar.
|
||||
|
||||
For more on tries, it may be helpful to see how Inform defines English
|
||||
inflections, since that's a simple case. See {\it The English Syntax
|
||||
of Inform} for more details.
|
||||
|
||||
The circulated draft of "French Language" defines a method like so:
|
||||
|
||||
(a) a list of about 25 irregular plurals, such as "pneu" to "pneus";
|
||||
(b) a general rule based on noun endings, such as that a noun ending in "eu"
|
||||
normally forms a plural by adding "x" -- for example "neveu" becomes
|
||||
"neveux";
|
||||
(c) a default rule to use if none of these apply -- add "s".
|
||||
|
||||
It's important to be as thorough as possible in covering irregularities and
|
||||
exceptions. (The ten most commonly used verbs in English and French, for
|
||||
example, are all irregular; but the writer will expect them to work.)
|
||||
|
||||
@h Chapter 2-2-7 - Cases.
|
||||
This will be significant for languages like German, but for French there's
|
||||
nothing to do. This part of Inform's adaptive text support is still being
|
||||
worked on.
|
||||
|
||||
@h Chapter 2-2-8 - Times of day.
|
||||
Inclusions of the I6 routines |PrintTimeOfDay|, |PrintTimeOfDayEnglish|,
|
||||
and |LanguageTimeOfDay|. These have not changed.
|
||||
|
||||
@h Part 2-3 - Adjectives.
|
||||
This is new material. Adjectives in Inform can have six different forms:
|
||||
neuter singular, neuter plural, masculine singular, masculine plural, feminine
|
||||
singular, feminine plural. In English all six forms are always the same, but
|
||||
that's not true in most other languages. Once again, we use tries to work
|
||||
from a base form (neuter singular) to the other five. For example, in
|
||||
French, suppose we start with "nouveau" as our base.
|
||||
|
||||
(a) The neuter singular is just "nouveau".
|
||||
|
||||
(b) The trie |<adjective-to-plural>| makes the neuter plural (n.p.), but we
|
||||
don't worry about this, because French doesn't use neuters anyway.
|
||||
|
||||
(c) The trie |<adjective-to-masculine-singular>| converts the n.s. to the
|
||||
m.s., but in French it doesn't change anything, i.e., we use the base text
|
||||
of the adjective as the m.s.
|
||||
|
||||
(d) The trie |<adjective-to-feminine-singular>| converts the n.s. to the
|
||||
f.s., turning "nouveau" into "nouvelle".
|
||||
|
||||
(e) The trie |<adjective-to-masculine-plural>| converts the m.s. to the m.p.,
|
||||
turning "nouveau" into "nouveaux".
|
||||
|
||||
(f) The trie |<adjective-to-feminine-plural>| converts the f.s. to the f.p.,
|
||||
turning "nouvelle" into "nouvelles".
|
||||
|
||||
A useful feature for adjectives: the following source text --
|
||||
|
||||
>> "Sample" (in French)
|
||||
>> Conjugatorium is a room.
|
||||
>> Test adjective (internal) with informatif.
|
||||
|
||||
-- causes Inform to print out all six forms for the adjective given, in this
|
||||
case, "informatif" (which doesn't have to be one defined already).
|
||||
|
||||
@h Part 2-4 - Verbs.
|
||||
This is the most challenging part of the language extension to write. We
|
||||
have to explain to Inform how to construct every person, in every tense,
|
||||
of every verb in the language, even highly irregular ones. English and
|
||||
French are contrasting here: English has very little inflection in the
|
||||
verb, but has about 640 irregular verbs, and has spelling rules which
|
||||
depend on pronunciation; French has only about half as many irregulars,
|
||||
but gives them an enormous variety of word endings.
|
||||
|
||||
@h Chapter 2-4-1 - Verb conjugations.
|
||||
Preform grammar is used in three different ways in Inform: to specify simple
|
||||
syntax; or to specify a trie, a device for altering word endings; or to
|
||||
specify a verb conjugation. It's an extremely flexible notation, allowing
|
||||
us to construct multiple stems and then apply endings depending on tense,
|
||||
mood (active or passive), sense (positive or negative), person, number;
|
||||
and we can mark certain words, such as participles, as needing adjectival
|
||||
agreement. This means that
|
||||
|
||||
>> In French craindre is a verb.
|
||||
|
||||
will automatically create a text substitution "[craignis]" which can
|
||||
come out in about 100 different forms: "a crainte" (a female person has
|
||||
been feared), "craignirent" (third-person plural past historic active),
|
||||
and so on. But we only get these benefits by writing an exhaustively
|
||||
detailed description; for French, it took 2200 lines of Preform code.
|
||||
|
||||
See {\it The English Syntax of Inform} and "French Language" for
|
||||
explanations of the notation here.
|
||||
|
||||
A useful feature for testing verb conjugation: the following source text --
|
||||
|
||||
>> "Sample" (in French)
|
||||
>> Conjugatorium is a room.
|
||||
>> Test verb (internal) with avoir.
|
||||
|
||||
-- causes Inform to print out its full conjugation for the verb "avoir"
|
||||
in French, and of course any verb can be placed there, including one which
|
||||
Inform doesn't otherwise define.
|
||||
|
||||
@h Chapter 2-4-2 - Meaningful verbs.
|
||||
"Meaningful" verbs are the ones which are defined with a meaning, like this:
|
||||
|
||||
>> In French avoir is a verb meaning to have.
|
||||
|
||||
We write a definition like this corresponding to each verb defined by Inform:
|
||||
to be, to have, to relate, to provide, to contain, and so on.
|
||||
|
||||
Once again this chapter is divided by sections, one section on each built-in
|
||||
extension which defines verbs.
|
||||
|
||||
@h Chapter 2-4-3 - Prepositions.
|
||||
And this is similar, but for prepositions:
|
||||
|
||||
>> In French \^etre voisin de is a verb meaning to be adjacent to.
|
||||
|
||||
@h Volume 3 - Responses.
|
||||
The main task of a language extension used to be to write many Inform
|
||||
constants:
|
||||
|
||||
|Constant CANTGO__TX = "Je ne peux pas aller dans cette direction.";|
|
||||
|
||||
and to define a huge I6 routine called |LanguageLM|, providing about 300
|
||||
"library messages". (If you wanted multiple viewpoints, you had to define
|
||||
the routine several times over.) However, the use of library messages wasn't
|
||||
universal across the Standard Rules, so translations used to have to replace a
|
||||
few rules from SR as well. Lastly, it was only possible to translate the text
|
||||
from the SR, not from, for example, useful built-in extensions like Locksmith
|
||||
or Rideable Vehicles.
|
||||
|
||||
All of that is changed. The |*__TX| constants no longer exist; all rules in
|
||||
the SR and other built-in extensions are routed through the new Responses
|
||||
system. These are all written in adaptive text so that they can appear in
|
||||
any tense, and so on. Library messages were numbered by action; responses
|
||||
are lettered (A, B, C, ...) within each named rule.
|
||||
|
||||
@h Part 3-1 - Responses.
|
||||
This is where we write out the responses in our new language. The draft
|
||||
"French Language" extension doesn't do this: a French speaker will have
|
||||
to fill all of this in, which really means converting the text from the
|
||||
old I6 format to the newer, and much more readable, I7 format. Here
|
||||
are some samples. We first define a meaningless verb and adjective, just
|
||||
so that Inform will be able to adapt them:
|
||||
|
||||
>> In French passer is a verb. In French ouvert is an adjective.
|
||||
|
||||
And now we set two responses:
|
||||
|
||||
>> Standard report waiting rule response (A) is "Le temps [passes]...".
|
||||
|
||||
>> Can't open what's already open rule response (A) is "[regarding the noun][Il] [es] déjà [ouvert]."
|
||||
|
||||
The RESPONSES testing command can help a great deal with this. For example,
|
||||
|
||||
|RESPONSES SET 1|
|
||||
|
||||
produces all of the definitions of the English messages, which you can cut
|
||||
and paste before you start translating.
|
||||
|
||||
@h Part 3-2 - The Final Question.
|
||||
Translations used to replace the little section in the Standard Rules which
|
||||
defined options for the final question. This is no longer necessary, because
|
||||
a new feature of Inform allows tables to be replaced:
|
||||
|
||||
|Table of Final Question Options (replaced)|
|
||||
|final question wording ...|
|
||||
|"RECOMMENCER" ...|
|
||||
|...|
|
||||
|
||||
That replacement table occupies this part.
|
||||
|
||||
@h Volume 4 - Command parsing.
|
||||
The remainder of the extension consists of material which hasn't changed.
|
||||
|
||||
@h Part 4-1 - Pronouns and possessives in commands.
|
||||
The Inform 6 definitions |LanguagePronouns| and |LanguageDescriptors|.
|
||||
|
||||
@h Part 4-2 - Understand grammar.
|
||||
This is where the "Understand" sentences should appear:
|
||||
|
||||
>> Understand "mode court" as preferring abbreviated room descriptions.
|
||||
|
||||
and so on. Note that by default the English command grammar still exists;
|
||||
you need to remove it if you don't want to allow English verbs.
|
||||
|
||||
This should also include grammar for the other built-in extensions (e.g.,
|
||||
for "Rideable Vehicles"), but the draft French Language doesn't yet do so.
|
||||
|
||||
@h Part 4-3 - Command parser internals.
|
||||
I6 definitions |LanguageVerb|, |LanguageVerbLikesAdverb| and
|
||||
|LanguageVerbMayBeName|; and the keywords used by the parser (|AGAIN1__WD|,
|
||||
and so on).
|
||||
|
||||
@h Part 4-4 - Informese translation of commands.
|
||||
The Inform 6 |LanguageToInformese| routine, and any supporting I6 code it
|
||||
needs.
|
||||
|
||||
@h Source text language: future developments.
|
||||
The ultimate goal is to be able to write the source text in the language
|
||||
of play. French Inform users will simply type their IF in French, and
|
||||
play the result in French; and similarly for other languages, of course.
|
||||
But this goal is still some way away.
|
||||
|
||||
At present, the plan is to do this in three phases:
|
||||
|
||||
(1) In Phase 1, the current draft build of Inform will be released.
|
||||
This will make the adaptive text and responses features available to users,
|
||||
but it will break all existing language extensions. So the draft build is
|
||||
being given to translators to give them a head-start in making new-style
|
||||
language extensions. Phase 1 will be complete when we have good-quality language
|
||||
extensions for all the main European languages currently supported: French,
|
||||
German, Italian and Spanish. German will need the most work, since noun
|
||||
inflection isn't yet finished.
|
||||
|
||||
(2) In Phase 2, a source text called "Rosetta" will be written, using the
|
||||
entire syntax of Inform. Volunteers will then be asked to translate Rosetta
|
||||
into their own languages, just as if they were translating a piece of text
|
||||
like a newspaper article. This will probably be quite boring to do, but it
|
||||
needs to be done well; the choices made might affect Inform for a long way
|
||||
into the future. Up to a point, of course, the translation should follow the
|
||||
English quite closely -- but it's important that German source text should
|
||||
read as natural to a German person, and so on. We don't want the whole thing
|
||||
to end up reading like a Japanese camera manual. Phase 2 will be complete when
|
||||
we have Rosetta in every language.
|
||||
|
||||
(3) In Phase 3, we use the Rosetta translations to write Preform syntax
|
||||
(and possibly other definitions) for languages other than English. Phase
|
||||
3 will be complete when Inform can compile Rosetta in every language.
|
||||
|
||||
As we make progress towards this goal, we will also want to do something
|
||||
about the languages used for presentation and documentation.
|
||||
|
||||
@h The presentation language. The main issue here is to do with Problem
|
||||
messages -- there are about 750 of them. At least the common ones need to be
|
||||
translated for two reasons; first, because we want people who don't know
|
||||
English well to be able to use Inform; second, because they often refer to
|
||||
correct Inform syntax. For example:
|
||||
|
||||
{\narrower ...this seems to give something a name which consists only of an article,
|
||||
that is, "a", "an", "the" or "some". This is not allowed since the
|
||||
potential for confusion is too high. (If you need, say, a room which
|
||||
the player sees as just "A", you can get this effect with: "A-Room is
|
||||
a room with printed name "A"".)}
|
||||
|
||||
If Inform is reading French source text then this message will be issued
|
||||
when somebody gives something the name "une", for example; so it will be
|
||||
very misleading in English.
|
||||
|
||||
Since 2008 or so, Inform has issued problem messages in a systematic way,
|
||||
giving each different message its own unique identifier -- for example,
|
||||
|PM_NoSuchPublicRelease|. These IDs are called "sigils". They never
|
||||
appear on screen and will not be translated, of course. Instead, Inform
|
||||
will allow translators to provide a file which gives a translation for each
|
||||
sigil. (In fact, it will allow them to translate only some problem messages:
|
||||
those which are translated will be used on screen, but with an icon allowing
|
||||
the user to see the English version instead; and those which haven't been
|
||||
translated will be given in English only.) Inform internally generates
|
||||
Problem messages using text like:
|
||||
|
||||
|While working on '%1', I needed to be able to make a default value|
|
||||
|for the kind '%2', but there's no obvious way to make one.|
|
||||
|
||||
So it should be fairly straightforward to enable Inform to read in other-language
|
||||
versions of these messages from a file in the language bundle.
|
||||
|
||||
Testing these problem messages is another matter. We have a suite of 750
|
||||
test cases which generate them, and an automated tool, |intest|, for checking
|
||||
that they are all correctly produced, but those test cases are all written
|
||||
in English. If you want to test the French version of |PM_NoSuchPublicRelease|,
|
||||
you'll first have to translate its test case into French.
|
||||
|
||||
@h The documentation language. Inform generates the HTML form of its manuals
|
||||
used in the applications from a marked-up plain text version, using a special
|
||||
tool called |indoc|. In principle, there's no reason why the plain text
|
||||
version shouldn't be run through |indoc| as well, though there are some
|
||||
practical issues to sort out about where the HTML will be stored -- perhaps,
|
||||
once again, in the relevant language bundle.
|
||||
|
||||
However, it's not a small task to translate whole books -- not to mention
|
||||
the many, many Examples - and since the documentation has to talk about the
|
||||
source syntax, we really shouldn't even start this process until the syntax
|
||||
for each language has been worked out.
|
||||
|
||||
@h The interface language. This should be quite easy to change, though it's our
|
||||
lowest priority. Mac OS X, Windows and Gnome for Linux all provide standard
|
||||
ways to do this. The inconvenient point is that they are different ways on
|
||||
each platform, so the work needs to be done three times.
|
||||
|
|
@ -12,6 +12,23 @@ Inform is often assigned material for courses on digital narrative).
|
|||
It has twice ranked in the top 100 most influential programming languages
|
||||
according to the TIOBE index.
|
||||
|
||||
## Licence
|
||||
|
||||
Except as noted, copyright in material in this repository (the "Package") is
|
||||
held by Graham Nelson (the "Author"), who retains copyright so that there is
|
||||
a single point of reference. As from the first date of this repository
|
||||
becoming public, the Package is placed under the [Artistic License 2.0](https://opensource.org/licenses/Artistic-2.0).
|
||||
This is a highly permissive licence, used by Perl among other notable projects,
|
||||
recognised by the Open Source Initiative as open and by the Free Software
|
||||
Foundation as free in both senses.
|
||||
|
||||
For the avoidance of doubt, the Author makes the further grant that users of
|
||||
the Package may make unlimited use of story files produced by the Package:
|
||||
such story files are not derivative works of Inform and do not inherit the
|
||||
Artistic License 2.0 as an obligation. (This further grant follows the
|
||||
practice of projects like bison, which also copy substantial code into
|
||||
their outputs.)
|
||||
|
||||
## Repositories
|
||||
|
||||
This is the "core repository", holding source code for the compiler, and
|
||||
|
|
@ -52,6 +69,12 @@ sounds like a helicopter taking off.
|
|||
|
||||
## Inventory
|
||||
|
||||
"I can't help feeling that if someone had asked me before the universe began
|
||||
how it would turn out, I should have guessed something a bit less like an old
|
||||
curiosity shop and a bit more like a formal French garden — an orderly
|
||||
arrangement of straight avenues, circular walks, and geometrically shaped
|
||||
trees and hedges." (Michael Frayn)
|
||||
|
||||
Inform is not a single program: while the Inform 7 compiler builds to a single
|
||||
executable file, this is only useful in concert with other tools (notably the
|
||||
Inform 6 compiler and the Inblorb packager), with standard libraries of code
|
||||
|
|
|
|||
|
|
@ -342,6 +342,7 @@ pages:
|
|||
$(INPOLICYX) -write-me scripts/READMEscript.txt
|
||||
$(INWEBX) inblorb -weave-docs -weave-into docs/inblorb
|
||||
$(INWEBX) indoc -weave-docs -weave-into docs/indoc
|
||||
$(INWEBX) inform7 -weave-docs -weave-into docs/inform7
|
||||
$(INWEBX) inpolicy -weave-docs -weave-into docs/inpolicy
|
||||
$(INWEBX) inrtps -weave-docs -weave-into docs/inrtps
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue