kjuulh/rhai
1
0
Fork 0
Code Issues 1 Pull Requests 1 Packages Projects Releases Wiki Activity

Replace - with –

Browse Source
This commit is contained in:
Stephen Chung
2020-12-29 23:01:34 +08:00
parent a45876856d
commit db5b855dea
51 changed files with 149 additions and 149 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/src/engine/call-fn.md
View File

@@ -3,7 +3,7 @@ Calling Rhai Functions from Rust
{{#include ../links.md}}
Rhai also allows working _backwards_ from the other direction - i.e. calling a Rhai-scripted function
Rhai also allows working _backwards_ from the other direction – i.e. calling a Rhai-scripted function
from Rust via `Engine::call_fn`.
Functions declared with `private` are hidden and cannot be called from Rust (see also [modules]).
@@ -56,8 +56,8 @@ let result: () = engine.call_fn(&mut scope, &ast, "hidden", ())?;
```
Low-Level API - `Engine::call_fn_dynamic`
----------------------------------------
Low-Level API – `Engine::call_fn_dynamic`
----------------------------------------------
For more control, construct all arguments as `Dynamic` values and use `Engine::call_fn_dynamic`, passing it
anything that implements `AsMut<Dynamic>` (such as a simple array or a `Vec<Dynamic>`):

46
doc/src/engine/custom-syntax.md
View File

@@ -33,8 +33,8 @@ Where This Might Be Useful
* Where you just want to confuse your user and make their lives miserable, because you can.
Step One - Design The Syntax
---------------------------
Step One &ndash; Design The Syntax
---------------------------------
A custom syntax is simply a list of symbols.
@@ -48,11 +48,11 @@ These symbol types can be used:
* Identifiers following the [variable] naming rules.
* `$expr$` - any valid expression, statement or statement block.
* `$expr$` &ndash; any valid expression, statement or statement block.
* `$block$` - any valid statement block (i.e. must be enclosed by `'{'` .. `'}'`).
* `$block$` &ndash; any valid statement block (i.e. must be enclosed by `'{'` .. `'}'`).
* `$ident$` - any [variable] name.
* `$ident$` &ndash; any [variable] name.
### The First Symbol Must be an Identifier
@@ -103,8 +103,8 @@ print(hello); // variable declared by a custom syntax persists!
```
Step Two - Implementation
-------------------------
Step Two &ndash; Implementation
------------------------------
Any custom syntax must include an _implementation_ of it.
@@ -176,8 +176,8 @@ let result = context.eval_expression_tree(expression)?;
```
Step Three - Register the Custom Syntax
--------------------------------------
Step Three &ndash; Register the Custom Syntax
--------------------------------------------
Use `Engine::register_custom_syntax` to register a custom syntax.
@@ -244,8 +244,8 @@ exec |x| -> { x += 1 } while x < 0;
```
Step Four - Disable Unneeded Statement Types
-------------------------------------------
Step Four &ndash; Disable Unneeded Statement Types
-------------------------------------------------
When a DSL needs a custom syntax, most likely than not it is extremely specialized.
Therefore, many statement types actually may not make sense under the same usage scenario.
@@ -258,24 +258,24 @@ the scenario.
A keyword or operator that is disabled can still be used in a custom syntax.
In an extreme case, it is possible to disable _every_ keyword in the language, leaving only
custom syntax (plus possibly expressions). But again, Don't Do It™ - unless you are certain
custom syntax (plus possibly expressions). But again, Don't Do It™ &ndash; unless you are certain
of what you're doing.
Step Five - Document
--------------------
Step Five &ndash; Document
-------------------------
For custom syntax, documentation is crucial.
Make sure there are _lots_ of examples for users to follow.
Step Six - Profit!
------------------
Step Six &ndash; Profit!
------------------------
Really Advanced - Custom Parsers
-------------------------------
Really Advanced &ndash; Custom Parsers
-------------------------------------
Sometimes it is desirable to have multiple custom syntax starting with the
same symbol. This is especially common for _command-style_ syntax where the
@@ -395,8 +395,8 @@ Most strings are [`ImmutableString`][string]'s so it is usually more efficient t
The return value is `Result<Option<ImmutableString>, ParseError>` where:
| Value | Description |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Ok(None)` | parsing complete and there are no more symbols to match |
| `Ok(Some(symbol))` | the next symbol to match, which can also be `$expr$`, `$ident$` or `$block$` |
| `Err(ParseError)` | error that is reflected back to the [`Engine`] - normally `ParseError(ParseErrorType::BadInput(LexError::ImproperSymbol(message)), Position::NONE)` to indicate that there is a syntax error, but it can be any `ParseError`. |
| Value | Description |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Ok(None)` | parsing complete and there are no more symbols to match |
| `Ok(Some(symbol))` | the next symbol to match, which can also be `$expr$`, `$ident$` or `$block$` |
| `Err(ParseError)` | error that is reflected back to the [`Engine`] &ndash; normally `ParseError(ParseErrorType::BadInput(LexError::ImproperSymbol(message)), Position::NONE)` to indicate that there is a syntax error, but it can be any `ParseError`. |

2
doc/src/engine/expressions.md
View File

@@ -11,7 +11,7 @@ In these cases, use the `Engine::compile_expression` and `Engine::eval_expressio
let result = engine.eval_expression::<i64>("2 + (10 + 10) * 2")?;
```
When evaluating _expressions_, no full-blown statement (e.g. `if`, `while`, `for`, `fn`) - not even variable assignment -
When evaluating _expressions_, no full-blown statement (e.g. `if`, `while`, `for`, `fn`) &ndash; not even variable assignment &ndash;
is supported and will be considered parse errors when encountered.
[Closures] and [anonymous functions] are also not supported because in the background they compile to functions.

2
doc/src/engine/hello-world.md
View File

@@ -43,7 +43,7 @@ Return Type
The type parameter for `Engine::eval` is used to specify the type of the return value,
which _must_ match the actual type or an error is returned. Rhai is very strict here.
There are two ways to specify the return type - _turbofish_ notation, or type inference.
There are two ways to specify the return type &ndash; _turbofish_ notation, or type inference.
Use [`Dynamic`] for uncertain return types.

4
doc/src/engine/metadata/gen_fn_sig.md
View File

@@ -37,12 +37,12 @@ A function registered under the name `foo` with three parameters and unknown ret
> `foo(_, _, _)`
An operator function - again, unknown parameters and return type.
An operator function &ndash; again, unknown parameters and return type.
Notice that function names do not need to be valid identifiers.
> `+(_, _)`
A [property setter][getters/setters] - again, unknown parameters and return type.
A [property setter][getters/setters] &ndash; again, unknown parameters and return type.
Notice that function names do not need to be valid identifiers.
In this case, the first parameter should be `&mut T` of the custom type and the return value is `()`:

2
doc/src/engine/optimize/optimize-levels.md
View File

@@ -5,7 +5,7 @@ Optimization Levels
There are three levels of optimization: `None`, `Simple` and `Full`.
* `None` is obvious - no optimization on the AST is performed.
* `None` is obvious &ndash; no optimization on the AST is performed.
* `Simple` (default) performs only relatively _safe_ optimizations without causing side-effects
(i.e. it only relies on static analysis and [built-in operators] for constant [standard types],

2
doc/src/engine/optimize/semantics.md
View File

@@ -17,7 +17,7 @@ if true { // condition always true
foo(42) // <- the above optimizes to this
```
If the original script were evaluated instead, it would have been an error - the variable `hello` does not exist,
If the original script were evaluated instead, it would have been an error &ndash; the variable `hello` does not exist,
so the script would have been terminated at that point with an error return.
In fact, any errors inside a statement that has been eliminated will silently _disappear_:

2
doc/src/engine/optimize/volatility.md
View File

@@ -6,7 +6,7 @@ Volatility Considerations for Full Optimization Level
Even if a custom function does not mutate state nor cause side-effects, it may still be _volatile_,
i.e. it _depends_ on the external environment and is not _pure_.
A perfect example is a function that gets the current time - obviously each run will return a different value!
A perfect example is a function that gets the current time &ndash; obviously each run will return a different value!
The optimizer, when using [`OptimizationLevel::Full`], will _merrily assume_ that all functions are _pure_,
so when it finds constant arguments (or none) it eagerly executes the function call and replaces it with the result.

6
doc/src/engine/scope.md
View File

@@ -1,4 +1,4 @@
`Scope` - Initializing and Maintaining State
`Scope` &ndash; Initializing and Maintaining State
=================================================
{{#include ../links.md}}
@@ -37,7 +37,7 @@ scope
// First invocation
engine.eval_with_scope::<()>(&mut scope, r"
let x = 4 + 5 - y + z + MY_NUMBER + s.len;
let x = 4 + 5 &ndash; y + z + MY_NUMBER + s.len;
y = 1;
")?;
@@ -46,7 +46,7 @@ let result = engine.eval_with_scope::<i64>(&mut scope, "x")?;
println!("result: {}", result); // prints 1102
// Variable y is changed in the script - read it with 'get_value'
// Variable y is changed in the script &ndash; read it with 'get_value'
assert_eq!(scope.get_value::<i64>("y").expect("variable y should exist"), 1);
// We can modify scope variables directly with 'set_value'