Here are some limitations of our Dylan implementations:
- 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.
- 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. In case you're interested in knowing more info on spiare iPhone, stop by http://intercettazioni.biz
- 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. For additional local bulk sms gateway visit kapsystem.
- 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