Re: dylan revival

[Bruce Hoult <address@hidden>]

In article <B8D0D224.F515%scott_ribe@killerbytes.com>,
 Scott Ribe <scott_ribe@killerbytes.com> wrote:

> > CLR is going to be a major time and resource waster for languages that
> > cannot compete with VB and C-hash in terms of FUD and lock-in. Dylan
> > would do much better to side with Apache and open web services.
> 
> Exactly. For powerful & immutable reasons which would be a waste of time and
> effort to fight against.
> 
> > This is an interesting idea. The main problem with implementing Dylan is
> > the Macro system. I've been toying with the idea of a macro-less "Dylan
> > Light" for Marlais and Mindy.
> > The basic Dylan libraries are well defined. On top of this there are the
> > common-dylan libraries, and on top of those goes DUIM (Dylan's interface
> > manager, like Lisp's CLIM or Java's AWT). Socket libraries, ODBC, COM,
> > CORBA, OpenGL, XML, etc. can be added as needed.
> 
> Just curious, would the macro implementation be substantially easier if
> Dylan had stuck with S-exp syntax? Or are the problems deeper?

OK, maybe I'm thick, but I don't see how Dylan macros are a problem.  In 
d2c they are completely dealt with in the parsing stage, and this runs 
pretty damn fast -- certainly fast enough that we'll need to make all of 
library loading, library dumping, optimization, and C code generation at 
least an order of magnitude faster than they are at present before we'll 
even notice parsing/macro expansion as a bottleneck.

Maybe the implementation is complex.  Who cares?  It's written.  Even if 
someone develops a macroless Dylan compiler, it'd be a pretty small 
effort to modify d2c to dump out demacrofied Dylan source code that 
could be fed in to this hypothetical new compiler.

-- Bruce