add rtd yaml

.readthedocs.yaml

@@ -0,0 +1,6 @@
+version: 2
+
+build:
+  os: "ubuntu-20.04"
+  tools:
+    python: "3.9"

docs/introduction.rst

@@ -6,8 +6,9 @@ Dhatupatha and other secondary texts, it defines a formal grammar that
 generates valid Sanskrit expressions.
 
 Padmini is an emulator for this grammar. When feasible, we follow the design
-and spirit of the Ashtadhyayi. But we balance this adherence to tradition with 
-a pragmatic focus on making a clean and maintainable program.
+and spirit of the Ashtadhyayi and the rest of the tradition. But we balance
+this adherence to tradition with a pragmatic focus on making a clean and
+maintainable program.
 
 
 How We Model Data
@@ -27,10 +28,10 @@ the word "bhavati":
 | bhav a ti (6.1.78)
 
 Each line of the prakriyā is its own step, and it is the result of applying the
-rule that appears in parentheses. Notice that in each step of a prakriyā, there
-are one or more **terms** (for example, "bho" or "ti") that each have their own
-labels and properties. And these terms consist of some number of **sounds**
-that can be modified and changed.
+rule that appears in parentheses. In each step of a prakriyā, there are one or
+more **terms** (for example, "bho" or "ti") that each have their own labels and
+properties. And these terms consist of some number of **sounds** that can be
+modified and changed.
 
 .. currentmodule:: padmini.prakriya
 
@@ -39,19 +40,22 @@ and we associate it with metadata in a :class:`~Term` object. And multiple
 :class:`~Term` objects are collected in a :class:`~Prakriya` object, which also
 maintains a record of all of the rules that have been applied so far.
 
+In general, Padmini's user-facing API receives some basic initial conditions
+and returns all prakriyās that satisfy those conditions.
+
 
 How We Model Rules
 ------------------
 
 Rules are of various types, but at a high level, they either (1) modify the
 prakriyā state or (2) prevent other rules from applying. In our model,
-modifying rules just mutate the :class:`~Prakriya` directly, and preventing
-rules are recorded without causing any other state changes.
+rules that modify just mutate the :class:`~Prakriya` directly, and rules that
+prevent are logged but don't cause any other state changes.
 
 A group of rules with a similar purpose is called a *prakaraṇa*. Based on this
-concept, we likewise group rules into functions and modules according to their 
-shared intent. We feel this is worth stating explicitly because the Ashtadhyayi
-itself does *not* make this choice. Rather, the Ashtadhyayi mainly optimizes
+concept, we group rules into functions and modules according to their shared
+intent. We feel this is worth stating explicitly because the Ashtadhyayi itself
+does *not* make this choice. Rather, the Ashtadhyayi mainly optimizes
 for concision and reorders rules if doing so would minimize the total length of
 the text.
 
@@ -93,3 +97,4 @@ Why have we used this approach? Mainly, we've done so because it greatly
 simplifies Padmini's execution flow and makes it much easier to debug problems
 and create patches. Once Padmini is stable, we might revisit this choice; but
 for now, it makes development much faster.
+