1
0
Fork 0
mirror of https://github.com/ganelson/inform.git synced 2024-06-26 04:00:43 +03:00

inform7/** typos

This commit is contained in:
Andrew 2022-04-30 10:00:24 -05:00
parent bfe5a878c5
commit 8721f499ae
38 changed files with 49 additions and 49 deletions

View file

@ -455,7 +455,7 @@ Note that a header file called |inform7_symbols.h| is included. This defines
useful constants like |i7_A_Take| (for the "taking" action) and |i7_I_Linear_B_tablet|
(for the object called "Linear B tablet"). But where did this header come from?
The answer is that this file can ootionally be created when //inform7// is
The answer is that this file can optionally be created when //inform7// is
generating C. In Example 5 we ran Inform with |-format=C/no-main|; this time
we use |-format=C/no-main/symbols-header|. This also needs a subtle change to
the makefile logic; the difference being that |Eg6-C.o| is now dependent on
@ -477,7 +477,7 @@ Eg6-I.c: Eg6.i7
Anyway, the result of this is:
= (text as ConsoleText)
Sir Arthur Evans, hero and archeologist, invites you to explore...
Sir Arthur Evans, hero and archaeologist, invites you to explore...
Welcome
An Interactive Fiction

View file

@ -22,7 +22,7 @@ Nobody who defines a literal pattern with the word "times" in can expect good
results anyway, given that "times" will usually be interpreted as
multiplication when Inform eventually parses such a literal.
@ We create new literal pattenrs during pass 1, which imposes two timing
@ We create new literal patterns during pass 1, which imposes two timing
constraints:
(a) The specification sentence must come after the sentence creating the

View file

@ -153,7 +153,7 @@ void ImperativeDefinitions::compile_first_block(void) {
@h The body.
During assessment, then, each //imperative_defn// is given a body, which
is one of these. It reoresents the body of the definition -- that is, the
is one of these. It represents the body of the definition -- that is, the
Inform 7 source text written underneath the heading.
=

View file

@ -6,11 +6,11 @@ with which the user can choose to invoke a To phrase.
@h Introduction.
A "phrase option" is a sort of modifier tacked on to an invocation of a
phrase; the only modifiers allowed are those declared in that phrase's
preamble. Phrase pptions are an early feature of Inform 7 going back to a
preamble. Phrase options are an early feature of Inform 7 going back to a
time when its priority was to enable the paraphrasing of Inform 6 library
features (such as the bitmap passed as a parameter to the list-printer).
I now sligjtly regret the existence of phrase options, but above all the
I now slightly regret the existence of phrase options, but above all the
comma-based syntax used for them, as here. Brackets would have been better;
it makes phrase options impossible to use for text substitutions.

View file

@ -24,7 +24,7 @@ typedef struct booking {
int placement; /* one of the |*_PLACEMENT| values above */
int place_automatically; /* should this be inserted automatically? */
struct booking_commentary commentary; /* used omly for indexing and code comments */
struct booking_commentary commentary; /* used only for indexing and code comments */
struct booking *next_booking; /* in its booking list */
CLASS_DEFINITION

View file

@ -85,7 +85,7 @@ making of the new activity.
@h Regular meanings.
As noted above, //Assertions::make_coupling// is called on each regular
assertion: coupling being a lingistic term for placing subject and object into
assertion: coupling being a linguistic term for placing subject and object into
a relationship with each other. What it does is to split into cases according to
the subject and object phrases of a sentence. These can take 12 different forms,
so there are $12\times 12 = 144$ possible combinations of subject with object,

View file

@ -8,7 +8,7 @@ Setting up the use of this module.
@ Like all modules, this one must define a |start| and |end| function.
Note that the "core" plugin itself does nothihg except to be a parent to the
Note that the "core" plugin itself does nothing except to be a parent to the
other two; it doesn't even have an activation function.
@e TASK_QUEUE_DA

View file

@ -349,7 +349,7 @@ By default the story file will be called something like |story.z8|, but
its leafname is actually declared from the source text of the Inform
project created to do this wrapping-up. So we need a way to set as well
as read this filename. Whatever the leafname, though, it lives in the top
level of materuals.
level of materials.
=
int Task::wraps_existing_storyfile(void) {

View file

@ -6,7 +6,7 @@ Interface to the Problems module.
@d PROBLEMS_HTML_EMITTER HTML::put
@ In "silence-is-goldem" mode, we want our Problem messages to look more like
@ In "silence-is-golden" mode, we want our Problem messages to look more like
traditional Unix errors, even if they're long ones:
@d FORMAT_CONSOLE_PROBLEMS_CALLBACK Problems::Using::console_format

View file

@ -359,7 +359,7 @@ int PluginCalls::new_base_kind_notify(kind *K, kind *super, text_stream *d, word
been created. For example, the figures plugin needs to know this so that it
can see when a new illustration has been created.
At the time this is called, the exact kind of an instance may not be knowm,
At the time this is called, the exact kind of an instance may not be known,
if that instance is an object: so beware of relying on the kind unless you're
sure you're not dealing with an object.

View file

@ -43,7 +43,7 @@ produce Inform 6 code. That is not so: they produce Inter code, which
can then be translated as needed.
Most of the definitions here also have annotations to positions in the
main Inform dcumentation: for example, |(documented at phs_s)|. This has
main Inform documentation: for example, |(documented at phs_s)|. This has
no effect on the code compiled, and is used only when Inform generates
certain problem messages; if the source text misuses the phrase, the problem
can then give a reference to the relevant documentation. |phs_s| is a

View file

@ -638,7 +638,7 @@ To decide whether player consents
(- YesOrNo() -).
@ Support for snippets, which are substrings of the player's command. This
is a kind of value which doesm't exist in Basic Inform.
is a kind of value which doesn't exist in Basic Inform.
=
Section 2 - The player's command

View file

@ -365,7 +365,7 @@ interpretation of words like "inside" which might refer either to the
Of the rest, N/S, NE/SW, E/W, SE/NW and U/D, it's noteworthy that this
choice imposes a cubical grid on the world, simply because the compass
directions are at 45 and 90 degree angles to each other: a hexagonal
tessalation would be more faithful to distances (it would get rid of the
tessellation would be more faithful to distances (it would get rid of the
awkward point that a NE move is root 2 times the length of a N move),
but in practice the world model doesn't care much about distances, another
example of its qualitative nature. A further point is that, in a
@ -659,7 +659,7 @@ than HER or IT). There has to be some convention here, and in a case where
we don't know our linguistic ground, opting for the least surprising
behaviour seems wisest.
The Inform compiler automatically applies the either-or prpperty |animate|
The Inform compiler automatically applies the either-or property |animate|
and the valued property |before| to a person, giving that value as just
|NULL|. This allows any person to become the protagonist during play
(using I6's |ChangePlayer| routine).

View file

@ -36,7 +36,7 @@ The verb to index map with in the imperative means the built-in index-map-with m
@h Use Options.
In fact, many of the definitions below are handled slightly differently in
the |srules| template files, to avoid the need for conditional compilatipn
the |srules| template files, to avoid the need for conditional compilation
(and thus to enable the template to be assimilated just once); but we
continue to give them the traditional constant names, for the sake of any
third-party extensions using these.

View file

@ -73,7 +73,7 @@ as a direction name plus "of", since "below" is not the name of the direction
... from
@ Two of the directions are special to mapping, because they have to be parsed
slighly differently. (These are the English names; there is no need to translate
slightly differently. (These are the English names; there is no need to translate
this to other languages.)
=

View file

@ -17,7 +17,7 @@ represented by //explicit_action// objects.
(*) An "action name" -- not an ideal thing to call it, but traditional -- is the
type of action involved, taken in isolation: for example, "taking". These can
also be values at run-time, they have kind |K_action_name|, and they are
represented in the comoiler by //action_name// objections.
represented in the compiler by //action_name// objections.
(*) An "action pattern" is a textual description which matches some actions but
not others, and can be vague or specific: for example, "wearing or examining
something". Action patterns become values of the kind |K_description_of_action|.

View file

@ -2,7 +2,7 @@
An exactly specified action is called "explicit".
@ Explicit actions are used inside the compiler whenever we kmow exactly what
@ Explicit actions are used inside the compiler whenever we know exactly what
action we are talking about; stored action constants are //explicit_action//
objects in a thin wrapper -- see //Action Kinds//.

View file

@ -205,7 +205,7 @@ to typecheck each clause.
LOG_OUTDENT;
}
@ This is where heterogenous patterns like "dropping a thing or taking a
@ This is where heterogeneous patterns like "dropping a thing or taking a
container" are thrown out: only the last-placed action is allowed to have
clauses.

View file

@ -625,7 +625,7 @@ some can never happen. For example,
ask [someone] about [something]
ask [someone] about [text]
=
have to be that way around, because any comnand which matches the first line
have to be that way around, because any command which matches the first line
here also matches the second. Putting these lines into order used to be part
of the craft of the Inform 6 programmer, but it was always difficult to do,
and Inform 7 aimed to liberate authors from the need to do this. A long
@ -651,7 +651,7 @@ int CGLines::cg_line_must_precede(command_grammar *cg, cg_line *L1, cg_line *L2)
@<Higher sort bonuses precede lower ones@>;
@<More specific determinations precede less specific ones@>;
@<Conditional readings precede unconditional readings@>;
@<Lines created earlier precede lines creater later in the source text@>;
@<Lines created earlier precede lines created later in the source text@>;
}
@<Perform some sanity checks@> =
@ -686,7 +686,7 @@ working through a |CG_IS_COMMAND| grammar -- it always knows how many words
it has to match. If the player has typed TAKE FROG FROM AQUARIUM, the parser
has to make sense of all of the words. It needs to consider the possibility
"take [something]" before "take [something] from [something]" because there
might be an object called "frog fram aquarium".
might be an object called "frog from aquarium".
On the other hand, if it is parsing a |CG_IS_TOKEN| grammar, it is trying to
match as many words as possible from a stream of words that will probably then
@ -771,6 +771,6 @@ an object has a name like ON VISION ON -- perhaps a book about the antique
BBC children's television programme "Vision On" -- so that the command
TURN ON VISION ON would match both of the alternative CGLs.
@<Lines created earlier precede lines creater later in the source text@> =
@<Lines created earlier precede lines created later in the source text@> =
if (L1->allocation_id < L2->allocation_id) return TRUE;
return FALSE;

View file

@ -209,7 +209,7 @@ parse_node *CompileValues::cast_nonconstant(parse_node *value, kind *K_wanted,
return value;
}
@ Certain kinds of value cannot be used on every virtual machine; for examole,
@ Certain kinds of value cannot be used on every virtual machine; for example,
the Z-machine does not support real numbers.
=

View file

@ -344,7 +344,7 @@ in the range |ACTOR_IS_PLAYER_CPMC <= N <= ACTOR_MATCHES_CPMC|, and so on.
@ This is the easier case: all four ranges of condition must be true, and so
we compile code equivalent to |ACTION and ACTOR and DETAILS and WHEN|. We
do it in that order for two reasons: firstly, wrong actions are the commonest
reasom actions fail to match, and the ACTION tests are quick, so it's efficient
reason actions fail to match, and the ACTION tests are quick, so it's efficient
to test that first. (The ACTOR tests are also quick, but usually pass.) Secondly,
some DETAILS tests will compile non-typesafe code in cases where ACTION would
not pass, so DETAILS must be compiled after ACTION. Finally, we put WHEN at
@ -395,7 +395,7 @@ we still have to compile |true|, to ensure that every action will match.
@ A listwise negated pattern is something like "doing something other than
examining the box", which matches any action except "examining the box". It
might seem that this could be negated just as the negation of the positive
case, but that overlookz the hidden clauses about who the actor is, whether
case, but that overlooks the hidden clauses about who the actor is, whether
the action is a request, and so on -- the |ACTOR_CPMCRANGE| -- and any
condition supplied -- the |WHEN_CPMCRANGE|.

View file

@ -53,7 +53,7 @@ ordinarily a direction.)
@ The not-nowhere test is needed for patterns like "going from the Dining Room",
which we want to match only where there is some destination: i.e., we don't want
it to match an attemot to go in a direction not available in the map.
it to match an attempt to go in a direction not available in the map.
@<Compile NOT_NOWHERE_CPMC test@> =
EmitCode::inv(NE_BIP);

View file

@ -4,7 +4,7 @@ To compile Inter functions.
@ The code in this section is used throughout the //imperative// and //runtime//
modules whenever an Inter function needs to be compiled. This will often not be
a function corresponding to a definition in the soruce text; more often, it will
a function corresponding to a definition in the source text; more often, it will
be a support function needed to implement some feature at runtime.
However it happens, every function is compiled using code like so:

View file

@ -19,7 +19,7 @@ about the function currently being compiled. In particular:
(*) what kind of value we should be returning, if anything.
@ Code can only be compiled "inside" a stack frame, and at any given time
(when code is being comoiled, anyway) there is a "current" frame.
(when code is being compiled, anyway) there is a "current" frame.
=
stack_frame *current_frame = NULL;

View file

@ -7,7 +7,7 @@ As this section of code opens, we are looking at the parse tree for the body
of a rule or phrase definition. A request has been made to compile (a version of)
this into an Inter function; the stack frame for that has been sorted out, and
the function begun. Now we must compile the actual code to go into the function;
the test grpup |:invocations| exercises all of this.
the test group |:invocations| exercises all of this.
Here is a typical example rule, taken from the Standard Rules:
= (text as Inform 7)
@ -21,7 +21,7 @@ Report an actor waiting (this is the standard report waiting rule):
=
In the parse tree, this now looks like so:
= (text)
IMPERATIVE_NT'report an actor waiting ( this is the standard report waitin'
IMPERATIVE_NT'report an actor waiting ( this is the standard report waiting'
CODE_BLOCK_NT
CODE_BLOCK_NT
INVOCATION_LIST_NT'if the actor is the player'
@ -825,7 +825,7 @@ void CompileBlocksAndLines::verify_say_node_list(parse_node *say_node_list) {
StandardProblems::sentence_problem(Task::syntax_tree(),
_p_(PM_SayOverComplex),
"this is too complex a text substitution",
"and needs to be simplified. You might find it helful to define a new text "
"and needs to be simplified. You might find it hel[ful to define a new text "
"substitution of your own ('To say fiddly details: ...') and then use it "
"in this text by including the '[fiddly details]'.");
problem_issued = TRUE;

View file

@ -39,7 +39,7 @@ front material before compiling the block, and the back material afterwards.
@ The process of compiling from an inline definition is a little like
interpreting a program, and a //csi_state// object represents the state of
tbe (imaginary) computer doing that.
the (imaginary) computer doing that.
=
typedef struct csi_state {
@ -160,7 +160,7 @@ unless a code block is opened: if it is, then they're deallocated when it ends.
if (CSIS.my_vars[i])
LocalVariableSlates::deallocate_I7_local(CSIS.my_vars[i]);
@ And tbis is what happens when the back part of the definition is finally
@ And this is what happens when the back part of the definition is finally
compiled.
=
@ -179,7 +179,7 @@ the schema, and calls //CSIInline::from_source_text// on any material enclosed
in |(+ ... +)| notation.
|CSIS| is passed to this function as our "opaque state" -- meaning that it is
passed through unchanged to our callbach functions, and means that the code
passed through unchanged to our callback functions, and means that the code
below can share some private state variables.
=

View file

@ -7,7 +7,7 @@ attached.
Either-or properties may need rather different run-time implementation from
properties with values, but otherwise they might seem nothing special: why
not simply regard them as properties holding truth state values? And then
there would just be obe type of property.
there would just be one type of property.
The answer is that whereas a computer-science view of the "open" property,
say, would take exactly this line -- i.e., that it simply holds a truth

View file

@ -94,7 +94,7 @@ void KindSubjects::renew(kind *K, kind *super, wording W) {
@ Even base kinds which do have subjects do not necessarily allow properties
to be given to their values -- "number", for instance, where you cannot give
a property to the nunber 6.
a property to the number 6.
In general a value can have properties if and only if its kind passes this test:

View file

@ -40,7 +40,7 @@ are equivalent here: permission for one is always permission for the other.
If these were long lists, or searched often, it would be faster to move each
found permission to the front, thus tending to move frequently-sought properties
to the start. Pofiling shows that this would save no significant time,
to the start. Profiling shows that this would save no significant time,
whereas the unpredictable order might make testing Inform more annoying.
@d LOOP_OVER_PERMISSIONS_FOR_PROPERTY(pp, prn)

View file

@ -286,7 +286,7 @@ source text description, so that "Mr Beebe" will not be flattened to "mr
beebe"; but that we take care to reduce the case of "Your nose" (etc.)
to "your nose", unless it occurs in the name of a room, like "Your Bedroom".
If the "spatial" plugin is inactive, |this_is_a_room| is akways |FALSE|.
If the "spatial" plugin is inactive, |this_is_a_room| is always |FALSE|.
@<Compose the I6 short-name as a piece of text@> =
Naming::compose_words_to_I6_naming_text(textual_value, W, FALSE,

View file

@ -10,7 +10,7 @@ which use this module:
@ Like all modules, this one must define a |start| and |end| function.
Note that the "multimedia" plugin itself does nothihg except to be a parent
Note that the "multimedia" plugin itself does nothing except to be a parent
to the other three; it doesn't even have an activation function.
@e MULTIMEDIA_CREATIONS_DA

View file

@ -166,7 +166,7 @@ int EmitCode::cast_possible(kind *F, kind *T) {
}
@ Casts are in many cases implicit, so that nothing need be done, and the
followimg simply returns |TRUE| to indicate success. But in a few cases, a
following simply returns |TRUE| to indicate success. But in a few cases, a
function call must be inserted, with a name like |SNIPPET_TY_to_TEXT_TY|;
in such cases, this function must exist in the kits somewhere.

View file

@ -1,6 +1,6 @@
[EqualitySchemas::] Equality Schemas.
To define how to compile a comparisom of two values.
To define how to compile a comparison of two values.
@ For most word-value kinds, it's easy to compare two values to see if they are
equal: all we need is the |==| operator. But for pointer-value kinds, that

View file

@ -1,6 +1,6 @@
[RTSpatial::] Here, Nowhere and Everywhere.
Almost a Beatles song, but really a set of schemas for compilimg the meaning
Almost a Beatles song, but really a set of schemas for compiling the meaning
of the unary predicates here, nowhere and everywhere.
@ Here. In fact, at present "here" predicates are never included in propositions to

View file

@ -80,7 +80,7 @@ inter_name *RTActions::base_iname(action_name *an) {
@ We actually want the other names to still be related to the base name even
after a translation; i.e., if an action is translated to |Grab|, then we want
to have the related names be |##Grab| and |GrabSub|. So translation needs to
happen early-ish in the run, befpre tbe base iname is generated.
happen early-ish in the run, before the base iname is generated.
=
void RTActions::translate(action_name *an, wording W) {

View file

@ -424,7 +424,7 @@ void RTAdjectives::make_adjective_phrase_package(id_body *idb) {
@h Compiling tasks for adjectives defined by I7 or Inter code.
First, an adjective defined by a condition written in raw Inter code can be
tested (but not asserted) using a schema, since those are also raw Inter coce.
tested (but not asserted) using a schema, since those are also raw Inter code.
All we do is remove the enrobing quotation marks around the condition.
=

View file

@ -58,7 +58,7 @@ package_request *RTVerbs::modal_package(parse_node *where) {
return Hierarchy::local_package_to(MVERBS_HAP, where);
}
@h Compilation data for conjgations.
@h Compilation data for conjugations.
Each |verb_conjugation| object contains this data:
@d VC_COMPILATION_LINGUISTICS_CALLBACK RTVerbs::initialise_vc

View file

@ -123,7 +123,7 @@ inter_name *RTRules::shell_iname(rule *R) {
}
@ Note that the response handler function must be made available to the linker,
because the idea is that the kit function will use it. For examole, the code
because the idea is that the kit function will use it. For example, the code
in the kit might read like so:
= (text as Inform 6)
[ MY_FOREIGN_R;