B.1 Changes from FDR1 to FDR2

The transition from FDR1 to FDR2 does require some source changes, due mainly to the new facilities offered by the updated parser. Apart from the loss of support for inline SML (which was never guaranteed to be maintained, and where comparable functionality is provided within the full language) the incompatibilities are all fairly minor.

• Since experience with FDR has established a wider requirement for the declaration of channels, the construct has been adopted into the core language and no longer requires (or accepts) the pragma used to escape it in the past. Thus, to modernise a script, one must globally replace pragma channel by just channel.
• As with channels, so with transparent functions; any tool which encounters a call to such a function must be advised to ignore it if it does not understand it, so the declaration has been adopted into the core language. Again, this is a global replacement of pragma transparent by just transparent.
• The optional colon at the end of a channel declaration introducing simple events (with no dots and no data) is no longer optional; it must not occur. The pattern is easily recognised, however.
• FDR1 did not support the > operator, since it generally clashed with the syntax for the end of a sequence. FDR2 supplies the full suite of comparison operators, although it is advised that parentheses be used to resolve any potential ambiguity.
• Unary minus is a new feature (in FDR1 you had to write an explicit subtraction from zero), and this introduces the possibility of confusion with comments. In a subtraction involving an expression with a unary minus (e.g., `2--1') the `--' is actually interpreted as introducing a single-line comment. And the syntax for block comments clashes with that for a set literal containing a leading unary minus. A solution for this is suggested in A.1.4 Sets, and a (disambiguating) style for using block comments is given in A.7 Mechanics.
• Another potential source of confusion comes from the behaviour of datatype tags (and channel names) in the new facility of pattern matching. In particular, a tag takes precedence over an (otherwise unbound) identifier in a pattern, and so is treated as an explicit pattern to be matched, rather than introducing a (local) identifier bound to the matched value (see A.2 Pattern Matching). To avoid this problem, a script should not use short, common names for datatype tags or channel names.
• The final change is a little less straightforward: in order to provide reasonable type-checking (and for all the other reasons that programming languages generally adopt the feature), the standard needs all identifiers to be declared, either implicitly in the course of giving them a definition or explicitly. The only case this affects is the convenience supported by the old language that an unbound identifier (in an expression context) stands for a distinguished constant. The only way in the FDR2 language to introduce such constants is by means of the datatype declaration. It is important for type-correctness that any objects which may need to be compared for equality (or placed in the same set) should be declared with the same type. The example given above:

  pragma channel fruit : {banana, apple, orange}
  

  should be recoded as:

  datatype FRUIT = banana | apple | orange
  channel fruit : FRUIT
  

  Of course, the non-defining use of FRUIT in the channel declaration could have been left as {banana,apple,orange}. It might be possible automatically to generate a single declaration of all such constants as members of a single enumeration, but this obviously circumvents the type safety which was the original purpose. In most cases, therefore, manual intervention is probably to be recommended.

Go to the Next or Previous section, the Detailed Contents, or the FS(E)L Home Page.