diff options
| author | Jay Kwak <82421531+jkwak-work@users.noreply.github.com> | 2024-10-25 21:12:37 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-10-25 21:12:37 -0700 |
| commit | a508b264eda4bc3c99ba1f44eab1dec6e5ce06c0 (patch) | |
| tree | 717722aefcae6b2a5adbccfbcd8aece4ed81f0b7 /docs/design/overview.md | |
| parent | 49c691e86862d092cd389a02beb4003ee59a4417 (diff) | |
Swap the term StdLib with Core-Module or Standard-Module in documents (#5414)
This PR is limited to documents.
All use of "Standard library" or "StdLib" are replaced with either "core module" or "standard modules", depending on the context.
Diffstat (limited to 'docs/design/overview.md')
| -rw-r--r-- | docs/design/overview.md | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/docs/design/overview.md b/docs/design/overview.md index 7c2b16cf3..c81853f1a 100644 --- a/docs/design/overview.md +++ b/docs/design/overview.md @@ -71,7 +71,7 @@ This means that most of the language "keywords" in Slang aren't keywords at all, Syntax declarations are associated with a callback that is invoked to parse the construct they name. The design of treating syntax as ordinary declarations has a long-term motivation (we'd like to support a flexible macro system) but it also has short-term practical benefits. -It is easy for us to add new modifier keywords to the language without touching the lexer or parser (just adding them to the standard library), and we also don't have to worry about any of Slang's extended construct (e.g., `import`) breaking existing HLSL code that just happens to use one of those new keywords as a local variable name. +It is easy for us to add new modifier keywords to the language without touching the lexer or parser (just adding them to the core module), and we also don't have to worry about any of Slang's extended construct (e.g., `import`) breaking existing HLSL code that just happens to use one of those new keywords as a local variable name. What the parser produces is an abstract syntax tree (AST). The AST currently uses a strongly-typed C++ class hierarchy with a "visitor" API generated via some ugly macro magic. @@ -186,7 +186,7 @@ We make a copy of things so that any optimization/transformation passes we do fo While copying IR code into the fresh module, we have cases where there might be multiple definitions of the same function or other entity. In those cases, we apply "target specialization" to pick the definition that is the best for the chosen target. -This step is where we can select between, say, a built-in definition of the `saturate` function for D3D targets, vs. a hand-written one in the Slang standard library to use for GLSL-based targets. +This step is where we can select between, say, a built-in definition of the `saturate` function for D3D targets, vs. a hand-written one in a Slang standard module to use for GLSL-based targets. ### API Legalization |