mirror of
https://github.com/ganelson/inform.git
synced 2024-06-29 05:24:57 +03:00
typos in services/*/*.w
This commit is contained in:
parent
bfe5a878c5
commit
6f4fecec72
|
@ -428,7 +428,7 @@ int TargetVMs::compatible_with(target_vm *VM, text_stream *token) {
|
|||
return FALSE;
|
||||
}
|
||||
|
||||
@h Ootions.
|
||||
@h Options.
|
||||
Final code-generators can call this to see what special requests were made.
|
||||
|
||||
=
|
||||
|
|
|
@ -151,7 +151,7 @@ void Calculus::Schemas::append(i6_schema *sch, char *fmt, ...) {
|
|||
|
||||
@ We recognise only a few escapes here: |%%|, a literal percentage sign; |%d|,
|
||||
an integer; |%s|, a C string; |%S|, a text stream; and three which are higher-level:
|
||||
(a) |%k| takes a |kind| parameter and exoands to its weak ID;
|
||||
(a) |%k| takes a |kind| parameter and expands to its weak ID;
|
||||
(b) |%L| takes a |local_variable| and expands to its identifier;
|
||||
(c) |%n| takes an |inter_name|, which expands more cautiously in a way which
|
||||
stores the actual |inter_name| reference: it is possible for two different
|
||||
|
|
|
@ -224,7 +224,7 @@ the conjunction of the two propositions had 26 variables.)
|
|||
if (k == 26) next_unused = 25; else next_unused = k;
|
||||
|
||||
@h Getting rid of free variables.
|
||||
Propositions with free variables are vague, and Inforn tries to minimise its
|
||||
Propositions with free variables are vague, and Inform tries to minimise its
|
||||
use of them. Whole verb phrases such as "the tree is in the Courtyard" can in
|
||||
general become propositions with no free variables, while descriptions such as
|
||||
"open containers which are in lighted rooms" will become propositions in which
|
||||
|
@ -256,7 +256,7 @@ pcalc_prop *Binding::bind_existential(pcalc_prop *prop,
|
|||
}
|
||||
|
||||
@ The second way is "substitution", for use when we do know the value of the
|
||||
free variable we want to remove. We replace every mention of it with sone
|
||||
free variable we want to remove. We replace every mention of it with some
|
||||
other term: but as we shall see, this is trickier than it seems.
|
||||
|
||||
We begin with two utility routines to substitute into the variable "underneath"
|
||||
|
|
|
@ -273,7 +273,7 @@ int Propositions::is_complex(pcalc_prop *prop) {
|
|||
}
|
||||
|
||||
@h Primitive operations on propositions.
|
||||
Now for some basic operations, as shown in the following examoles:
|
||||
Now for some basic operations, as shown in the following examples:
|
||||
= (text from Figures/operations.txt as REPL)
|
||||
|
||||
Note that the conjunction of A and B renamed the variable |x| in B to |y|,
|
||||
|
|
|
@ -131,7 +131,7 @@ and |prime(n)|.
|
|||
@h Unary predicates.
|
||||
The //calculus// module aims to be agnostic about what unary predicates will
|
||||
exist. They are grouped into "families" -- see //Unary Predicate Families//
|
||||
for details -- which loosely group them by implementation. So, for exanple,
|
||||
for details -- which loosely group them by implementation. So, for example,
|
||||
Inform has a family of unary predicates in the form |calling='whatever'(x)|
|
||||
which assert that |x| represents something of a given name. But //calculus//
|
||||
is not concerned with the details. Only one family is built in:
|
||||
|
|
|
@ -38,7 +38,7 @@ localisation_dictionary *Localisation::new(void) {
|
|||
a typical entry might be |Index.Pages.Kinds.Caption|. At present, we do not
|
||||
take advantage of this to make a more efficient search (one could imagine
|
||||
a tree structure of dictionaries): we just use these path-like identifiers
|
||||
as keys to a single dictionary. If we ever need really large localisatiom
|
||||
as keys to a single dictionary. If we ever need really large localisation
|
||||
dictionaries, we might revisit this.
|
||||
|
||||
=
|
||||
|
|
|
@ -4,7 +4,7 @@ Lexical clusters are sets of noun or adjective forms, perhaps multiple
|
|||
or in multiple languages, which have in common that they share a meaning.
|
||||
|
||||
@h Cluster.
|
||||
A cluster is a linked list of declensions, annotated with lingistic roles. For
|
||||
A cluster is a linked list of declensions, annotated with linguistic roles. For
|
||||
example, the cluster of forms for the common noun "man" might be:
|
||||
|
||||
>> man (En, neuter singular), men (En, neuter plural), homme (Fr, masculine singular), hommes (Fr, masculine plural)
|
||||
|
|
|
@ -219,9 +219,9 @@ int Lcon::same_but_for_sense(lcon_ti A, lcon_ti B) {
|
|||
@h Axes.
|
||||
We can think of a combination of the seven grammatical attributes above as
|
||||
being like a position in seven-dimensional space, with each being a coordinate
|
||||
on one of these sevem axes.
|
||||
on one of these seven axes.
|
||||
|
||||
In practice, we're oftem interested in only a few of the seven. Nouns, for
|
||||
In practice, we're often interested in only a few of the seven. Nouns, for
|
||||
instance, do not have tenses; verbs do not have cases. It's convenient to
|
||||
represent the seven axes by the following constants, so that an arbitrary
|
||||
sum of these can represent a set of things we're interested in:
|
||||
|
|
|
@ -535,8 +535,8 @@ void Kinds::mark_vocabulary_as_kind(vocabulary_entry *ve, kind *K) {
|
|||
}
|
||||
|
||||
@h From context.
|
||||
Sometimes we need to kmow the current values of the 26 kind variables, A
|
||||
to Z: that depemds on a much wider context than the |kinds| module can see,
|
||||
Sometimes we need to know the current values of the 26 kind variables, A
|
||||
to Z: that depends on a much wider context than the |kinds| module can see,
|
||||
so we need the client to help us. |v| is in the range 1 to 26. Returning
|
||||
|NULL| means there is no current meaning; so if the client provides no
|
||||
function to tell us, then all variables are permanently unset.
|
||||
|
|
|
@ -137,7 +137,7 @@ written as |k| and |l| (note lower case). So, for example, |list of k|.
|
|||
|
||||
|terms| is used only for proper constructors. For a unary constructor, it will
|
||||
give one term; for binary, two terms, separated by a comma. Each term should
|
||||
be |covariant| or |contravariant|, with an ootional keyword after it:
|
||||
be |covariant| or |contravariant|, with an optional keyword after it:
|
||||
(*) |optional| means that it is legal to name the constructor without naming
|
||||
this term. For example, "activity" is a legal way to say "activity on nothing".
|
||||
(*) |list| means that it is legal to give a list of kinds here, in brackets
|
||||
|
|
|
@ -276,7 +276,7 @@ any, results from performing an arithmetic operation.
|
|||
traditional usage of "type constructor", but note that Haskell and some other
|
||||
functional languages mean something related but different by this.
|
||||
|
||||
[2] So, for examole, Inform acts on text like "A weight is a kind of value." by
|
||||
[2] So, for example, Inform acts on text like "A weight is a kind of value." by
|
||||
calling //Kinds::new_base//.
|
||||
|
||||
[3] Inform's built-in kinds like |number| or |text| all come from such files,
|
||||
|
|
|
@ -38,7 +38,7 @@ For example, the parent could define |INGREDIENTS_MC| and |RECIPES_MC| to
|
|||
have two different namespaces, and then define |EXACT_PARSING_BITMAP| to
|
||||
be |INGREDIENTS_MC + RECIPES_MC| to make both of them parsed exactly.
|
||||
|
||||
Mimimal default settings are made if the parent doesn't create these
|
||||
Minimal default settings are made if the parent doesn't create these
|
||||
constants.
|
||||
|
||||
@h Using callbacks.
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
To specify standard verb-phrase nodes in the parse tree.
|
||||
|
||||
@ This section lays out a sort of specification for what we ultinately want
|
||||
@ This section lays out a sort of specification for what we ultimately want
|
||||
to turn sentences into: i.e., little sentence diagrams made up of parse nodes.
|
||||
We do that with the aid of the //syntax// module. So we must first set up
|
||||
some new node types:
|
||||
|
|
|
@ -225,7 +225,7 @@ small_word_set *Articles::add(small_word_set *sws, nonterminal *nt, article *a)
|
|||
|
||||
@h English articles.
|
||||
So, then, these nonterminals are not parsed by Preform but are instead used
|
||||
to stock small word sets above. The fornat is the same as the one used in
|
||||
to stock small word sets above. The format is the same as the one used in
|
||||
//Pronouns//: rows are cases, within which the sequence is neuter singular,
|
||||
neuter plural, masculine singular, masculine plural, feminine singular,
|
||||
feminine plural. In English, of course, articles hardly inflect at all,
|
||||
|
|
|
@ -248,7 +248,7 @@ we might have |TW| being "is in the green bucket".
|
|||
for (verb_usage *vu = tier->tier_contents; vu; vu = vu->next_within_tier)
|
||||
@<Consider whether this usage is being made at this position@>;
|
||||
|
||||
@ We must test whether our verb usage appears at the front of |TW|, thougn for
|
||||
@ We must test whether our verb usage appears at the front of |TW|, though for
|
||||
efficiency's sake we first test whether the verb has a meaning. (There are
|
||||
potentially a great many meaningless verbs, because of the way adaptive text
|
||||
is handled in Inform.)
|
||||
|
|
|
@ -76,7 +76,7 @@ error message and return |FALSE|. If this callback is not provided, all non-empt
|
|||
names are acceptable. See //Adjectives::declare//.
|
||||
|
||||
(*) |ALLOW_VERB_IN_ASSERTIONS_LINGUISTICS_CALLBACK| and |ALLOW_VERB_LINGUISTICS_CALLBACK|
|
||||
give the parent control over which forms of verbs are allowed: for examole, //core//
|
||||
give the parent control over which forms of verbs are allowed: for example, //core//
|
||||
allows them in assertions only in the third person (singular or plural), whereas
|
||||
it allows them in any form in non-assertion contexts. See
|
||||
//VerbUsages::register_voices_of_verb//.
|
||||
|
|
|
@ -208,6 +208,6 @@ asymmetric roles because the action is done by Peter but to the ball, and
|
|||
@h Performance in practice.
|
||||
The following tabulates the linguistic stock accumulated by a typical Inform 7
|
||||
compilation (the same one used to generate the data in //inform7: Performance Metrics//).
|
||||
Within each categpry, items are listed in order of creation.
|
||||
Within each category, items are listed in order of creation.
|
||||
|
||||
= (hyperlinked undisplayed text from Figures/stock-diagnostics.txt)
|
||||
|
|
|
@ -127,7 +127,7 @@ text used by //StandardProblems::sentence_problem//.
|
|||
=
|
||||
Here the punctuation; |%3| is expected to end with a full stop and |%2| not to.
|
||||
|
||||
Finally, the escape |%P| means "poragraph break here", and is used for adding
|
||||
Finally, the escape |%P| means "paragraph break here", and is used for adding
|
||||
subsequent clarifications to long or complicated problems.
|
||||
|
||||
@ //Problems, Level 3// contains functions for standardly-shaped problems, then.
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
Setting up the use of this module.
|
||||
|
||||
@ This section simoly sets up the module in ways expected by //foundation//,
|
||||
@ This section simply sets up the module in ways expected by //foundation//,
|
||||
and contains no code of interest. The following constant exists only in tools
|
||||
which use this module:
|
||||
|
||||
|
|
|
@ -37,7 +37,7 @@ useful for other projects.
|
|||
|
||||
The idea here is that we want an identifier based on a natural language
|
||||
wording, but which passed the above validity tests, and which does not lead
|
||||
tp namespace collisions. Such identifiers are composed in a pattern which
|
||||
to namespace collisions. Such identifiers are composed in a pattern which
|
||||
uses an identifying letter (e.g., A for Action), a unique ID number
|
||||
(preventing name-clashes) and then a truncated alphanumeric-safe form of
|
||||
the words used in the textual description, if any. For example, an object
|
||||
|
|
|
@ -87,7 +87,7 @@ pointer results. For example, you could make a very crude calculator with:
|
|||
<cardinal-number> plus <cardinal-number> ==> { R[1]+R[2], - }
|
||||
=
|
||||
Here |R[1]+R[2]| produces a result by composition of the two results of
|
||||
the <cardinal-number> nontermimal which occurred when parsing the line.
|
||||
the <cardinal-number> nonterminal which occurred when parsing the line.
|
||||
So, for example, "seven" matches <arithmetic> with result 7, and "two plus
|
||||
three" with result 5.
|
||||
|
||||
|
|
|
@ -481,7 +481,7 @@ rather than the next number counting upwards; see //About Preform//.
|
|||
"too many tokens on production for nonterminal");
|
||||
}
|
||||
|
||||
@ Here we porse what is, to the Lexer, a single word (at word number |wn|),
|
||||
@ Here we parse what is, to the Lexer, a single word (at word number |wn|),
|
||||
but which might actually be a row of possibilities divided by slashes:
|
||||
for example, |onions/shallots|.
|
||||
|
||||
|
|
|
@ -124,7 +124,7 @@ an internal NT, or try all possible productions for a regular one.
|
|||
@h Middle level.
|
||||
So from here on down we look only at the regular case, where we're parsing the
|
||||
text against a production. Recall that a production's NTIC has the "ditto flag"
|
||||
if it is the same constraint as the previous productions's NTIC; in which
|
||||
if it is the same constraint as the previous production's NTIC; in which
|
||||
case we have no need to recompute |violates|.
|
||||
|
||||
@<Try to match to a production@> =
|
||||
|
|
Loading…
Reference in a new issue