[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