Creating, activating or deactivating compiler features.
+
+
§1. "Features" are optional pieces of compiler functionality, which are given
+textual names. They can be "activated" or "deactivated", that is, on or off.
+For example, some of the interactive-fiction support in the Inform compiler
+is provided by features which are deactivated for Basic Inform projects.
+Incompletely implemented, or experimental, functions under development can
+also be gated behind features which are deactivated by default, and activated
+just for test projects.
+
+
+
It turns out to be convenient to have a hard-wired maximum number of these.
+But since features are not things an author can create in source text, we always
+know exactly how many there are.
+
§3. The idea is that an inactive feature does nothing; it's as if that section of
+code were not in the compiler at all. These provide convenient shorthand ways
+to test that:
+
§4. In the code above, features are set up as inactive by default — even "core",
+which the compiler absolutely cannot live without. So Project Services (in supervisor)
+calls the following before switching on optional things that it wants.
+
§5. Most features are subordinate to a parent feature: for example, a dozen more
+specific IF-related features are subordinate to the "interactive fiction" one.
+
§8. Every active feature gets to run its start function, if it provides one.
+But this is postponed until Features::run_activation_functions is called;
+at that point, every activated feature runs its function. If any feature is
+activated after this point, its function runs immediately. (The point of the
+postponement is that very early in Inform's run, the memory manager may not
+yet be working, and so on.)
+
+
+
It's kind of incredible that C's grammar for round brackets is unambiguous.
+
§1. Prerequisites. The arch module is a part of the Inform compiler toolset. It is
presented as a literate program or "web". Before diving in:
@@ -148,8 +148,14 @@ anything". This should be the default; §5. Features. The last service provided by this module is to manage which named features of
+the compiler are switched on or off: see Feature Manager. At one time
+this functionality was part of the core Inform compiler, but having it here
+means that all of the compiler tools can make use of it.
+
-
+ Creating, activating or deactivating compiler features.
+
+
+
diff --git a/docs/assertions-module/3-nvr.html b/docs/assertions-module/3-nvr.html
index af61f4f65..e6f59bb81 100644
--- a/docs/assertions-module/3-nvr.html
+++ b/docs/assertions-module/3-nvr.html
@@ -360,7 +360,7 @@ now absolutely any non-empty word range is accepted as the property name.
§5.3. So we can now use the above grammar to understand the definition of the verb.
Note that it is legal, but does nothing, to request a built-in meaning which
does not exist: this allows for Basic Inform to mention built-in meanings
-which exist only when certain plugins are active.
+which exist only when certain features are active.
Find the verb meaning and priority5.3 =
diff --git a/docs/assertions-module/4-ass.html b/docs/assertions-module/4-ass.html
index f91fe6011..211a2b6cc 100644
--- a/docs/assertions-module/4-ass.html
+++ b/docs/assertions-module/4-ass.html
@@ -889,7 +889,7 @@ further sub-cases later.
§6.3.17. Case 17. In fact one sentence like this can make sense — "The mist is
-everywhere", or similar — but is handled by the spatial plugin, if active.
+everywhere", or similar — but is handled by the spatial feature, if active.
Even then, of course, "everywhere" implicitly means "in every room",
not "every room".
@@ -2057,7 +2057,7 @@ these sentences falls into case 41.
East is the Pavilion.
-
(Of course this will only be true if the map plugin is active.)
+
(Of course this will only be true if the map feature is active.)
Case 41 - PROPER NOUN on both sides6.3.41 =
diff --git a/docs/assertions-module/4-rpt.html b/docs/assertions-module/4-rpt.html
index a89a4b969..e61a0302f 100644
--- a/docs/assertions-module/4-rpt.html
+++ b/docs/assertions-module/4-rpt.html
@@ -115,7 +115,7 @@ the details of a description to the node.
§3. It's useful to have a safe way of transferring the complete noun details
from one node to another, without breaking the above invariant. (The
-nowhere annotation is used by the spatial model plugin, if active, and
+nowhere annotation is used by the spatial feature, if active, and
it probably never needs to be copied, but we do so for safety's sake.)
@@ -634,7 +634,7 @@ complicated description is as follows:
elseNode::set_subject(p, NULL);
§11.8.1. For example, "above" and "below" become significant if the mapping plugin
+
§11.8.1. For example, "above" and "below" become significant if the mapping feature
is active, and "nowhere" if the spatial one is.
diff --git a/docs/assertions-module/5-rcd.html b/docs/assertions-module/5-rcd.html
index c713e91ea..21a26f115 100644
--- a/docs/assertions-module/5-rcd.html
+++ b/docs/assertions-module/5-rcd.html
@@ -94,7 +94,7 @@ about the location applies. Those two restrictions are both stored in its RCD.
structwordingactivity_context; text used to parse...structactivity_list *avl; happens only while these activities go onstructaction_pattern *ap; happens only if the action or parameter matches this
-void *plugin_rcd[MAX_PLUGINS]; storage for plugins to attach, if they want to
+void *feature_rcd[MAX_COMPILER_FEATURES]; storage for features to attach, if they want to} id_runtime_context_data;id_runtime_context_dataRuntimeContextData::new(void) {
@@ -102,7 +102,7 @@ about the location applies. Those two restrictions are both stored in its RCD.
phrcd.activity_context = EMPTY_WORDING;phrcd.avl = NULL;phrcd.ap = NULL;
-for (inti=0; i<MAX_PLUGINS; i++) phrcd.plugin_rcd[i] = NULL;
+for (inti=0; i<MAX_COMPILER_FEATURES; i++) phrcd.feature_rcd[i] = NULL;PluginCalls::new_rcd_notify(&phrcd);returnphrcd;}
@@ -114,13 +114,13 @@ about the location applies. Those two restrictions are both stored in its RCD.
The structure id_runtime_context_data is accessed in 5/rf and here.
§2. For the more interesting clauses, see Scenes (in if) and Rules Predicated on Actions (in if),
-where the scenes and actions plugins make use of the following extensibility:
+where the scenes and actions features make use of the following extensibility:
§3. Specificity. The following is one of Inform's standardised comparison routines, which
takes a pair of objects A, B and returns 1 if A makes a more specific
diff --git a/docs/assertions-module/5-rf.html b/docs/assertions-module/5-rf.html
index 7b216aaf9..1b5b5da6e 100644
--- a/docs/assertions-module/5-rf.html
+++ b/docs/assertions-module/5-rf.html
@@ -122,7 +122,7 @@ this is divided up into smaller excerpts of text, as in the following examples:
intowning_rulebook_placement; ...and with this placement value: see Rulebooksintpermit_all_outcomes; waive the usual restrictions on rule outcomes
-void *plugin_rfd[MAX_PLUGINS]; storage for plugins to attach, if they want to
+void *feature_rfd[MAX_COMPILER_FEATURES]; storage for features to attach, if they want toCLASS_DEFINITION} rule_family_data;
@@ -140,18 +140,18 @@ this is divided up into smaller excerpts of text, as in the following examples:
rfd->owning_rulebook = NULL;rfd->owning_rulebook_placement = MIDDLE_PLACEMENT;rfd->permit_all_outcomes = FALSE;
-for (inti=0; i<MAX_PLUGINS; i++) rfd->plugin_rfd[i] = NULL;
+for (inti=0; i<MAX_COMPILER_FEATURES; i++) rfd->feature_rfd[i] = NULL;returnrfd;}
The structure rule_family_data is accessed in 5/tpf and here.
-
§3. These two macros provide access to plugin-specific rule family data:
+
§3. These two macros provide access to feature-specific rule family data:
§4. Identification. We are going to claim as our own any definition whose name matches the
following nonterminal — and because of the last production, this will always
diff --git a/docs/assertions-module/6-rls.html b/docs/assertions-module/6-rls.html
index 617738fdf..0d1f0cc2b 100644
--- a/docs/assertions-module/6-rls.html
+++ b/docs/assertions-module/6-rls.html
@@ -290,7 +290,7 @@ nothing.
kind *Rules::to_kind(rule *R) {kind *K = R->kind_of_rule;if (K == NULL) {
-if (PluginManager::active(actions_plugin))
+if (FEATURE_ACTIVE(actions))K = Kinds::binary_con(CON_rule, K_action_name, K_void);elseK = Kinds::binary_con(CON_rule, K_void, K_void);
diff --git a/docs/core-module/1-cm.html b/docs/core-module/1-cm.html
index 37dea9958..a94e38905 100644
--- a/docs/core-module/1-cm.html
+++ b/docs/core-module/1-cm.html
@@ -67,22 +67,29 @@ function togglePopup(material_id) {
§2. Like all modules, this one must define a start and end function.
-
Note that the "core" plugin itself does nothing except to be a parent to the
+
Note that the "core" feature itself does nothing except to be a parent to the
other two; it doesn't even have an activation function.
+
The "experimental features" feature is similarly an umbrella for any features
+being used to test out half-implemented compiler functionality before it's ready
+to be part of a released version.
+
diff --git a/docs/core-module/1-cp.html b/docs/core-module/1-cp.html
index ebb2dc9a0..fb405ce16 100644
--- a/docs/core-module/1-cp.html
+++ b/docs/core-module/1-cp.html
@@ -249,7 +249,6 @@ We begin with core itself.
enumlabel_namespace_CLASSenumgroup_together_function_CLASSenumnascent_array_CLASS
-enumplugin_CLASSenumruntime_kind_structure_CLASSenumslash_gpr_CLASSenumtest_scenario_CLASS
@@ -269,7 +268,6 @@ We begin with core itself.
DECLARE_CLASS(label_namespace)DECLARE_CLASS(group_together_function)DECLARE_CLASS(nascent_array)
-DECLARE_CLASS(plugin)DECLARE_CLASS(runtime_kind_structure)DECLARE_CLASS(slash_gpr)DECLARE_CLASS(test_scenario)
@@ -371,7 +369,7 @@ We begin with core itself.
DECLARE_CLASS(files_data)
diff --git a/docs/core-module/1-cp2.html b/docs/core-module/1-cp2.html
index 30fe36f71..4b7a1a876 100644
--- a/docs/core-module/1-cp2.html
+++ b/docs/core-module/1-cp2.html
@@ -165,7 +165,7 @@ bit or the <k-kind> bit set, which as we see above is }
diff --git a/docs/core-module/1-cs.html b/docs/core-module/1-cs.html
index 35471f8f3..fb8d72a2c 100644
--- a/docs/core-module/1-cs.html
+++ b/docs/core-module/1-cs.html
@@ -231,7 +231,7 @@ the above settings can be changed.)
}
diff --git a/docs/core-module/1-htc.html b/docs/core-module/1-htc.html
index c983da8ea..49e479ad0 100644
--- a/docs/core-module/1-htc.html
+++ b/docs/core-module/1-htc.html
@@ -164,8 +164,8 @@ as possible.
§2.2. Here, then, are the steps in the production line, presented without
commentary. For what they do, see the relevant sections. Note that at the
-end of each stage, plugins are allowed to add further steps; see
-Task::advance_stage_to.
+end of each stage, plugins made by compiler features are allowed to add
+further steps; see Task::advance_stage_to.
Before anything else can be done, we must create an empty Inter hierarchy
@@ -655,7 +655,7 @@ to advance last_task}
diff --git a/docs/core-module/1-inaa.html b/docs/core-module/1-inaa.html
index 916a93f69..aca98dc2e 100644
--- a/docs/core-module/1-inaa.html
+++ b/docs/core-module/1-inaa.html
@@ -487,7 +487,7 @@ which compilation unit the node belongs.
enumlpe_options_ANNOTint: options set for a literal pattern partenummultiplicity_ANNOTint: e.g., 5 for "five gold rings"enumnew_relation_here_ANNOTbinary_predicate: new relation as subject of "relates" sentence
-enumnowhere_ANNOTint: used by the spatial plugin to show this represents "nowhere"
+enumnowhere_ANNOTint: used by the spatial feature to show this represents "nowhere"enumpredicate_ANNOTunary_predicate: which adjective is assertedenumquant_ANNOTquantifier: for quantified excerpts like "three baskets"enumquantification_parameter_ANNOTint: e.g., 3 for "three baskets"
@@ -1340,7 +1340,7 @@ which compilation unit the node belongs.
}
diff --git a/docs/core-module/1-itc.html b/docs/core-module/1-itc.html
index 3827edce2..20e12a9bd 100644
--- a/docs/core-module/1-itc.html
+++ b/docs/core-module/1-itc.html
@@ -470,7 +470,7 @@ and carry on regardless.
§1. The following set of functions is an API for the main compiler to consult
-with the plugins; put another way, it is also an API for the plugins to
-influence the main compiler. They do so by adding plugs to the relevant rulebooks:
-see PluginManager::plug.
+
§1. The three Inform compiler tools inform7, inbuild and inter
+share a set of named compiler features, managed by Feature Manager (in arch).
+At any given time these can be active or inactive.
-
Nothing can prevent this from being a big old miscellany, so we take them by
+
In inform7, features gain further abilities: they can attach storage to
+certain internal data structures, and they can provide plugin functions which
+interfere with the normal running of the compiler.
+
+
+
The names of these features are hard-wired into the compiler rather than being
+stored in Preform grammar, and they therefore cannot be translated out of
+English. But this is intentional. Dependencies on compiler features are managed
+by name inside the supervisor module, and metadata for projects and kits
+refers to those names. So they have to be the same regardless of the language
+being used in the project. But it hardly matters, because these names are
+invisible to all but the most expert users.
+
+
+
However, because it is possible to have headings in Inform source text which
+restrict material according to whether a feature is active, we do need a
+Preform nonterminal to parse those names. Here it is:
+
§2. As noted above, features can provide plugin functions, which go into what
+we will call "plugin rulebooks" — there's a mixed metaphor here, but the idea
+is that they behave like Inform rulebooks. When a rulebook is called, the
+compiler works through each plug until one of them returns something other
+than FALSE.
+
+
+
Features should add plugins in their activation functions, by calling
+PluginCalls::plug, which has an interestingly vague type. The next
+screenful of code looks like something of a workout for the C typechecker, but
+it compiles under clang without even the -Wpedantic warning, and honestly
+you're barely living as a C programmer if you never generate that one.
+
§3. The functions in Plugin Calls then make use of these macros, which are
+the easiest way to persuade the C typechecker to allow variable arguments to
+be passed in a portable way. Similarly, there are two macros not one because
+C does not allow a void variable argument list.
+
+
+
We must take care that the variables introduced in the macro body do not mask
+existing variables used in the arguments; the only way to do this is to give
+them implausible names.
+
+
+
definePLUGINS_CALL(code, args...) {
+void *R_plugin_pointer_XYZZY; no argument can have this name
+LOOP_OVER_LINKED_LIST(R_plugin_pointer_XYZZY, void, plugin_rulebooks[code]) {
+int (*R_plugin_rule_ZOOGE)() = (int (*)()) R_plugin_pointer_XYZZY; or this one
+intQ_plugin_return_PLUGH = (*R_plugin_rule_ZOOGE)(args); or this
+if (Q_plugin_return_PLUGH) returnQ_plugin_return_PLUGH;
+ }
+returnFALSE;
+}
+definePLUGINS_CALLV(code) {
+void *R_plugin_pointer_XYZZY;
+LOOP_OVER_LINKED_LIST(R_plugin_pointer_XYZZY, void, plugin_rulebooks[code]) {
+int (*R_plugin_rule_ZOOGE)() = (int (*)()) R_plugin_pointer_XYZZY;
+intQ_plugin_return_PLUGH = (*R_plugin_rule_ZOOGE)();
+if (Q_plugin_return_PLUGH) returnQ_plugin_return_PLUGH;
+ }
+returnFALSE;
+}
+
+
§4. Nothing can prevent this from being a big old miscellany, so we take them by
compiler module, and within each module in alphabetical order.
-
§2. Influencing core. Called from Task::advance_stage_to. This allows plugins to run additional
+
§5. Influencing core. Called from Task::advance_stage_to. This allows features to run additional
production-line steps in compilation, and that is done mostly at the Inter
-generation stage, to add extra arrays or functions needed at run-time to
-support whatever feature the plugin implements. For example, the mapping plugin
-compiles an array to hold the map during stage INTER1_CSEQ.
+generation stage, to add extra arrays or functions needed at runtime.
+For example, the mapping feature compiles an array to hold the map during
+stage INTER1_CSEQ.
Because the following is called at the end of every main stage of compilation
except for FINISHED_CSEQ, it is called about 15 times in all, so it is
essential to check stage and act only on the right occasion. debugging is
-TRUE if this is a debugging run, and allows a plugin to generate diagnostic
-features if so.
+TRUE if this is a debugging run.
§6. Influencing assertions. Called from Refine Parse Tree (in assertions) to ask if this node is a noun
phrase with special significance: for example, "below" is significant to the
-mapping plugin. If so, the plugin should set the subject of the node to say
+mapping feature. If so, the plugin should set the subject of the node to say
what it refers to, and return TRUE.
@@ -113,8 +207,8 @@ what it refers to, and return PLUGINS_CALL(ACT_ON_SPECIAL_NPS_PLUG, p);}
-
§4. Called from Assemblies (in assertions). Body-snatching is used only by the
-"player" plugin, and is explained there; it handles the consequences of sentences
+
§7. Called from Assemblies (in assertions). Body-snatching is used only by the
+"player" feature, and is explained there; it handles the consequences of sentences
like "The player is Lord Collingwood".
@@ -126,7 +220,7 @@ like "The player is Lord Collingwood".
PLUGINS_CALL(DETECT_BODYSNATCHING_PLUG, body, snatcher, counterpart);}
-
§8. Called from Assertions (in assertions) to see if any plugin wants to
intepret a sentence its own way, either taking direct action or issuing a
more nuanced problem message than the usual machinery would have issued.
If so, the plugin should return TRUE, which both ensures that no other
@@ -141,8 +235,8 @@ with the sentence.
PLUGINS_CALL(INTERVENE_IN_ASSERTION_PLUG, px, py);}
-
§6. Called from The Creator (in assertions) when a copular sentence may be
-creating something. For example, the actions plugin needs this.
+
§9. Called from The Creator (in assertions) when a copular sentence may be
+creating something. For example, the actions feature needs this.
enumCREATION_PLUG
@@ -152,8 +246,8 @@ creating something. For example, the actions plugin needs this.
PLUGINS_CALL(CREATION_PLUG, px, py);}
-
§7. Called from Assertions (in assertions) when an unfamiliar node type appears
-where a property value might be expected. For example, the actions plugin
+
§10. Called from Assertions (in assertions) when an unfamiliar node type appears
+where a property value might be expected. For example, the actions feature
uses this to deal with setting a property to an ACTION_NT node. To
intervene, set the node specification using Refine Parse Tree (in assertions)
and return TRUE; or return FALSE to let nature take its course.
@@ -166,10 +260,10 @@ and return TRUEPLUGINS_CALL(UNUSUAL_PROPERTY_VALUE_PLUG, py);}
-
§11. Called from The Creator (in assertions) when an instance is being made in
an assembly, and its name may involve a genitive. For example, if the
assembly says "every person has a nose", then normally this would be called
-something like "Mr Rogers's nose"; but the player plugin uses the following
+something like "Mr Rogers's nose"; but the player feature uses the following
to have "your nose" in the case of the player instance.
@@ -181,9 +275,9 @@ to have "your nose" in the case of the player instance.
PLUGINS_CALL(IRREGULAR_GENITIVE_IN_ASSEMBLY_PLUG, owner, genitive, propriety);}
-
§12. Called from Booting Verbs (in assertions) to give each plugin a chance to
create any special sentence meanings it would like to. For example, the
-sounds plugin defines a special form of assertion sentence this way. The
+sounds feature defines a special form of assertion sentence this way. The
plugin should always return FALSE, since otherwise it may gazump other
plugins and cause them to stop working.
@@ -195,11 +289,11 @@ plugins and cause them to stop working.
PLUGINS_CALLV(MAKE_SPECIAL_MEANINGS_PLUG);}
-
§13. Called from Assertions (in assertions) when it seems that the author wants
to create a property of something with a sentence like "A container has a
number called security rating." A plugin can intervene and act on that,
returning TRUE to stop the usual machinery. For example, the actions
-plugin does this so that "The going action has a number called celerity"
+feature does this so that "The going action has a number called celerity"
can be intercepted to create an action variable, not a property.
@@ -210,7 +304,7 @@ can be intercepted to create an action variable, not a property.
PLUGINS_CALL(OFFERED_PROPERTY_PLUG, K, owner, what);}
-
§14. Called from Assertions (in assertions) when the specification pseudo-variable
is about to be set for something; the plugin can then intercept this.
@@ -221,9 +315,9 @@ is about to be set for something; the plugin can then intercept this.
PLUGINS_CALL(OFFERED_SPECIFICATION_PLUG, owner, W);}
-
§15. Called from Refine Parse Tree (in assertions) to ask plugins if a noun phrase
has a noun implicit within it, even though none is explicitly given. For
-example, the player plugin uses this to say that "initially carried" means
+example, the player feature uses this to say that "initially carried" means
"...by the player", and sets the subject of the node to be the player character
instance.
§13. Called from Classifying Sentences (in assertions) to give plugins the chance
-of an early look at a newly-read assertion. For example, the map plugin uses
+
§16. Called from Classifying Sentences (in assertions) to give plugins the chance
+of an early look at a newly-read assertion. For example, the map feature uses
this to spot that a sentence will create a new direction.
@@ -247,7 +341,7 @@ this to spot that a sentence will create a new direction.
PLUGINS_CALL(NEW_ASSERTION_NOTIFY_PLUG, p);}
-
§17. Called from The Equality Relation Revisited (in assertions) when we have
to decide if it's valid to ask or declare that two things are the same.
Returning TRUE says that it is always valid; returning FALSE leaves
it to the regular machinery. This plug can therefore only be used to permit
@@ -261,7 +355,7 @@ additional usages, not to restrict existing ones.
PLUGINS_CALL(TYPECHECK_EQUALITY_PLUG, K1, K2);}
-
@@ -294,9 +388,9 @@ a new set of runtime context data is being made.
PLUGINS_CALL(NEW_RCD_NOTIFY_PLUG, rcd);}
-
§18. Influencing values. Called from Rvalues (in values) to allow plugins to help decide whether values
+
§21. Influencing values. Called from Rvalues (in values) to allow plugins to help decide whether values
of the same kind would be equal if evaluated at runtime. For example, the
-"scenes" plugin uses this to determine if two K_scene constants are equal.
+scenes feature uses this to determine if two K_scene constants are equal.
To make a decision, set rv to either TRUE or FALSE and return TRUE.
To make no decision, return FALSE.
@@ -308,7 +402,7 @@ To make no decision, return F
PLUGINS_CALL(COMPARE_CONSTANT_PLUG, c1, c2, rv);}
-
§19. Called from Rvalues (in values) to allow plugins to compile rvalues in
+
§22. Called from Rvalues (in values) to allow plugins to compile rvalues in
eccentric ways of their own: not in fact just for the whimsy of it, but to
make it possible for plugins to support base kinds of their own. For example,
the "actions" plugin needs this to deal with the "stored action" kind.
@@ -321,7 +415,7 @@ the "actions" plugin needs this to deal with the "stored action" kind.
PLUGINS_CALL(COMPILE_CONSTANT_PLUG, VH, K, spec);}
-
§23. Called from Conditions (in values) to allow plugins to compile conditions in
their own way. For example, the "actions" plugin needs this to compile matches
of the current action against an action pattern.
@@ -333,9 +427,9 @@ of the current action against an action pattern.
PLUGINS_CALL(COMPILE_CONDITION_PLUG, VH, spec);}
-
§24. Called from Specifications (in values) to ask if there is some reason why
a rule about I1 should be thought broader in scope than one about I2. This
-is used by the regions plugin when one is a sub-region of the other. This is
+is used by the regions feature when one is a sub-region of the other. This is
expected to behave as a strcmp-like sorting function, with a positive
return value saying I1 is broader, negative I2, or zero that they are equal.
§25. Called from Constants and Descriptions (in values) to give plugins a chance
to parse text which might otherwise be meaningless (or mean something different)
and make it a "composite noun-quantifier" such as "everywhere" or "nothing".
The main compiler does not recognise "everywhere" because it has no concept
-of space, but the spatial plugin does, and this is how.
+of space, but the spatial feature does, and this is how.
enumPARSE_COMPOSITE_NQS_PLUG
@@ -362,7 +456,7 @@ of space, but the spatial plugin does, and this is how.
PLUGINS_CALL(PARSE_COMPOSITE_NQS_PLUG, W, DW, quantifier_used, some_kind);}
§26. Influencing knowledge. Called from The Model World (in knowledge) to invite the plugin to participate
in stages I to V of the completion process. This may involve using contextual
reasoning to draw further inferences.
@@ -374,7 +468,7 @@ reasoning to draw further inferences.
PLUGINS_CALL(COMPLETE_MODEL_PLUG, stage);}
-
§27. Called from Inference Subjects (in knowledge) to invite the plugin to
create any additional inference subjects it might want to reason about. In
practice, this tends to be used to create preliminary subjects to stand in
for significant kinds before those kinds are ready to be created.
@@ -387,7 +481,7 @@ for significant kinds before those kinds are ready to be created.
PLUGINS_CALLV(CREATE_INFERENCE_SUBJECTS_PLUG);}
-
§28. Called from Indefinite Appearance (in knowledge) to ask the plugins what
inferences, if any, to draw from a double-quoted text standing as an entire
sentence. The infs is the subject which was being talked about at the time
the text was quoted, and therefore presumably is what the text should describe.
@@ -400,10 +494,10 @@ the text was quoted, and therefore presumably is what the text should describe.
PLUGINS_CALL(DEFAULT_APPEARANCE_PLUG, infs, txt);}
-
§29. Called from Inferences (in knowledge) when an inference is drawn about
something. This does not, of course, necessarily mean that this will actually
be the property of something: the inference might turn out to be mistaken. The
-mapping plugin uses this to infer further that if something is said to be a
+mapping feature uses this to infer further that if something is said to be a
map connection to somewhere else, then it is probably a room.
@@ -414,7 +508,7 @@ map connection to somewhere else, then it is probably a room.
PLUGINS_CALL(INFERENCE_DRAWN_NOTIFY_PLUG, I, subj);}
-
§30. Called from Kind Subjects (in knowledge). Early in the run, before some kinds
are created, placeholder inference subjects are created to stand in for them;
this call enables plugins to recognise certain texts as referring to those.
@@ -426,9 +520,9 @@ this call enables plugins to recognise certain texts as referring to those.
PLUGINS_CALL(NAME_TO_EARLY_INFS_PLUG, W, infs);}
-
§31. Called from Kind Subjects (in knowledge) to warn plugins about a new kind,
which in practice enables them to spot from the name that it is actually a kind
-they want to provide built-in support for: thus the actions plugin reacts to
+they want to provide built-in support for: thus the actions feature reacts to
the name "stored action", for example. K is the newcomer, super its super-kind,
if any; d and W are alternate forms of that name — d will be useful if the
kind was created by a kit (such as "number"), W if it came from Inform 7
@@ -442,8 +536,8 @@ source text (such as "container").
PLUGINS_CALL(NEW_BASE_KIND_NOTIFY_PLUG, K, d, W);}
-
§29. Called from Instances (in knowledge) to warn plugins that a new instance has
-been created. For example, the figures plugin needs to know this so that it
+
§32. Called from Instances (in knowledge) to warn plugins that a new instance has
+been created. For example, the figures feature needs to know this so that it
can see when a new illustration has been created.
@@ -459,8 +553,8 @@ sure you're not dealing with an object.
PLUGINS_CALL(NEW_INSTANCE_NOTIFY_PLUG, nc);}
-
§30. Called from Property Permissions (in knowledge) to warn plugins that a subject
-has been given permission to hold a property; the parsing plugin, for example,
+
§33. Called from Property Permissions (in knowledge) to warn plugins that a subject
+has been given permission to hold a property; the parsing feature, for example,
uses this to attach a visibility flag.
@@ -471,7 +565,7 @@ uses this to attach a visibility flag.
PLUGINS_CALL(NEW_PERMISSION_NOTIFY_PLUG, pp);}
-
§34. Called from Properties (in knowledge) to warn plugins that a property has
been created, which they can use to spot properties with special significance
to them.
@@ -483,7 +577,7 @@ to them.
PLUGINS_CALL(NEW_PROPERTY_NOTIFY_PLUG, prn);}
-
§35. Called from Inference Subjects (in knowledge) to warn plugins that a subject
has been created, which they can use to spot subjects with special significance
to them.
@@ -495,7 +589,7 @@ to them.
PLUGINS_CALL(NEW_SUBJECT_NOTIFY_PLUG, subj);}
-
§36. Called from Nonlocal Variables (in knowledge) to warn plugins that a new
variable has been created, which they can use to spot variables with special
significance to them.
@@ -507,7 +601,7 @@ significance to them.
PLUGINS_CALL(NEW_VARIABLE_NOTIFY_PLUG, q);}
-
§37. Called from Instances (in knowledge) to warn plugins that the kind of an
instance is about to be set. This happens most often when the instance is
created, but can also happen again, refining the kind to a subkind, when
the instance is an object.
@@ -520,7 +614,7 @@ the instance is an object.
PLUGINS_CALL(SET_KIND_NOTIFY_PLUG, I, k);}
-
§38. Called from Kind Subjects (in knowledge) when one kind of object is made a
subkind of another, as for example when "container" is a made a subkind of
"thing". The plugin should return TRUE if it wishes to forbid this,
and if so, it had better throw a problem message, or the user will be
@@ -538,8 +632,8 @@ regions plugin does with the "region" kind.
PLUGINS_CALL(SET_SUBKIND_NOTIFY_PLUG, sub, super);}
-
§36. Influencing the imperative plugin. Called from Rule Bookings (in assertions) to give plugins a chance to move
-automatically placed rules from one rulebook to another. The actions plugin
+
§39. Influencing the imperative module. Called from Rule Bookings (in assertions) to give plugins a chance to move
+automatically placed rules from one rulebook to another. The actions feature
uses this to break up what would otherwise be unwieldy before and after
rulebooks into smaller ones for each action.
@@ -596,12 +690,12 @@ This is currently only used by PLUGINS_CALL(INLINE_ANNOTATION_PLUG, annot, supplied);}
-
§41. Influencing the actions plugin. We now have a whole run of functions called only by the actions plugin, and
+
§44. Influencing the actions feature. We now have a whole run of functions called only by the actions feature, and
therefore only when it is active.
Called from Actions Plugin (in if) to signal that a new action has been
-created. For example, the going plugin uses this to spot the arrival of "going".
+created. For example, the going feature uses this to spot the arrival of "going".
enumNEW_ACTION_NOTIFY_PLUG
@@ -611,7 +705,7 @@ created. For example, the going plugin uses this to spot the arrival of "going".
PLUGINS_CALL(NEW_ACTION_NOTIFY_PLUG, an);}
§45. Called from Action Pattern Clauses (in if) to invite plugins to change the
action pattern clause ID associated with a given action variable. This may be
needed in order to cross-reference between multiple such clauses, as with
the going action variables.
@@ -625,7 +719,7 @@ the going action variables.
PLUGINS_CALL(DIVERT_AP_CLAUSE_PLUG, stv, id);}
-
§46. Called from Action Pattern Clauses (in if) to ask plugins to print a helpful
name for the debugging log for any new clause ID C which they have created.
@@ -636,7 +730,7 @@ name for the debugging log for any new clause ID PLUGINS_CALL(WRITE_AP_CLAUSE_ID_PLUG, OUT, C);}
-
§47. Called from Action Pattern Clauses (in if) to ask for the *_APCA aspect
for the clause ID C, where C is a new clause ID created by the plugin. If
this is not given, then the aspect will be MISC_APCA.
@@ -648,7 +742,7 @@ this is not given, then the aspect will be PLUGINS_CALL(ASPECT_OF_AP_CLAUSE_ID_PLUG, C, A);}
-
§48. Called from Action Pattern Clauses (in if) to give plugins a chance to
decide which AP is more specific, on the basis of the extra clauses defined
in the plugin.
@@ -672,7 +766,7 @@ to let the usual machinery take its course.
PLUGINS_CALL(COMPARE_AP_SPECIFICITY_PLUG, ap1, ap2, rv, ignore_in);}
-
§50. Called from Parse Clauses (in if) to give plugins a chance to intervene in
the normal process of evaluating the meaning of text in an action pattern
-clause: for example, in parsing "going nowhere", the going plugin uses this
+clause: for example, in parsing "going nowhere", the going feature uses this
to detect that the NOUN_AP_CLAUSE, with text "nowhere", should not be parsed
normally. What it does it to set a bit in the bitmap bits, which it will pick
up again and act upon when reacting to ACT_ON_ANL_ENTRY_OPTIONS_PLUG.
@@ -702,7 +796,7 @@ text of the clause in the normal way.
PLUGINS_CALL(PARSE_AP_CLAUSE_PLUG, an, c, bits);}
-
§51. Called from Parse Clauses (in if) to give plugins a chance to intervene in
the type-checking process for a clause. Ordinarily, this would just check that
the contents have the right kind: if matching an action variable of kind K
then it must be a value compatible with K or a description of such.
@@ -720,7 +814,7 @@ or FALSE (it is
PLUGINS_CALL(VALIDATE_AP_CLAUSE_PLUG, an, c, outcome);}
-
§53. Called from Matching Action Patterns (in imperative) when assembling the requirement
clauses for compiling a mattern match; this gives plugins a chance to act
extra stipulations, which are not explicit in clauses already in the pattern.
@@ -744,7 +838,7 @@ extra stipulations, which are not explicit in clauses already in the pattern.
PLUGINS_CALL(SET_PATTERN_MATCH_REQUIREMENTS_PLUG, ap, cpm, needed, needed_apoc);}
-
@@ -756,7 +850,7 @@ requirements set by SET_PATTE
}
diff --git a/docs/core-module/P-wtmd.html b/docs/core-module/P-wtmd.html
index 7b8a7bcf5..ba597149f 100644
--- a/docs/core-module/P-wtmd.html
+++ b/docs/core-module/P-wtmd.html
@@ -96,13 +96,11 @@ needed to make Inform's many concepts work at run-time.
There are then two expansion packs, as it were: the if and multimedia
modules, which do nothing essential but add support for interactive fiction
-and for sound and images respectively. These are implemented very largely
-as sets of Chapter 3: Plugins, an architecture which allows the basic Inform
-language to be made more domain-specific.
+and for sound and images respectively.
Plugin Calls -
- The interface between the main compiler and its plugins.
+ Giving compiler features the ability to install plugin functions.
diff --git a/docs/final-module/4-i6o.html b/docs/final-module/4-i6o.html
index ec54bd778..4cd83c44a 100644
--- a/docs/final-module/4-i6o.html
+++ b/docs/final-module/4-i6o.html
@@ -483,10 +483,10 @@ enumerated these colours as 1, 2, 3.
§9. For the I6 header syntax, see the DM4. Note that the "hardwired" short
name is intentionally made blank: we always use I6's short_name property
-instead. I7's spatial plugin, if loaded (as it usually is), will have
+instead. I7's spatial feature, if loaded (as it usually is), will have
annotated the Inter symbol for the object with an "arrow count", that is,
a measure of its spatial depth. This we translate into I6 arrow notation.
-If the spatial plugin wasn't loaded then we have no notion of containment,
+If the spatial feature wasn't loaded then we have no notion of containment,
all arrow counts are 0, and we define a flat sequence of free-standing objects.
§4. Plugins. Except for the current minimal section of code, the if module is comprised
-of the following plugins. They all belong to an "if" plugin, but that does
+of the following features. They all belong to an "if" feature, but that does
nothing except to be a parent to them; it has no activation function.