Overview

So far, we have relied on implicit guidance on how to assemble core assets and then we manually perform a product instantiation since the MLPolyR language could not state the relations between a feature and its corresponding code segments in the program text. See here for more information. However, the recent addtion of a macro system enables developers to explicitly specify the relations between features and core assets as a set of rules.

One benefit of it is that the MLPolyR compiler can automate product engineering process, that is, it can automatically pick a right reference architecture and its associated components with respect to the given rules.

The macro system

For example, suppose the following macro term in the program text:

module Ix = @Interp

The macro term @Interp will get expanded depending on the feature selection at the parse time and such expansions are specified as a sequence of rules in the form of feature configuration.

Feature configuration

The expansion rules are used to map feature sets into feature-related abstractions (i.e., module names). For example, the expansion rules for a family of the SAL interpreters look like:

(* Architecture Model *)

Interp : InterpFun    (Checker, Evaluator)            {}
       | InterpOptFun (Checker, Optimizer, Evaluator) {Optimizer}


(* Component Model *)

Checker   : Check             {}
          | ECheck            {Conditional}

Optimizer : COptimizer        {Optimizer, ConstantFolding}
          | ECOptimizer       {Optimizer, Conditional, ConstantFolding}
          | ESOptimizer       {Optimizer, Conditional, ShortCircuit}
          | ECSOptimizer      {Optimizer, Conditional, ConstantFolding, ShortCircuit}

Evaluator : BigStep           {EvaluationSemantics}
          | EBigStep          {EvaluationSemantics, Conditional}
          | Machine           {MachineSemantics}
          | EMachine          {MachineSemantics, Conditional}

":" denotes a "is-one-of" relations. In this example, for instnace, a macro term @Interp will be implemented by either a template "InterpFun" or "InterpOptFun". A template can have multiple arguments in the following parenthesis. A module argument can recursively have its own expansion rules.

Feature selection

Now, we are going to select features:

Language Simple Arithmetic
Conditional
Evaluation Evaluation semantics
Machine semantics
Optimizer Constant folding
Short-circuit

Current feature selection : {}

Code generation

With respect to expansion rules and feature selection, the compiler can pick a right reference architecture and its associated components, so the macro term @Interp will get expanded:

@Interp

Comments

We are continuing this work in several ways. One of them is to validate feature selection. Since our expansion rules do not support any specification of feature relations (i.e., mutually exclusive or required relations), the current compiler cannot detect any invalid feature sets. We are currently investigating to adopt the so-called "AutoForm" technology to provide visual feedback as a user selects features, pointing out mistakes.

For example, the previous feature selection can be validated on the fly:

Language Simple Arithmetic
Conditional
Evaluation Evaluation semantics
Machine semantics
Optimizer Constant folding
Short-circuit

More information is available at SmartForm or FeatureForm.