Required and NoValue keywords
In the previous version of the language, it was permitted to create a rule with no default value. This would generate an error at run-time when the evaluator found that no value could be computed. This was common for Parameter rules; which would simply report that the parameter had not been supplied. In Intent Language version 3.0, "empty" rules are not permitted. Instead, two commonly used keywords are used: Required and NoValue. When encountered during evaluation, Required generates the "required value not supplied" error, but NoValue is returned as NoValue (no error is generated). Required parameters MUST be supplied before the Part Editor will allow the Part to be created.
This difference means that the IntentUp translation cannot reasonably supply either Required or NoValue when an empty rule is encountered. However, since the intent of the empty rule is not always clear, IntentUp inserts [[Required|NoValue]] in its place. This construct will not compile, and any attempt to load the Design will fail. The file must then be fixed manually, after inspection of rules to determine whether Required or NoValue should be used.
- Canonicals should almost always be Required.
- If there are tests for NoValue, then NoValue should be used.
- When a Parameter is one of the enablers of a Group rule, it usually should not be Required (Required means it must be supplied).
- When none of the above applies, use Required, and test. If it is not the right thing, it will usually be immediately apparent.
Language-building rules
Rules which build language elements are not able to be converted. Such rules typically consist of string literals being combined with computed strings. The results are then supplied to Intent as language source. All such rules must be converted to the new syntax. For example:
Syntax-specific rules
Users sometimes use string search functions to parse language elements, like reference chains. Since the syntax of reference chains has changed, these rules will fail.
Statements vs. Expressions
In prior versions of the Intent Language, all language constructs were expressions that returned a value. In Intent Language version 3.0, many of the same constructs are now statements which do not return a value, or are permitted both as statements or as expressions. When used as statements, any return value is ignored.
Because the If-then-else expression always returned a value in the past, it led to some “dead” else branches when used for effect, rather than value, for example:
The else clause here is completely unused. This translates to:
IntentUp attempts to detect such problems, and rewrite to use the new “If-Then” construct, but if it cannot, it must be rewritten by hand as:
Declarations and types
Intent Language version 3.0 requires declaration of all local variables. Earlier versions do not. As a result, IntentUp adds Dim statements for all local variables in statement blocks. Because the type of such variables is unknown, they are declared as type Any. Such declarations can often hide the source of problems in an application, and we recommend changing to specific types when they are known.
Notes on specific elements
Loop
Intent Language version 3.0 does not have a single Loop construct equivalent to the Loop expression available in earlier versions. Instead, there are several iteration constructs which can be used in different situations. IntentUp does not attempt to determine if a given Loop can be converted to a new iteration construct. Instead, IntentUp, and Intent Language version 3.0, supports a “Compatible Loop” syntax that allows precise mapping of old loops into code that works identically.
Ref
The Ref function uses a string that represents a reference chain. The syntax for reference chains has changed. For compatibility reasons, Intent Language version 3.0 will accept the colon-based syntax of earlier Intent language versions. So statements such as,
translate to:
but should still function correctly (assuming wayToUpdate evaluates to a string). However this is not true for other functions which take language source as strings.
Unary Minus and Not Operator
In prior versions of Intent, the unary ‘–‘ operated on both numeric values and boolean values. In Intent Language version 3.0, two different operators are used. The minus sign is kept for numerics, but the logical operator NOT is used for booleans. Because the translator in most cases does not know the type of the value (unless it is a literal) involved, it does not attempt to translate the operator. In cases where the operand is a binary boolean expression, it does translate the operator to NOT.
Trailing Commas in Lists and Arguments
In prior version of Intent, trailing commas or separators were permitted (and ignored). A list such as {1, 3, } was parsed as a list of 2 items. IntentUp uses the older parser technology, so these are still permitted and ignored. However, this means that there will be no trailing commas in the output, since they were ignored on input. Also, users comfortable with the older tolerance of trailing separators should be aware that they are no longer permitted, and will produce a syntax error if used.