B. Provisional language features - intel/device-modeling-language GitHub Wiki

Sometimes, we may choose to extend the DML compiler with a feature before it is ready to be fully incorporated into the language. This can happen for different reasons, e.g. if the design is not fully evaluated or if the feature is backward incompatible. Currently, all provisional features are enabled on a per-file basis, by adding provisional feature_name, other_feature_name; just after the dml 1.4; statement.

Provisional features can come in two flavours:

  • Stable provisional features have a proven design and are expected to remain pretty stable over time. Details in semantics may still change between versions, but if we decide to make a significant incompatible change to a supported provisional, then we will create a second version of the provisional, under a new name, and keep both versions in parallel for some time. It can make sense to use supported provisional features in production code.

  • Unstable provisional features are expected to undergo significant incompatible changes over time, and are generally exposed to allow a dedicated team of modelers to evaluate an early design. It can be used to play around with, but should not be used in production code without first communicating with the DML team.

List of stable provisional features

explicit_param_decls

This feature extends the DML syntax for parameter definitions to distinguish between an intent to declare a new parameter, and an intent to override an existing parameter (including when providing a definition for an abstract parameter). This distinction allows DML to capture misspelled parameter overrides as compile errors.

The following new forms are introduced to mark the intent of declaring a new parameter:

  • For typed parameters, param NAME: TYPE = value; and param NAME: TYPE default value; are essentially shorthands for param NAME: TYPE; followed by param NAME = value; or param NAME default value;.

  • For untyped parameters, param NAME := value; and param :default value; are essentially shorthands for param NAME; followed by param NAME = value; or param NAME default value;.

If one of these forms is used for overriding an existing parameter, then DMLC will signal an error, because the declaration was not intended as an override. DMLC will also signal an error if a plain param NAME = value; or param NAME default value; declaration appears that does not override a pre-existing parameter.

In some rare cases, you may need to declare a parameter without knowing if it's an override or a new parameter. In this case, one can accompany a param NAME = value; or param NAME default value; declaration with a param NAME; declaration in the same scope/rank. This marks that the parameter assignment may be either an override or a new parameter, and no error will be printed.

Enabling the explicit_param_decls feature in a file only affects the parameter definitions specified in that file.

⚠️ **GitHub.com Fallback** ⚠️