MWorks variable types

Support
1

Hi Chris,

We’d like to get a solid understanding of how MWorks deals with variable type. I found this discussion:

http://help.mworks-project.org/discussions/questions/62-expression-parser-and-floatsints

In which there are a lot of different ideas about how to do typing in MWorks but it isn’t clear what the final decision was. Has this been documented?

  • Evan
2

Hi Evan,

Unfortunately, nothing has changed since the discussion you cited; types in MWorks are still confusing and a bit of a mess. Let me try to summarize the key points.

First, variables in MWorks do not have types. A given variable can hold a value of any type (boolean, integer, float, string, list, etc.), and the type of value held by a variable can be changed at any time via an assignment action.

Second, the variety of number types leads to a couple issues. As mentioned in that previous discussion, boolean values aren’t allowed to participate in arithmetic operations. More problematically, dividing one integer-typed value by another produces an integer-valued result, so anything to the right of the decimal point in the result is truncated. Practically speaking, this means that when dividing, you should always ensure that the divisor is a floating-point value, either by using a floating-point literal (e.g. 2.0) or casting a variable value (e.g. (double)two).

Finally, there’s that damn “type” field in variable declarations. Contrary to intuition, this does not serve to indicate that a given variable can only hold values of the specified type. Rather, it determines how the text in the “default_value” field is interpreted when setting the default value. If “type” is set to one of the numeric types (“boolean”, “integer”, or “float”), the text in “default_value” is evaluated like any other expression, and the resulting value is then cast to the specified type and assigned to the variable. If “type” is string, the text in “default_value” is used as-is as the content of a new string value, which is assigned to the variable. Finally, if “type” is “list”, then the text in “default_value” is interpreted as a comma-separated list of expressions, each of which is evaluated and appended to a new list value, which is then assigned to the variable. See the attached experiment for a demonstration.

So that’s where things stand today. In the future, I think we should make two changes:

  1. Make all division non-truncating, either by ensuring that the result of division is always a float, or by eliminating integer numeric types altogether.
  2. Deprecate the “type” field. In the absence of a “type” value, default to evaluating the text in “default_value” as an expression and using the result as the default value (i.e. handle “default_value” just like the “value” field of an assignment action).

Hopefully this answers your question. If you want more specifics about anything, please let me know.

Chris

3

Attachment: var_type.xml (1.9 KB)