Slight rewording

docs/syntax-attributes-functions-parameters.md

@@ -18,7 +18,7 @@ attribute = '@' NAME
           | '@' NAME '(' ATOMIC-LITERAL (',' ATOMIC-LITERAL)* ')'
 ```
 
-The extension proposed to the [Attributes](./syntax-attributes-functions.md) RFC is in the second and third lines which allow zero or more comma-separated literals to be supplied to the attribute. `NAME` should be a valid identifier immediately following `@` without any spaces. The `ATOMIC-LITERAL` category includes values of type `boolean`, `number`, `string`, and the `nil` value. The `nil` value can be be used for "optional" parameters when no valid value exists. As a hypothetical example, consider the `@deprecated(<new-function-name>, <warning-message>)` attribute. Assume a function is being marked deprecated because we are getting rid of the feature entirely and there is no other function replacing it. In that case, we can pass `nil` for the `<new-function-name>` parameter. An alternative would be to allow this attribute to have either one or two parameters. But that still won't help when an attribute can take three parameters and we want to ignore the second. A `(` following a `NAME`, with or without intervening whitespace, starts a parameter list for that attribute, even if the attribute does not support parameters. The parser will only check for syntacting correctness. The implemention will raise an error when it uses the attribute and finds that an invalid number or type of arguments were supplied. The implemention will treat an attribute with an empty parameter list equivalent to one without parameters. This means that `@native()` is the same as `@native`. This gives us forward compatibility if we decide to support attributes on parenthesized expressions in the future. Consider the following hypothetical example with a `@my_attribute` attribute, which does not take any parameters, applied to a parenthesized expression.
+The extension proposed to the [Attributes](./syntax-attributes-functions.md) RFC is in the second and third lines which allow zero or more comma-separated literals to be supplied to the attribute. `NAME` should be a valid identifier immediately following `@` without any spaces. The `ATOMIC-LITERAL` category includes values of type `boolean`, `number`, `string`, and the `nil` value. The `nil` value can be be used for "optional" parameters when no valid value exists. As a hypothetical example, consider the `@deprecated(<new-function-name>, <warning-message>)` attribute. Assume a function is being marked deprecated because we are getting rid of the feature entirely and there is no other function replacing it. In that case, we can pass `nil` for the `<new-function-name>` parameter. An alternative would be to allow this attribute to have either one or two parameters. But that still won't help when an attribute can take three parameters and we want to ignore the second. To ensure there is no parsing ambiguity, a `(` following a `NAME`, with or without intervening whitespace, starts a parameter list for that attribute, even if the attribute does not support parameters. The parser will only check for syntacting correctness. The implemention will raise an error when it uses the attribute and finds that an invalid number or type of arguments were supplied. The implemention will treat an attribute with an empty parameter list equivalent to one without parameters. This means that `@native()` is the same as `@native`. This gives us forward compatibility if we decide to support attributes on parenthesized expressions in the future. Consider the following hypothetical example with a `@my_attribute` attribute, which does not take any parameters, applied to a parenthesized expression.
 
 ```lua
 @my_attribute