Fix spec typos

hcl/hclsyntax/spec.md

@@ -4,12 +4,12 @@ This is the specification of the syntax and semantics of the native syntax
 for HCL. HCL is a system for defining configuration languages for applications.
 The HCL information model is designed to support multiple concrete syntaxes
 for configuration, but this native syntax is considered the primary format
-and is optimized for human authoring and maintenence, as opposed to machine
+and is optimized for human authoring and maintenance, as opposed to machine
 generation of configuration.
 
 The language consists of three integrated sub-languages:
 
-* The _structural_ language defines the overall heirarchical configuration
+* The _structural_ language defines the overall hierarchical configuration
   structure, and is a serialization of HCL bodies, blocks and attributes.
 
 * The _expression_ language is used to express attribute values, either as
@@ -186,7 +186,7 @@ for later evaluation by the calling application.
 ### Blocks
 
 A _block_ creates a child body that is annotated with a block _type_ and
-zero or more block _labels_. Blocks create a structural heirachy which can be
+zero or more block _labels_. Blocks create a structural hierachy which can be
 interpreted by the calling application.
 
 Block labels can either be quoted literal strings or naked identifiers.
@@ -296,7 +296,7 @@ There is a syntax ambiguity between _for expressions_ and collection values
 whose first element is a reference to a variable named `for`. The
 _for expression_ interpretation has priority, so to produce a tuple whose
 first element is the value of a variable named `for`, or an object with a
-key named `for`, use paretheses to disambiguate:
+key named `for`, use parentheses to disambiguate:
 
 * `[for, foo, baz]` is a syntax error.
 * `[(for), foo, baz]` is a tuple whose first element is the value of variable
@@ -482,7 +482,7 @@ object.
 In the case of object `for`, it is an error if two input elements produce
 the same result from the attribute name expression, since duplicate
 attributes are not possible. If the ellipsis symbol (`...`) appears
-immediately after the value experssion, this activates the grouping mode in
+immediately after the value expression, this activates the grouping mode in
 which each value in the resulting object is a _tuple_ of all of the values
 that were produced against each distinct key.
 
@@ -769,7 +769,7 @@ sequence is escaped as `%%{`.
 
 When the template sub-language is embedded in the expression language via
 _template expressions_, additional constraints and transforms are applied to
-template literalsas described in the definition of template expressions.
+template literals as described in the definition of template expressions.
 
 The value of a template literal can be modified by _strip markers_ in any
 interpolations or directives that are adjacent to it. A strip marker is
@@ -903,7 +903,7 @@ key/value pairs given are returned as the static pairs, with no further
 interpretation.
 
 The usual requirement that an attribute name be interpretable as a string
-does not apply to this static analyis, allowing callers to provide map-like
+does not apply to this static analysis, allowing callers to provide map-like
 constructs with different key types by building on the map syntax.
 
 ### Static Call

hcl/json/spec.md

@@ -5,7 +5,7 @@ for defining configuration languages for applications. The HCL information
 model is designed to support multiple concrete syntaxes for configuration,
 and this JSON-based format complements [the native syntax](../hclsyntax/spec.md)
 by being easy to machine-generate, whereas the native syntax is oriented
-towards human authoring and maintenence.
+towards human authoring and maintenance
 
 This syntax is defined in terms of JSON as defined in
 [RFC7159](https://tools.ietf.org/html/rfc7159). As such it inherits the JSON
@@ -280,9 +280,9 @@ When interpreted as an expression, a JSON array represents a value of a HCL
 tuple type.
 
 Each element of the JSON array represents an element of the HCL tuple type.
-The tuple type is constructed by enumerationg the JSON array elements, creating
+The tuple type is constructed by enumerating the JSON array elements, creating
 for each an element whose type is the result of recursively applying the
-expression mapping rules. Correspondance is preserved between the array element
+expression mapping rules. Correspondence is preserved between the array element
 indices and the tuple element indices.
 
 An instance of the constructed tuple type is then created, whose values are
@@ -325,7 +325,7 @@ HCL null value of the dynamic pseudo-type.
 
 ### Strings
 
-When intepreted as an expression, a JSON string may be interpreted in one of
+When interpreted as an expression, a JSON string may be interpreted in one of
 two ways depending on the evaluation mode.
 
 If evaluating in literal-only mode (as defined by the syntax-agnostic

hcl/spec.md

@@ -29,7 +29,7 @@ which are discussed in detail in a later section.
 A _block_ is a nested structure that has a _type name_, zero or more string
 _labels_ (e.g. identifiers), and a nested body.
 
-Together the structural elements create a heirarchical data structure, with
+Together the structural elements create a hierarchical data structure, with
 attributes intended to represent the direct properties of a particular object
 in the calling application, and blocks intended to represent child objects
 of a particular object.
@@ -269,7 +269,7 @@ are two structural type _kinds_:
   has a type. Attribute names are always strings. (_Object_ attributes are a
   distinct idea from _body_ attributes, though calling applications
   may choose to blur the distinction by use of common naming schemes.)
-* _Tuple tupes_ are constructed of a sequence of elements, each of which
+* _Tuple types_ are constructed of a sequence of elements, each of which
   has a type.
 
 Values of structural types are compared for equality in terms of their
@@ -301,10 +301,10 @@ the same element type.
 
 ### Null values
 
-Each type has a null value. The null value of a type represents the absense
+Each type has a null value. The null value of a type represents the absence
 of a value, but with type information retained to allow for type checking.
 
-Null values are used primarily to represent the conditional absense of a
+Null values are used primarily to represent the conditional absence of a
 body attribute. In a syntax with a conditional operator, one of the result
 values of that conditional may be null to indicate that the attribute should be
 considered not present in that case.
@@ -458,7 +458,7 @@ If semantic checking succeeds without error, the call is _executed_:
   definition is used to determine the call's _result value_.
 
 The result of a function call expression is either an error, if one of the
-erroenous conditions above applies, or the _result value_.
+erroneous conditions above applies, or the _result value_.
 
 ## Type Conversions and Unification
 
@@ -505,7 +505,7 @@ Bidirectional conversions are available between the string and number types,
 and between the string and boolean types.
 
 The bool value true corresponds to the string containing the characters "true",
-while the bool value false corresponds to teh string containing the characters
+while the bool value false corresponds to the string containing the characters
 "false". Conversion from bool to string is safe, while the converse is
 unsafe. The strings "1" and "0" are alternative string representations
 of true and false respectively. It is an error to convert a string other than
@@ -671,7 +671,7 @@ The language-agnosticism of this specification assumes that certain behaviors
 are implemented separately for each syntax:
 
 * Matching of a body schema with the physical elements of a body in the
-  source language, to determine correspondance between physical constructs
+  source language, to determine correspondence between physical constructs
   and schema elements.
 
 * Implementing the _dynamic attributes_ body processing mode by either