Here are some limitations of our Dylan implementations:

Open Dylan

  • The compiler only generates code for x86, though there is a partially completed PowerPC backend.
  • The IDE only runs on Windows because there is only a win32 backend for DUIM. There is a mostly-completed gtk+ backend.
  • The generated code doesn’t run as fast as it could. More optimizations are needed.

Gwydion Dylan

    • d2c (the Gwydion compiler) generates fast code slowly. This problem was solved in the Open Dylan compiler by supporting incremental compilation. We’d like to do the same in d2c
      eventually.
    • The Dylan-to-C interface is good, but sometimes has problems with
      unusual constructs in system header files.

  • Debugging is uncomfortable. Although there’s support on most platforms for dybug, a gdb wrapper that understands Dylan, this can hardly called elegant. But at least it’s there.
  • d2c supports most of the Dylan language as specified in the Dylan Reference Manual (DRM), but is lacking support for some features, such as limited collections.

Mindy

  • Mindy generates slow code quickly. You can
    compile an enormous program into bytecodes in a blink of an eye, but
    it won’t run as fast as the average Perl script—it certainly
    won’t compete with GCC. Because Mindy has such a short turn-around
    time (and a built-in debugger), some developers use it to prototype
    programs, or just to make sure source files will compile before
    subjecting them to a (relatively slow) d2c compile.
  • Mindy doesn’t support Dylan macros and a number
    of other useful features.
  • No further work will be done on Mindy, and it will not be included
    with 2.5.0 and later versions. All current work is focused on d2c and
    Open Dylan.