6 files changed, 16 insertions, 16 deletions

diff --git a/docs/proposals/007-variadic-generics.md b/docs/proposals/007-variadic-generics.md
index 9249119f7..8e5de1f04 100644
--- a/docs/proposals/007-variadic-generics.md
+++ b/docs/proposals/007-variadic-generics.md
@@ -29,8 +29,8 @@ Background
 ----------
 
 We have several cases that will benefit from variadic generics. One simplest example is the `printf` function is currently
-defined to have different overloads for each number of arguments. The downside of duplicating overloads is the bloating standard
-library size and a predefined upper limit of argument count. If users are to build their own functions that wraps the `printf`
+defined to have different overloads for each number of arguments. The downside of duplicating overloads is the bloating the core
+module size and a predefined upper limit of argument count. If users are to build their own functions that wraps the `printf`
 function, they will have to define a set of overloads for each number of arguments too, further bloating code size.
 
 Some of our users would like to implement the functor idiom in their shader code with interfaces. This is almost possible
diff --git a/docs/proposals/008-tuples.md b/docs/proposals/008-tuples.md
index efbcb7d28..a052585d6 100644
--- a/docs/proposals/008-tuples.md
+++ b/docs/proposals/008-tuples.md
@@ -28,7 +28,7 @@ to interop more directly with other parts of the user application written in oth
 Proposed Approach
 -----------------
 
-With variadic generics support, we can now easily define a Tuple type in stdlib as:
+With variadic generics support, we can now easily define a Tuple type in the core module as:
 ```
 __generic<each T>
 __magic_type(TupleType)
@@ -43,7 +43,7 @@ This will allow users to instantiate tuple types from their code with `Tuple<T0,
 
 ### Constructing Tuple Values
 
-To make it easy to construct tuples, we will define a `makeTuple` function in stdlib as:
+To make it easy to construct tuples, we will define a `makeTuple` function in the core module as:
 ```
 __intrinsic_op($(kIROp_MakeTuple))
 Tuple<expand each T> makeTuple(expand each T values);
@@ -73,7 +73,7 @@ let v = t._1_0;
 
 ### Concatenation
 
-We can define tuple concatenation operation in stdlib as:
+We can define tuple concatenation operation in the core module as:
 ```
 Tuple<expand each T, expand each U> concat<each T, each U>(Tuple<expand each T> first, Tuple<expand each U> second)
 {
@@ -103,7 +103,7 @@ int foo<each T>()
 ### Operator Overloads
 
 We should have builtin operator overloads for all comparison operators if every element type of a tuple conforms to `IComparable`.
-This can be supported by defining an overload for these operators in stdlib in the form of:
+This can be supported by defining an overload for these operators in the core module in the form of:
 ```
 bool assign(inout bool r, bool v) { r = v;  return v; }
 
@@ -137,4 +137,4 @@ Tuple<T, U> concat<each T, each U>(Tuple<T> t, each U values);
 ```
 However, this could lead to surprising behavior when the user writes `concat(t0, t1, t2)` where t1 and t2 are also tuples.
 Having this overload means the result would be `(t0_0, t0_1, ... t0_n, t1, t2)` where the user could be expecting `t1` and `t2`
-to be flattened into the resulting tuple. To avoid this surprising behavior, we decide to not include this overload in stdlib.
\ No newline at end of file
+to be flattened into the resulting tuple. To avoid this surprising behavior, we decide to not include this overload in the core module.
diff --git a/docs/proposals/010-new-diff-type-system.md b/docs/proposals/010-new-diff-type-system.md
index dd5623a1d..61157819e 100644
--- a/docs/proposals/010-new-diff-type-system.md
+++ b/docs/proposals/010-new-diff-type-system.md
@@ -111,9 +111,9 @@ interface IDifferentiablePtrType : __IDifferentiableBase
 
 ```
 
-Some extras in stdlib allow us to constrain the diffpair type for things like `IArithmetic`
+Some extras in the core module allow us to constrain the diffpair type for things like `IArithmetic`
 ```csharp
-// --- STDLIB EXTRAS ---
+// --- CORE MODULE EXTRAS ---
 
 interface ISelfDifferentiableValueType : IDifferentiableValueType
 {
diff --git a/docs/proposals/implementation/ast-ir-serialization.md b/docs/proposals/implementation/ast-ir-serialization.md
index 62f18dca9..248b752a1 100644
--- a/docs/proposals/implementation/ast-ir-serialization.md
+++ b/docs/proposals/implementation/ast-ir-serialization.md
@@ -18,8 +18,8 @@ Currently, deserialization of the AST or IR for a module is an all-or-nothing op
 Either the entire `Decl` hierarchy of the AST is deserialized and turned into in-memory C++ objects, or none of it is.
 Similarly, we can either construct the `IRInst` hierarchy for an entire module, or none of it.
 
-Releases of the Slang compiler typically included a serialized form of the standard library ("stdlib") module, and the runtime cost of deserializing this module has proven to be a problem for users of the compiler.
-Becuse parts of the Slang compiler are not fully thread-safe/reentrant, the stdlib must be deserialized for each "global session," so that deserialization cost is incurred per-thread in scenarios with thread pools.
+Releases of the Slang compiler typically included a serialized form of the core module, and the runtime cost of deserializing this module has proven to be a problem for users of the compiler.
+Becuse parts of the Slang compiler are not fully thread-safe/reentrant, the core module must be deserialized for each "global session," so that deserialization cost is incurred per-thread in scenarios with thread pools.
 Even in single-threaded scenarios, the deserialization step adds significantly to the startup time for the compiler, making single-file compiles less efficient than compiling large batches of files in a single process.
 
 Overview of Proposed Solution
@@ -283,4 +283,4 @@ Each entry in the abbreviation table would store:
 
 When deserializing a node, code would read its abbreviation index first, and then look up the corresponding abbreviation to both find important information about the node, and also to drive deserialization of the rest of its data (e.g., by determining how many operands to read before reading in children).
 
-In cases where the low-level serialization uses things like variable-length encodings for integers, the abbreviations can be sorted so that the most-frequently used abbreviations have the lowest indices, and thus take the fewest bits/bytes to encode.
\ No newline at end of file
+In cases where the low-level serialization uses things like variable-length encodings for integers, the abbreviations can be sorted so that the most-frequently used abbreviations have the lowest indices, and thus take the fewest bits/bytes to encode.
diff --git a/docs/proposals/legacy/001-basic-interfaces.md b/docs/proposals/legacy/001-basic-interfaces.md
index 4d04cbe04..6083c8ae9 100644
--- a/docs/proposals/legacy/001-basic-interfaces.md
+++ b/docs/proposals/legacy/001-basic-interfaces.md
@@ -1,7 +1,7 @@
 Basic Interfaces
 ================
 
-The Slang standard library is in need of basic interfaces that allow generic code to be written that abstracts over built-in types.
+The Slang core module is in need of basic interfaces that allow generic code to be written that abstracts over built-in types.
 This document sketches what the relevant interfaces and their operations might be.
 
 Status
@@ -49,7 +49,7 @@ T horizontalSum<T : __BuiltinFloatingPointType>( vector<T,4> v )
 }
 ```
 
-This alternative is much more palatable to users, but it results in them using a double-underscored interface (which we consider to mean "implementation details that are subject to change"). Users often get tripped up when they find out that certain operations that make sense to be available through `__BuiltinFloatingPointType` are not available (because those operations were not needed in the definition of the stdlib, which is what the `__` interfaces were created to support).
+This alternative is much more palatable to users, but it results in them using a double-underscored interface (which we consider to mean "implementation details that are subject to change"). Users often get tripped up when they find out that certain operations that make sense to be available through `__BuiltinFloatingPointType` are not available (because those operations were not needed in the definition of the core module, which is what the `__` interfaces were created to support).
 
 Related Work
 ------------
@@ -228,7 +228,7 @@ The main reason for the current `__Builtin` interfaces is that it allows us to d
 
 ### What should the naming convention be for `interface`s in Slang?
 
-These would be the first `interface`s officially exposed by the standard library.
+These would be the first `interface`s officially exposed by the core module.
 While most of our existing code written in Slang uses an `I` prefix as the naming convention for `interface`s (e.g., `IThing`), we have never really discussed that choice in detail.
 Whatever we decide to expose for this stuff is likely to become the de facto convention for Slang code.
 
diff --git a/docs/proposals/legacy/003-error-handling.md b/docs/proposals/legacy/003-error-handling.md
index 28652824f..23c7bdc40 100644
--- a/docs/proposals/legacy/003-error-handling.md
+++ b/docs/proposals/legacy/003-error-handling.md
@@ -84,7 +84,7 @@ Proposed Approach
 We propose a modest starting point for error handling in Slang that can be extended over time.
 The model borrows heavily from Swift, but also focuses on strongly-typed errors.
 
-The standard library will provide a built-in interface for errors, initially empty:
+The core module will provide a built-in interface for errors, initially empty:
 
 ```
 interface IError {}