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.