3 ms·
True, but can't we say that about every non-trivial PL feature? For example, we could say that: In OOP languages such as Smalltalk, there is much less need for
by raganwald 15y ago
True, but can't we say that about every non-trivial PL feature? For example, we could say that:
In OOP languages such as Smalltalk, there is much less need for macros.
The author's point is that programming languages are great when you're cutting with the grain, when you're working in the domain the author optimized the language around. But when you leave the domain, macros are an important tool.
Don't get me wrong, I think that lazy evaluation is an incredibly valuable tool for separating what from how. But I wonder how it obviates the need for macros any more so than a well-defined OO system or any other non-trivial language feature.
- wnoise 15y agosedachv actually got my point. The standard need for macros rather than functions is to handle staged computations, distinguishing between names and objects. Lazy evaluation really does strike right at the heart of this, unlike something like "object system".
- kenjackson 15y agoClosures give you this (staged computations). Macros really give syntactic abstraction. That's it. That's nice, but you get the rest via other mechanisms.
- sedachv 15y agoClosures can't do partial evaluation, macros can.
- kenjackson 15y agoI wasn't trying to imply you can do everything with closures. But rather you could do lazy evaluation with it (I guess staged computations could include various forms of pre-rutime evaluation).
- dfox 15y agoIn my opinion, Smalltalk is prime example of language that is desperately missing macros. Most of Smalltalk code is boilerplate that is automatically generated by IDE, replacing this automatic generation with macros seems like natural thing to do. Smalltalk community seems to prefer to build complex tools to automatically generate and modify code in it's textual form, which I think is generally solving the wrong problem.