Design principles

From Dyna
Jump to: navigation, search

We hope to make Dyna ...

  • Elegant. Dyna programs tend to be very short (see examples). They express the abstract structure of an algorithm. This is useful for curiosity-driven research and pedagogy. It also reduces errors.
  • Convenient. Dyna isn't supposed to take over your life. It compiles into classes designed for tight integration with your C++ main() program. This leaves you in control, and keeps the Dyna language small and beautiful (it doesn't even have I/O).
  • Efficient. We worry about every pointer dereference and pretty much every integer comparison in the compiled code. (This doesn't mean they're all gone yet, though!) Now, it is true that there are some compilation decisions that can't be made optimally without knowing the inputs and method calls that you will feed to the C++ classes. Our strategy for these cases is to allow you to control those decisions by compiler pragmas, and eventually to generate the pragmas automatically by runtime analysis. (Examples: whether to store backpointers or recompute them on demand; what storage disciplines to use for representing particular structure types; how to order the updates.)
  • Trainable. Support for parameter training is built in.
  • Expressive. Dyna was motivated originally by problems in natural language processing, but it stretched naturally to cover a somewhat broader class of problems, and we have tried to accommodate those.
  • Easy to use. We've tried to make installing and compiling fairly easy. We'll soon provide a visual debugger for browsing proof forests, and there is an Emacs mode for editing Dyna code. Eventually we'd like the Dyna compiler to generate SWIG wrappers so that you can call your Dyna code from languages like Perl and Python, not just C++.
Personal tools