[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dylan revival



In article <B8DA6655.1076E%scott_ribe@killerbytes.com>,
 Scott Ribe <scott_ribe@killerbytes.com> wrote:

> > 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.
> 
> I was referring both to difficulty of implementation and difficulty of
> comprehension and use. It never occurred to me to think that parsing
> performance could be a problem; the days of CPUs that slow are long past ;-)

Where Dylan macros are capable of doing the job at all, I think they're 
substantially easier to write and understand than, say, Common 
Lisp-style procedural macros.

Of course, there are things that pattern replacement-style macros such 
as in Dylan can't do, but I think they're a good 99% solution.

-- Bruce