Datatypes in DSL

[donmendelson]

The DSL specification should tell about datatypes of variables, such as whether they are static or dynamic.

My proposal:

• Every variable has a FIX datatype so variables are interchangeable with message fields in an expression.
• A variable does not exist until an assignment expression is evaluated. Then, by default, it assumes the type of field in the expression.
• Type promotion generally happens as in common programming languages. For instance, an integer multiplied by a float yields a float.
• Type promotion is actually table-driven to handle logical cases like price times qty = amt. (That's actually the definition of FIX amt type.)
• Once a variable is created with a type, it retains that type.

[jimnup]

Need to think more about static v. dynamic and exposing that in the DSL. Trying to avoid 4GL syndrome plaguing almost all DSLs I have seen built.

Instead of FIX datatypes - should this be Orchestra datatypes? I would not want to see us bind the DSL to FIX.

[donmendelson]

Jim, I see what you're driving at, and we do have datatype section of Orchestra that can be used to enumerate non-FIX datatypes (example: NYSE Pillar file). However, there are several issues that need to be overcome to get to a completely FIX-agnostic DSL.

• Still the majority of usage will be with FIX APIs, such as QuickFIX. We really do need to know the FIX datatype to properly get and set field values.
• For a non-FIX type system, the DSL implementation would not only need to know the types, but also how to relate literals to the type system and type conversion and promotion rules. This can be table-driven, as I said. We would need to add such rules to Orchestra, but I doubt that most prospective Orchestra users would want to deal with such technicalities. It's easier for me to foresee an alternative DSL library for a non-FIX system.