From 499a17091c22677186bc905b7b64414741cdd202 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Thu, 4 Nov 2021 10:50:46 -0400 Subject: [PATCH] Spelling (#119) Fixed various spelling errors. Co-authored-by: Josh Soref --- docs/function-debug-info.md | 2 +- docs/function-table-freeze.md | 2 +- docs/syntax-continue-statement.md | 2 +- docs/syntax-if-expression.md | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/function-debug-info.md b/docs/function-debug-info.md index 1362dc9..5f486db 100644 --- a/docs/function-debug-info.md +++ b/docs/function-debug-info.md @@ -14,7 +14,7 @@ Today Luau provides only one method to get the callstack, `debug.traceback`. Thi There are a few cases where this can be inconvenient: -- Sometimes it is useful to pass the resulting call stack to some system expecting a structured input, e.g. for crash aggreggation +- Sometimes it is useful to pass the resulting call stack to some system expecting a structured input, e.g. for crash aggregation - Sometimes it is useful to use the information about the caller for logging or filtering purposes; in these cases using just the script name can be useful, and getting script name out of the traceback is slow and imprecise Additionally, in some cases instead of getting the information (such as script or function name) from the callstack, it can be useful to get it from a function object for diagnostic purposes. For example, maybe you want to call a callback and if it doesn't return expected results, display a user-friendly error message that contains the function name & script location - these aren't possible today at all. diff --git a/docs/function-table-freeze.md b/docs/function-table-freeze.md index 47de0f9..ca81988 100644 --- a/docs/function-table-freeze.md +++ b/docs/function-table-freeze.md @@ -44,7 +44,7 @@ To limit the use of `table.freeze` to cases when table contents can be freely ma Exposing the internal "readonly" feature may have an impact on interoperability between scripts - for example, it becomes possible to freeze some tables that scripts may be expecting to have write access to from other scripts. Since we don't provide a way to unfreeze tables and freezing a table with a locked metatable fails, in theory the impact should not be any worse than allowing to change a metatable, but the full extents are unclear. -There may be existing code in the VM that allows changing frozen tables in ways that are benign to the current sanboxing code, but expose a "gap" in the implementation that becomes significant with this feature; thus we would need to audit all table writes when implementing this. +There may be existing code in the VM that allows changing frozen tables in ways that are benign to the current sandboxing code, but expose a "gap" in the implementation that becomes significant with this feature; thus we would need to audit all table writes when implementing this. ## Alternatives diff --git a/docs/syntax-continue-statement.md b/docs/syntax-continue-statement.md index 4adde09..94e2009 100644 --- a/docs/syntax-continue-statement.md +++ b/docs/syntax-continue-statement.md @@ -56,7 +56,7 @@ end These rules are simple to implement. In any Lua parser there is already a point where you have to disambiguate an identifier that starts an assignment statement (`foo = 5`) from an identifier that starts a function call (`foo(5)`). It's one of the few, if not the only, place in the Lua grammar where single token lookahead is not sufficient to parse Lua, because you could have `foo.bar(5)` or `foo.bar=5` or `foo.bar(5)[6] = 7`. -Because of this, we need to parse the entire left hand side of an assignment statement (primaryexpr in Lua's BNF) and then check if it was a function call; if not, we'd expect it to be an assignment statement. +Because of this, we need to parse the entire left hand side of an assignment statement (primaryexp in Lua's BNF) and then check if it was a function call; if not, we'd expect it to be an assignment statement. Alternatively in this specific case we could parse "continue", parse the next token, and if it's one of the exclusion list above, roll the parser state back and re-parse the non-continue statement. Our lexer currently doesn't support rollbacks but it's also an easy strategy that other implementations might employ for `continue` specifically. diff --git a/docs/syntax-if-expression.md b/docs/syntax-if-expression.md index 9fc8556..a435fd5 100644 --- a/docs/syntax-if-expression.md +++ b/docs/syntax-if-expression.md @@ -12,7 +12,7 @@ Introduce a form of ternary conditional using `if cond then value else alternati Luau does not have a first-class ternary operator; when a ternary operator is needed, it is usually emulated with `and/or` expression, such as `cond and value or alternative`. -This expression evaluates to `value` if `cond` and `value` are truthful, and `alternative` otherwise. In particular it means that when `value` is `false` or `nil`, the result of the entire expression is `alternative` even when `cond` is truthful - which doesn't match the expected ternary logic and is a frequent source of subtle errors. +This expression evaluates to `value` if `cond` and `value` are truthy, and `alternative` otherwise. In particular it means that when `value` is `false` or `nil`, the result of the entire expression is `alternative` even when `cond` is truthy - which doesn't match the expected ternary logic and is a frequent source of subtle errors. Instead of `and/or`, `if/else` statement can be used but since that requires a separate mutable variable, this option isn't ergonomic. An immediately invoked function expression is also unergonomic and results in performance issues at runtime. @@ -22,7 +22,7 @@ To solve these problems, we propose introducing a first-class ternary conditiona Concretely, the `if-then-else` expression must match `if then else `; it can also contain an arbitrary number of `elseif` clauses, like `if then elseif then else `. Note that in either case, `else` is mandatory. -The result of the expression is the then-expression when condition is truthful (not `nil` or `false`) and else-expression otherwise. Only one of the two possible resulting expressions is evaluated. +The result of the expression is the then-expression when condition is truthy (not `nil` or `false`) and else-expression otherwise. Only one of the two possible resulting expressions is evaluated. Example: