Current limitations and workarounds
This website (dyna.org) documents the evolving design of the Dyna language. Some features documented on the site are designed but not yet implemented. We have tried to indicate in the wiki when this is the case. (If we didn't, please edit us.)
This section reviews the most significant limitations of the current implementation, especially limitations that prevent some of the examples from running as they stand. We also explain how to work around some of these limitations.
Please let us know which of these features are most urgent for your work.
At present, Dyna programs must have a restricted homogeneous form:
- All items must have the same type and the same default value. It is not yet possible to mix
boolitems in the same program, as in this factorial example.
- All accumulation operators must be identical. It is not yet possible to mix
min=, etc. in the same program, as needed for game tree analysis.
- All computed expressions must use the same operator. It is not yet possible to have both
b cin the same program, or to write
a*b c, as in these smoothing formulas.
- The (single) operator that appears in expressions must distribute over the (single) accumulation operator.
In particular, you are limited to the following types of programs, which correspond to different semirings. (Feel free to ask us to extend this list. It's easy for us to do so as long as the distributive property holds.)
:- item(item, bool, false). a |= b